You are currently browsing the archives for the Browsers category


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.

Function Overwriting in JavaScript

Whether intentional, or simply a by-product of it’s design, Javascript, being a dynamic language, allows for a level of expressiveness which most any seasoned programmer would come to appreciate. Javascript naturally provides the ability to implement some rather intriguing and quite unique patterns; one of which is the ability to overwrite a function at runtime.

Function Overwriting

Function Overwriting (also known as “Self-Defining Functions” or “Lazy Defining Functions”) provides a pattern which, as stated above, allows for overwriting a function’s definition at runtime. This can be accomplished from outside of the function, but also from within the function’s implementation itself.

For example, on occasion a function may need to perform some initial piece of work, after which, all subsequent invocations would result in unnecessarily re-executing the initialization code. Typically, this issue is addressed by storing initialization flags or refactoring the initialization code to another function. While such a design solves this problem, it does result in unnecessary code which will need to be maintained. In JavaScript, perhaps a different approach is in order: we can simply redefine the function after the initialization work has been completed.

A possible candidate use-case for Function Overwriting is Feature Detection as, detecting for specific feature support in the Browser typically only needs to be tested once, at which point subsequent tests are unnecessary.

Below is a basic example of implementing Function Overwritting in the context of an abstraction of the HTML5 Geolocation API.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Initial "getLocation" implementation. Since we only need to test
// for Geolocation support once, we perform the initial test and then
// overwrite the "getLocation" implementation based on the results of
// the test.
var getLocation = function ( success, fail, options )
{
    var geolocation = navigator.geolocation;
    if ( geolocation )
    {
        var _options = {
            enableHighAccuracy : true,
            timeout : 60000,
            maximumAge : 0
        };
// Geolocation is supported, so we overwrite the implementation
// to simply invoke "geolocation.getCurrentPosition" as there
// is no need to perform the test again.
getLocation = function (success, fail, options)
{
geolocation.getCurrentPosition ( success,
fail,
options || _options);
}
getLocation( success, fail, options );
    }
    else
    {
   // Geolocation is not supported, so we overwrite the
// implementation to simply return false (a real
   // implementation might provide a polyfill here...).
   getLocation = function ()
   {
return false;
}
}        
};

Considerations

Since functions are objects in Javascript, it is important to keep in mind that if you add a property or method to a function (either statically or via the function’s prototype), and then overwrite the function, you will have effectively removed those properties or methods as well. Also, if the function is referenced by another variable, or by a method of another object, the initially defined implementation will be preserved and the overwriting process will not occur. As such, be mindful when implementing this pattern. As a general rule of thumb, I typically only implement Function Overwriting when the function being redefined is in a private scope.

Concluding Thoughts

As you can see, Function Overwriting provides a convenient facility for optimizing code execution at runtime. There are many use-cases for dynamically overwriting functions and, where appropriate, they can certainly provide value in terms of performance and code maintainability.

Below you can find an example which demonstrates two basic Function Overwriting implementations. Simply load the page and add some breakpoints in Firebug to test the execution paths; both before and after overwriting each function occurs, or you can simply view the source.
Example

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.

Interconnectivity in JavaScript with Peerbind

The ability to facilitate interconnectivity between multiple clients has always presented some rather interesting possibilities for both simple and complex Web Applications alike. More often than not, such interconnected applications would require complex server-side configurations (often proprietary in nature) in addition to numerous infrastructure considerations.

Peerbind, a new JavaScript API, remedies many of these complications by providing a very simple client-side API built on jQuery.

Peerbind is quite unique in that it provides an event binding API (on top of jQuery) that is shared amongst all connected clients of the same interest. Essentially this allows for binding something as common as a “click” event (or any event for that matter, including custom events) such that each active instance of the same application across the web will be notified of the event. As one might imagine, this allows for some rather compelling possibilities.

To demonstrate just how quickly and easily interconnectivity can be plugged into a web application using Peerbind (and the Peerbind public server), below is a simple example which displays a new item each time a new “peer” views the example page since loaded (hint: try opening a few instances, either in tabs or separate browsers).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<title>Simple Peerbind Example</title>
<script src="http://code.jquery.com/jquery-1.4.4.js"></script>
<script src="http://js.peerbind.com/jQuery.peerbind.js"></script>
<script>
var Peers = (function()
{
    var added = function(e)
    {
        var timestamp = new Date(e.timeStamp);
        var visitor = e.srcPeer ? "New Visitor" : "You";
var item = "<li>" + visitor + " arrived on " +
timestamp + "</li>";
   $("#visitors").preppend( item );
    }
    var init = function()
    {
        var body = $(document.body);
       body.peerbind( "peer", added );
       body.peertrigger( "peer" );
    }
    return {
       init: init
    }
}());
$(document).ready( Peers.init );
</script>
</head>
<body>
<ul id="visitors"></ul>
</body>
</html>

Example (run)

Simple enough!

Of course, for most applications there are obvious security concerns which would need to be addressed as well as issues of scale and availability to take into consideration. That being said, if you haven’t checked out Peerbind yet and would like to quickly and easily add interconnectivity to your application or leverage it’s simplicity to prototype such features, it is certainly worth taking for a test drive.

Tracking HTML5 Support in Chrome

Google has now made it easy to track the current implementation status of HTML5 in Chrome via The Chromium Projects’ new Web Platform Status page.

Many of the sections have links to their html5rocks site, which provide further details and more in-depth tutorials of implemented specifications.

The current sections include:

This is certainly something to keep an eye on as, Chrome is setting the standard in terms of HTML5 support by desktop browser vendors.

Custom Search Engines in Chrome and Firefox

Recently I upgraded to a beautiful new iMac, on which I needed to configure my development environment and general workflow preferences. This required a few steps which I haven’t performed in quite some time and, upon doing so, I was reminded of how minor, yet useful many of these simple configurations actually are.

One such configuration involved defining Custom Search Engines in both Chrome and Firefox – a rather nice facility a colleague shared with me a while back. In case you haven’t used them before, Custom Search Engines allow for defining simple and complex search queries which can be easily invoked using a predefined keyword in the Address bar in Firefox or Omnibox in Chrome.

For instance, I use a Custom Search Engine with JIRA for quickly searching tickets, etc. Once set up, searching (by example of JIRA) is as simple as typing in my chosen keyword “t” (for ticket) and entering a ticket number, as can be seen below:
Custom Search Chrome
Custom Search Engine in Chrome

Likewise, in Firefox, typing my Custom Search Engine keyword for JIRA in the Address bar brings up the following prompt:
Custom Search Firefox
Custom Search Engine in Firefox

Defining a Custom Search Engine

Setting up your own Custom Search Engine is simple and straightforward. Doing so in Chrome can be accomplished as follows:

  1. Select the Wrench Icon.
  2. Under Preferences, select “Basics”.
  3. In the Search Section, click on the “Manage Search Engines…” button.
  4. In the “Other Search Engines” Section, add the name of your Search Engine, your search Keyword and the URL of the site you will be using, appending %s to the end in place of the Query.
  5. Once completed, enter the keyword into the Omnibox. You will see the the Name you choose for the Search Engine automatically added. Type a Query, hit Enter, and you are all set.

In Firefox creating a Custom Search Engine is accomplished by specifying a “keyword” when adding a bookmark and, appending the bookmarked URL with %s in place of the Query. This can be done as follows:

  1. From the Menu Bar, select “Bookmarks”.
  2. In the Menu Drop down, select “Show all Bookmarks”.
  3. In the Bookmark Library Dialog, select a folder (e.g. Bookmarks Toolbar).
  4. Click on the Gear Icon in the top left of the Dialog.
  5. From the Drop down, select “New Bookmark…”
  6. Enter the Name of your Bookmark/Custom Search Engine.
  7. In the Location field, enter the URL of the site you will be searching, replacing the query with %s (use existing Search Engines entries as a reference if needed).
  8. In the Keyword field, enter an arbitrary keyword of your choosing.
  9. Click “Add”
  10. Enter the keyword followed by your query in the Address Bar. You will see the Name you choose for the Search Engine automatically added in the History Dropdown. Hit Enter, and you are all set.

And thats basically all there is to it. Simple, quick and useful.

AJAX Debugger beta 2.0

This weekend I built a simple AJAX debugger for handling complex types such as objects, arrays, JSON objects etc. The AJAX Debugger traces out all properties of a user defined objects, properties of an object, indexes of an array, keys of an array or other object types to a div tag with an id of “console” in your application.

To use it, just include the debugger.js file and create a div somewhere on the page to use as an output panel. Simply give the div tag an id of “console”.

To use the debugger simply use the following syntax to trace an object to the console div:

Examples:

1
2
3
4
5
6
// whereas the first param is an object of any type to trace
// and the second param instructs the debugger to recursively
// trace out the object or not.
trace (object, true);
1
2
3
4
5
6
7
8
9
10
var obj = new Object();
this.obj.name = "AJAX Debugger";
this.obj.build = 1.0;
this.trace(obj, true);
// Outputs the following to the "console" div:
// Found instance of type : Object
// .name = AJAX Debugger
// .build = 1

An upgrade to version q.0 will be made within the next few weeks which will allow the console to be in a separate window abstracted from the application itself.

To view an example of how the debugger works click on the link below:
AJAX Debugger

To download version 1.0 of the AJAX Debugger, click on the link below:
ajax-debugger.zip

Feel free to email me with your thoughts and / or ideas to make the Debugger better.