As it turns out, it actually does; only there is a syntactical caveat to it – your immediate functions must have the closing parentheses defined outside of the function.

For example, while my preferred tool for validating Javascript is JSHint, the much stricter JSLint requires defining an immediate function’s invocation (i.e. the closing parentheses) within the function:

( function(){
}());
  

In JSLint, failing to do so, such as the following:

( function(){
})();
  

… results in the following error:

Error: Move the invocation into the parens that contain the function.

Being somewhat used to conforming to these (arguably unnecessary) rules, after some trial and error I found that adhering to JSLint’s requirements was in fact the cause of Aptana failing to provide an Outline View.

The solution to this problem is quite simple, just keep the invocation outside of the immediate function and Aptana will display the correct Outline View. Technically, I would consider this a bug on Aptana’s part and therefore have filed APSTUD-4364. Hopefully this issue will be resolved. In the interim, I hope this post helps.

In a previous post from a few months back I discussed some of the benefits of function overwriting in JavaScript. One similar performance optimization I regularly employee is that of One-time function initializations.

Conceptually, a One-time function initialization is a rather simple pattern which can be broadly described as follows:

1. An Immediate Function / Self-executing Function performs some initial test conditions.
2. The Immediate Function returns an anonymous function which, in turn, returns the results of the test conditions. Alternately, the Immediate Function can just return the test condition results.
3. The anonymous function returned is assigned to a function expression or, the test condition results are assigned directly.

An example in code illustrates just how simple this pattern is:

var hasSomeFeature = ( function() {
    // implement test logic... for example, testing
    // a feature's existence in the browser against
    // multiple vendor prefixes, etc.

    // return a function which returns the results, or
    // just return the result value if desired...
    return function(){
		// return results...
	};
}() );
  

Practical implementation example:

var hasWebSockets = ( function( window ) 
{
	var prefixes = 'ms O Moz Webkit'.split(' '),
	    n = prefixes.length,
	    i = 0;
	
	for ( ; i < n; ++i ) {
		if ( window[ prefixes[i] + 'WebSocket'] ) {
			return true;
		}
	}
	return 'WebSocket' in window;
}( this ) );
  

Implementing One-time function initializations are quite useful in many situations. Specifically, they are of most value when implemented for use-cases where conditions are too complex to assign to a variable directly and, when the conditions tested only need to be evaluated once, after which re-evaluating the condition would be redundant and unnecessary – such as certain feature detections.

As a general rule of thumb, if a condition or set of conditions can be tested once; that is, they are guaranteed to not change during the execution of the application and, the tests are too complex to maintain if directly assign to a variable, then implementing One-time function initializations are a small, yet simple and practical optimization.

Recently, I was contacted by a representative of the AT&T Developer Program informing me of the research conducted by the AT&T Research Labs and, the subsequent resources made available by AT&T as a result of their findings. Since I was unaware of this work, I was very interesting in learning more and, after reading the introductory statements, I was quite eager to apply AT&T’s recommendations as well; to quote specifically:

We quickly saw that a few, simple design approaches could significantly improve application responsiveness.

Having read through the material in it’s entirety (provided below) I must say I am rather impressed. The information provided has very real and practical implications on the design of Mobile Web Applications. Specifically, I found the clear and concise explanation of the underlying implementation of the Radio Resource Control (RRC) protocol to be particularly relevant and useful. RRC is by far one of the most important design factors to consider in terms of battery life and Application responsiveness and, as the research suggests, this may not have been common knowledge.

By far, the most interesting and notable aspect of the AT&T Research Lab’s work in this area is the fact that all of the information provided is applicable in the context of all Wireless Carriers, not just AT&T. That is, the recommendations given, such as those regarding the RRC State Machine, for example, are all based on carrier-independent standards and protocols implemented by all Wireless Carriers. As such, understanding the implementation specifics and recommendations provided is certain to prove valuable for all users of your Application, regardless of their Carrier.

If you haven’t all ready, I highly recommend reading and applying the principles provided by AT&T’s research to your current and future Mobile Web Application Designs.

AT&T Research Labs: Mobile Application Resources

Build Efficient Apps
Profiling Resource Usage for Mobile Applications: A Cross-layer Approach

Luckily, with Charles, on iOS this is quite simple to accomplish.

Configuration

To configure Charles to proxy all requests from an iOS device, simply follow these basic steps:

1. From your iOS Device, open Settings.
2. Go to Wi-Fi, select your Network and select the Blue “arrow” icon.
3. Scroll to HTTP Proxy and select the Manual Button.
4. In the Server field, enter the IP address of your development machine.
5. In the port field, enter port 8888 (the default port to which Charles binds).
6. Leave Authentication set to Off.

And that’s all there is to it. Now, open Mobile Safari and go to your Web Application’s URL (or any page on the web for that matter). On your development machine, in Charles you will receive a prompt with the IP Address of your Mobile Device, click “Allow” and you are all set. When you are done working, make sure to turn off HTTP Proxy on your device.

Additional Note

While this article may be focused on Mobile Web Applications, these same configurations apply to all HTTP traffic from any application on your device that requires resources over the web.

While jQote2 provides a perfect API for templating, it does not provide a method specifically for loading external templates; this is likely due to the fact that loading external templates could easily be accomplished natively in jQuery. However, since this is a rather common development use case, having such a facility available would be quite useful.

After reviewing the comments I came across a nice example from aefxx (the author of jQote2) which demonstrated a typical approach to loading external templates which was simular to what I had been implementing myself.

And so, I wrote a simple jQuery Plug-in which provides a tested, reusable solution to loading external templates. After having leveraged the Plugin on quite a few different projects, I decided to open source it as others may find it useful as well.

You can grab the source and view the example over on the jQote2 Template Loader Github page.

Being that I was unfamiliar with DHTMLX Touch (as I have been using jQuery Mobile almost exclusively), I was quite interested to learn more; and, having tried the Examples and reviewed the Documentation, I was rather impressed by DHTMLX Touch.

And so, if you haven’t already, check it out.

For example, consider the following simplified example which creates an li element for each item in an Array:

var list = "",
    items = [{name: "Item A", url: "/#item-a"}, 
             {name: "Item B", url: "/#item-b"}, 
             {name: "Item C", url: "/#item-c"}];

$.each( items, function( i, item ) {
    list += '<li><a href="' + item.url + '">';
    list += item.name;
    list += '</a></li>';
});
$("ul:jqmData(role='listview')").append( list );
  

While this will create the list items and add them to the target listview ul element, JQM will not auto enhance the newly added items unless instructed to do so. I imagine this is due to a necessary design decision as, constantly monitoring the DOM for changes would certainly incur a performance hit.

In order to correct this, we just need to invoke .listview("refresh"); after appending the new elements to the list. This will notify JQM to apply the expected enhancements. And so, the following example will result in the expected list enhancements being applied:

var list = "",
    items = [{name: "Item A", url: "/#item-a"}, 
             {name: "Item B", url: "/#item-b"}, 
             {name: "Item C", url: "/#item-c"}];

$.each( items, function( i, item ) {
    list += '<li><a href="' + item.url + '">';
    list += item.name;
    list += '</a></li>';
});
$("ul:jqmData(role='listview')").append( list ).listview("refresh");
  

You can try an example which demonstrates both of the above implementations here.

Having worked with jQuery Mobile since Alpha 1, in the time since, the framework has certainly evolved into a mature, premier platform on which Mobile Web Applications can be built.

On a personal note, as I am currently in the process of working towards the release of a multi form-factor Mobile Web Application built on jQuery Mobile, the 1.0 release couldn’t have come at a better time.

Be sure to check out the updated API Docs, especially the new Data Attributes section.

jQuery Mobile 1.0 represents a significant milestone in the Mobile Web Space. I am certainly excited to see what is on the roadmap next.

In addition to the new Attribute Selectors, the CSS3 Selectors Module defines a new Combinator called the General sibling combinator, which is described below, succeeding a review of each CSS3 Combinator.

In addition to some of the more common Simple Selectors, such as Type Selectors, Class Selectors and Id Selectors, we have have Attribute Selectors, which, as the name implies, allow us to match elements based on their attributes.

To summarize, there are a total of seven Attribute Selectors in CSS3, three of which are new. Whether used for general matches, such as global Attributes; e.g. *[hreflang|=en] or more specific matches, such as chaining; e.g, a[href^="https"][target="_blank"], Attribute Selectors provide a powerful mechanism for selecting both general and specific content within a page.

Interestingly, while reviewing the CSS3 Selectors Module (my personal favorite), I noticed that the selection pseudo-element selector which was originally drafted for CSS3 had been dropped from the proposal. In fact, it was dropped a rather long time ago.

In case you are not familiar with the selection pseudo-element, essentially it allows for defining the text color and background-color of selected text within a document.

For example, all <code> elements on my site have a red background with white text when selected – such as this text here (select it) – based on the following two simple rules:

// IE, Chrome, Safari, Opera
code::selection { background: #ca3131; color:#fff; }
code::-moz-selection { background: #ca3131; color:#fff; }
  

And so, while having been dropped, support is already rather good (FF3.6, SA3.1+, OP9.5+, CH2+, IE9) and as far as I am aware Browser vendors will continue to support ::selection.