You are currently browsing the archives for the Mobile Web category


One-time function initialization

When developing Mobile Web Applications, even the seemingly marginal micro-optimizations can result in a noticeable performance improvement over time and, therefore should be implemented where possible. One could also argue (and rightly so) that this same principle applies when developing Web Applications on the Desktop; however, in the context of Mobile Web Experiences, such optimizations are essential, perhaps even obligatory on the developers part.

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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.

AT&T Best Practices Guide for App Development

When considering the various best practices surrounding the design of Mobile Web Experiences and Architectures, such works as the W3C’s Mobile Web Application Best Practices guide, or the excellent Mobile Web Best Practices site, and of course, the seminal text, Mobile First, are likely to come to mind. The concepts and strategies presented in these works are a staple in the design of many modern Mobile Web Experiences and are without question an invaluable resource. In addition to these and other similarly related works, another new and valuable resource has been made available from a very important player in the Mobile Space indeed – an actual Wireless Carrier, AT&T.

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

Configuring iOS HTTP Monitoring

When developing Web Applications for the Mobile Web Experience it is often useful to have a clear view into all HTTP requests and responses sent between the client and server. This is quite simple to accomplish when developing Web Applications for the Desktop as, the browser is running locally so any standard HTTP Monitor will suffice. And, while it is a normal part of a typical development workflow to run an application locally the majority of the time, testing on each target device is obviously an essential part of the process as well.

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.

DHTMLX Touch 1.0 Released

Last week, shortly after I blogged about the release of jQuery Mobile 1.0, I received an email informing me of the release of another Mobile Web Framework: DHTMLX Touch 1.0.

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.

jQuery Mobile 1.0 Released

, the jQuery Mobile Team announced the official release of jQuery Mobile 1.0.

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.

CSS3 Combinators

In my previous article on CSS3 Selectors, I discussed the two Attribute Selector classifications; Attribute Presence and Value Selectors, and, Attribute Substring Matching Selectors.

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.

Combinators

Combinators provide a means for describing relationships between elements in order to “combine” them to form specific rules based on a simple syntax. There are four Combinators in CSS3, below is description and example of each:

Descendant combinator
The most familiar of all Combinators, the Descendant combinator allows for selecting any element f which is a descendant (child, grandchild, great-grandchild and so on) of an element e. The combinator syntax for a Descendant combinator is a single “white-space” character.
1
2
3
4
5
/* Matches all <h1> elements which are descendants of an <article> element */
article h1{
/* declarations */
}

8.1. Descendant combinator
Child combinators
Child combinators allow for selecting any element f which is a direct child of an element e. The combinator syntax for a Child combinator is a single “greater-than” (>) sign.
1
2
3
4
5
/* Matches each <section> element that is a direct child of an <article> element */
article > section {
/* declarations */
}

8.2. Child combinator
Adjacent sibling combinator
The Adjacent sibling combinator is a Sibling combinator which allows for selecting an element f which is adjacent to an element e; that is, element f immediately follows element e in the document tree. The combinator syntax for an Adjacent sibling combinator is a single “plus” (+) sign.
1
2
3
4
5
/* Matches all <em> elements which are the next sibling of a <strong> element */
strong + em {
    /* declarations */
}

8.3.1. Adjacent sibling combinator
General sibling combinator
New in CSS3, the General sibling combinator is similar to the Adjacent sibling combinator in that it matches an element f which follows an element e in the document tree; however, whereas in the Adjacent sibling combinator element f must immediately follow element e, the General sibling combinator allows for selecting an element f which is preceded by an element e, but not necessarily immediately preceded by an element e. The combinator syntax for a General sibling combinator is a single “tilde” (~) sign.
1
2
3
4
5
/* Matches all <time> elements which are preceded by a <del> element */
del ~ time {
/* declarations */
}

8.3.2. General sibling combinator

The following link provides a (rather crude in terms of design) example of each Combinator described above:
View Example

CSS3 Attribute Selectors

The power of CSS Selectors can not be understated; for, without them, there would be no simple means by which developers could target specific elements for styling in a manner abstracted from, or external to, the actual markup to which the styles will bind.

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.

Attribute Presence and Value Selectors

CSS2 introduced four Attribute Selectors; referred to as Attribute Presence and Value Selectors, which allow for course grained matching of specific elements based on their attributes and / or attribute values. These include the following:

e[attr]
Where e is an element and [attr] is an attribute of element e. For example, p[title] would match all p tags with a title, regardless of the value of the title.
1
2
3
4
5
6
/* Matches all <p> tags with a title and changes their background color to red with white text */
p[title]{
background-color: red;
color: white;
}

e[attr=val]
Where e is an element and [attr=val] represent an attribute of element e which contains the exact value of val. For example, p[title="Example 1"] would match all p tags with a title which equals “Example 1″ exactly.

1
2
3
4
5
6
/* Matches all <p> tags with a title equal to "Example 1" and changes their background color to green and text color to white */
p[title="Example 1"]{
background-color: green;
color: white;
}

e[attr~=val]
Where e is an element and [attr~=val] is an attribute of element e which has a value containing a whitespace-separated list of words, one of which equals val exactly. For example, p[title~="Example-1a"] would match all p tags with a title containing the word “Example-1a” in a list of whitespace delimited words.

1
2
3
4
5
6
/* Matches all <p> tags with a title containing the exact word to "Example-1a" and changes their background color to black and text color to red */
p[title~="Example-1a"]{
background-color: black;
color: red;
}

e[attr|=val]
Where e is an element and [attr|=val] is an attribute of element e that has a value of val exactly, or begins with val immediately followed by a hyphen “-”. For example, p[title!="Example"] would match all p tags with a title containing the word “Example-”, followed by any other value, such as “Example-1″, “Example-A”, etc..

1
2
3
4
5
6
/* Matches all <p> tags with a title containing the word to "Example-" and changes their background color to blue and text color to white */
p[title|="Example"]{
background-color: blue;
color: white;
}

View Example

Substring Matching Attribute Selectors

In addition to the above Attribute Presence and Value Selectors, CSS3 expands on this by defining three additional Attribute Selectors; referred to as Substring Matching Attribute Selectors. These additions allow for fine grained matching of specific elements based on their attribute values.

In simplest terms, the new Attribute Selectors in CSS3 can be used to match an element with a given attribute whose value begins, ends or contains a certain value. The following is a basic description and example of each new Attribute Selector:

e[attr^=val]
Where e is an element and [attr^=val] is an attribute of element e which contains a value that begins with val.
1
2
3
4
5
/* Matches all linked resources sent over https */
a[href^="https"]{
color: red;
}
e[attr$=val]
Where e is an element and [attr$=val] represent an attribute of element e which contains a value that ends with val.
1
2
3
4
5
/* Matches all anchor tags to .html documents */
a[href$=".html"]{
color: green;
}
e[attr*=val]
Where e is an element and [attr*=val] is an attribute of element e which has a value that contains val.
1
2
3
4
5
/* Matches all anchor tags which contain a query string */
a[href*="?"]{
color: blue;
}

View Example

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.

Test Driven Javascript with QUnit

For the past year I have been using jQuery Mobile for developing web based mobile applications leveraging HTML5, CSS3 and JavaScript. Like all UI implementations, meaningful test coverage is essential to ensuring requirements have been met and refactoring can be achieved with confidence. Building applications for the Mobile Web is no different in this respect. And so, a high quality Unit Testing framework is as essential to the success of Mobile Web Applications as it is to their Desktop counterparts.

Why QUnit?

While there are quite a few good JavaScript Unit Testing Frameworks available, Jasmine in particular, I have found QUnit to best suit my particular needs for implementing Test Driven Development in JavaScript based on it’s clean design and practical implementation.

A Simple, Powerful API

The power of QUnit lies in it’s simple and a rather unique approach to Test Driven Development in JavaScript. The QUnit API introduces a few slightly different test implementation concepts when compared to the more traditional xUnit style of TDD. In doing so, QUnit succeeds in simplifying some of the tedium of writing tests by leveraging the language features of JavaScript as opposed to strictly adhering to the more traditional xUnit conventions, the design of which is based on an fundamentally different language idiom – that is, Java.

For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:

1
2
3
4
5
6
test("Test expected namespace override", function() {
var expected = "someNamespace-";
var actual = $.mobile.ns;
equal(actual, expected, "expecting namespace to have been set.");
});

Figure 1 (run) (source)

The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.

As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.

A Complete Example

As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).

HTML5 Elements: The <base> Tag

The HTML5 Specification introduces many new semantic elements, as well as specifications for existing elements; one of which is the <base> Tag, which allows for specifying a root URL from which all linkable elements in a document (hyperlinks, images etc.) are based, as well as a default target for all linkable elements.

Overview

  • The <base> Tag provides two attributes; href (Hyper-text Reference) and target, respectively, which have the same semantic meaning as that of a hyperlink.
  • Only a single <base> Tag is to be defined per page and, must be defined before any elements which except a URL are defined (other than the html element).

Note: While the <base> Tag is not new to HTML5, the changes to the a Tag implies a difference (albeit, marginal) as, a Tags are always hyperlinks, or placeholders for hyperlinks.

Example

Like all HTML markup, usage of the <base> Tag is easy and straightforward: Simply add a single <base> Tag in the <head> element of the document and define either a base URL and / or default target attribute.

Defining a default base URL and target:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!DOCTYPE html>
<html>
<head>
<base href="http://somedomain/app" target="_blank" />
</head>
<body>
<nav>
<a href="index.php" >Home</a>
<a href="aboutus.php">About Us</a>
<a href="contactus.php">Contact Us</a>
</nav>
</body>
</html>

The above links will all default to a blank target (new page), with each link’s base URL defaulting to “http://somedomain/app”. Individual links can override the base URL as well as the default target.

Support

The <base> Tag is currently supported by all major browsers.

A Step Backwards In Usability?

I recently read a preview of a column which is to be published in the next addition of ACM CHI magazine, Interactions. This particular article is a rather interesting read in that it touches upon what the authors argue are the many short-comings in current Gestural Interfaces; stating that they pose a huge step backwards in terms of Usability.

This may not have raised many eyebrows if it were not for the expertise of the articles authors, Donald A. Norman and Jakob Nielsen; both of whom know quite a bit about HCI.

Experimentation in new technology and the process of learning what works and what does not can be challenging. This article raises some important, yet mostly overlooked, concerns surrounding new technologies which are built upon Gestural Interfaces; i.e. current touch screen devices such as iOS and Android. Certainly a good read for anyone interested in Touch Screen development. Gestural Interfaces: A Step Backwards In Usability