You are currently browsing the archives for the APIs category

External Templates in jQote2

The jQote2 API Reference provides plenty of useful examples which are sure to help users get up and running quickly. I found it a bit unclear, though, as to how templates could be loaded externally as, in the reference examples, templates are defined within the containing page. For the sake of simplicity this approach certainly makes sense in the context of examples. However, in practice, templates would ideally be loaded externally.

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.

December 12, 2011 AJAX / APIs / Design Patterns / HTML5 / JavaScript / jqote2 / jQuery / Test Driven Development
2 comments

Refreshing listviews in jQuery Mobile

When dynamically creating or updating a list in jQuery Mobile; either via AJAX or by other means, one must take care to explicitly invoke the target listview widget to “refresh” in order to instruct the framework to apply the augmented markup and styles to the corresponding elements of the underlying list.

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 + ‘">’ + item.name +‘</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 + ‘">’ + item.name +‘</a></li>’;
});
$("ul:jqmData(role=’listview’)").append( list ).listview("refresh");

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

November 18, 2011 AJAX / APIs / HTML5 / JavaScript / jQuery / jQuery Mobile
No comments

Circumventing Conditional Comparisons

Often during the course of my day I come across code which evaluates the same conditional comparisons in multiple contexts. Understandably, this is rather typical of most software systems, and while it may only introduce a negligible amount of technical dept (in the form of redundancy) for smaller systems, that dept can grow considerably in more complex, large scale applications. From a design perspective, this issue is applicable to nearly every language.

For example, consider a simple Compass class which defines just one public property, “direction” and, four constants representing each cardinal direction: North, East, South and West, respectively. In JavaScript, this could be defined simply as follows:

var Compass = function(direction){
    this.direction = direction;
}
Compass.NORTH = "North";
Compass.EAST  = "East";
Compass.SOUTH = "South";
Compass.WEST  = "West";

Technically, there is nothing problematic with the above class signature; the defined constants certainly provide a much better design than conditional comparisons against literal strings throughout implementation code. That being said, this design does lead to redundancy as every instance of Compass which needs to evaluate the state of direction requires conditional comparisons.

For example, to test for Compass.North, typically, client code must be implemented as follows:

if (compass.direction === Compass.NORTH) {
    //…
}

Likewise, simular comparisons would need to be implemented for each cardinal direction. And, while this may seem trivial for a class as simple as the Compass example, it does become a maintenance issue for more complex implementations.

With this in mind, we can simplify client code by defining each state as a specific method of Compass. In doing so, we afford our code the benefit of exercising (unit testing) Compass exclusively. This alone improves maintainability while also simplifying client code which depends on Compass. As such, Compass could be refactored to:

var Compass = function(direction){
    this.direction = direction;
}
Compass.prototype = {
    isNorth: function() {
        return this.direction === Compass.NORTH;
    },
    isWest: function() {
        return this.direction === Compass.WEST;
    },
    isSouth: function() {
        return this.direction === Compass.SOUTH;
    },
    isEast: function() {
        return this.direction === Compass.EAST;
    }
}

Based on the above implementation of Compass, the previous conditional comparison can be refactored as follows:

if (compass.isNorth()) {
    //…
}

Comparator API

To simplify implementing conditional comparisons, I have provided a simple Comparator API that defines a single static method: Comparator.each, which allows for augmenting existing objects with comparison methods. Comparator.each can be invoked with three arguments as follows:

type
The Class to which the comparison methods are to be added.
property
The property against which the comparisons are to be made. If the property has not been defined it, too, will be added.
values
An Array of constants where each value will be used to create a new comparison method (prefixed with “is”). If the constants specified are Strings, typically an Array containing each constant should suffice. For example, passing [Foo.BAR] where BAR equals “Bar” would result in an isBar() method being created. To specify custom comparison method names, an Object of name/value pairs can be used where each name defines the name of the method added and the value is the constant evaluated by the method. This is useful for constants which are not strings. For example, {isIOS421: DeviceVersion.IOS_4_2_1} where IOS_4_2_1 equals 4.2.1 would result in an isIOS421() method being created.

Taking the Compass example, the previous comparison methods could be augmented without the need to explicitly define them via Comparator.each:

var Compass = function(){
    this.direction = direction;
}
Compass.NORTH = "North";
Compass.EAST  = "East";
Compass.SOUTH = "South";
Compass.WEST  = "West";
Comparator.each( Compass, "direction", [Compass.NORTH,
                                        Compass.WEST,
                                        Compass.SOUTH,
                                        Compass.EAST] );

The above results in the comparison methods isNorth, isEast, isSouth and isWest being added to the Compass type.

Comparator: source | min | test (run)

October 14, 2011 Agile / APIs / Code Review / Design Patterns / JavaScript / Object Oriented Design / Refactoring / Software Engineering / Test Driven Development
No comments

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.

September 18, 2011 APIs / Browsers / CSS3 / HTML5 / JavaScript
No comments

Multiscreen Software Design

“We are in the midst of a revolution across a variety of screens”

You may recall first hearing the notion of a “Multiscreen Revolution” during the keynote at Max 2010. If you take a moment and think about it that’s a rather profound statement, and by all apparent indications a very true one.

This is also how Kevin Lynch, CTO at Adobe, begins his recent article, aptly titled “The Multiscreen Revolution” in which Kevin provides a succinct breakdown covering the driving forces behind this revolution and how it is guiding the future of the Flash Platform.

Allow me to digress for a moment as, in a way, for me at least, the “Multiscreen Revolution” tends to conjure up the hypothetical notion of a Multiverse. This may be a suitable analogy I suppose as we have been focused in a predominantly Personal Computer based reality for many years, and while this remains relevant, it is no longer exclusive.

I have been giving a lot of thought lately regarding designing software in a multi form factor paradigm and felt I would share some initial thoughts on the subject. Keep in mind much of this is still quite new and subject to change; however, I have made an attempt to isolate what I feel will remain constant moving forward, particularly in the context of developing native applications with the Flash Platform across a variety of screens.

First, User Experience Design

My initial thoughts on the implications of what a Multiscreen paradigm will have on the way we think about the design of software are primarily concerned with User Experience Design (UX Design). While simply using CSS3 media queries to facilitate dynamic runtime layouts will be needed for most HTML based web applications, I do not believe these types of solutions alone will allow for the kinds of compelling experiences users have come to expect. Sure they are useful, and for some HTML based websites they may suffice. However, in the context of more complex applications, RIAs in particular, but also just about every application developed specifically for a PC, too, I believe UX Design will need to encompass the best of what a particular form factor, “screen” or whatever you prefer to call it, has to offer, be it a PC, smartphone, tablet or TV.

For example, it is extremely rare that a UX Design intended for users of a PC will translate directly to a Mobile or Tablet User Experience. The interactions of a traditional physical keyboard and mouse do not equate to those of soft keys, virtual keyboards and touch gesture interactions. Moreover, the navigation and transitions between different views and even certain concepts and metaphors are completely different. In simplest terms; it’s not “Apples to Apples”, as the expression goes.

With this in mind, UX Design should remain at the forefront of Software Design, and in order for that to happen UX Design will not only need to continue to reflect the needs of users, but also by leverage the capabilities of the particular devices and screens on which an application will run. This is necessary as it better serves the needs of users in new and useful ways. Likewise, UX Design will need to account for the limitations (resources in particular) of those same form factors.

Second, Architecture

Mulitiscreen design obviously poses some new challenges considering the growing number of form factors which will need to be taken into account. The good news is most existing well designed software architectures have been designed with this in mind all along. That is, the key factor in managing this complexity I believe will be code reuse. A common theme amongst many of my posts, code reuse has many obvious benefits, and in the context of Multiscreen concerns it will allow for different screen specific applications to leverage general, well defined and well tested APIs. Code reuse will certainly be of tremendous value when considering the complexities encountered with Multiscreen design. Such shared APIs can be reused across applications which are designed for particular screens or extended to provide screen / device specific implementations.

For example, the Architectures I have worked on are designed such that each is broken out into specific modules (libraries) which, on a high level, are typically as follows:

  • unittesting-support: Provides convenience extensions of unit testing and mock frameworks.
  • commons: Provides all generic, reusable APIs which have no dependencies outside of those of the Flex Framework and Flash Player API.
  • framework-support: Provides reusable extensions of a particular framework. There can be multiple framework-support libraries, each of which would be specific to an individual framework; e.g. parsley-support, swiz-support, robotlegs-support, cairngorm-support, springactionscript-support etc.
  • business: Provides domain dependent, business specific reusable APIs which are common amongst all projects within the business domain. This includes domain models, shared services, Presentation Models, UI components and anything else which is specific to the business domain. While all of the previously listed libraries could be used with any AS3 / Flex project, the business library is intentionally coupled to the domain.

All of the above projects are used by the different business applications, allowing for significantly reduced complexity of each individual application. Moreover, each library provides isolated test coverage which allows for a greater sense of confidence when building applications which are dependent on them. This type of structure also lends itself well with common SCM and build conventions, allowing for simplified branching and versioning.

Architectures designed similar to what I have described above I would consider to be “multiscreen ready” (provided they are optimized and efficient) in that much of the underlying implementation has already been completed, tested and proven. What’s left is the mobile, tablet or TV application designs which should be mainly concerned with UX, particularly interactions, navigation and device capabilities. From these screen specific UX Designs the application architecture is mainly focused around view concerns specific to those devices; leveraging the existing APIs as needed. This is where the Presentation Model Pattern (which I have been recommending for years) or similar patterns will be of great value.

I also anticipate additional libraries being abstracted in addition to those I have listed above as a result of these device specific projects being developed. For example, I could easily imagine “device-support”, “mobile-support” and “tablet-support” projects which would provide reusable APIs specific for those screens so as to be leveraged across applications. In fact, I am working on libraries such as these at the moment.

Reusable libraries are nothing new; however, their role now is perhaps even more important as it is quite likely that multiple implementations of the same application will be needed for the various form factors and contexts. Existing reusable libraries may also need to be further optimized to provide the best performance against the slowest devices in order to be considered suitable for devices with the most limited resources. A natural side effect of such optimizations is that implementations of an application targeting the fastest form factors (typically, PCs) will benefit greatly.

Some Concluding Thoughts

In short, I believe both users and developers alike will be best served by providing unique User Experiences for specific screens as opposed to attempting to adapt the same application across multiple screens. One of the easiest ways of managing the complexity of multiscreen design and development will inevitably be code reuse.

I also believe the main point of focus should be on the medium and small form factors; i.e. Tablets and Smart phones. Not only for the more common reasons but, also because I believe PCs and Laptops will eventually be used almost exclusively for developing the applications which run on the other form factors. In fact, I can say this from my own experiences already.

While there is still much to learn in the area of Multiscreen Design, I feel the ideas I’ve expressed here will remain relevant. Over the course of the coming months I plan to dedicate much of my time towards further exploration of this topic and will certainly continue to share my findings.

March 6, 2011 Agile / Android / APIs / Code Review / Design Patterns / iPad / iPhone / Mobile / Object Oriented Design / Refactoring / Software Engineering / Tablets / Test Driven Development / User Experience Design
2 comments

Practices of an Agile Developer

Of the many software engineering books I have read over the years, Practices of an Agile Developer in particular continues to be one book I find myself turning to time and time again for inspiration.

Written by two of my favorite technical authors, Andy Hunt and Venkat Subramaniam, and published as part of the Pragmatic Bookshelf, Practices of an Agile Developer provides invaluable, practical and highly inspirational solutions to the most common challenges we as software engineers face project after project.

What makes Practices of an Agile Developer something truly special is the simplicity and easy to digest format in which it is written; readers can jump in at any chapter, or practically any page for that matter, and easily learn something new and useful in a matter of minutes.

While covering many of the most common subjects on software development, as well as many particularly unique subjects, it is the manner in which the subjects are presented that makes the book itself quite unique. The chapters are formatted such that each provides an “Angel vs. Devil on your shoulders” perspective of each topic. This is quite useful as one can briefly reference any topic to take away something useful by simply reading the chapters title and the “Angel vs. Devil” advice, and from that come to a quick understanding of the solution. Moreover, each chapter also provides tips on “How it Feels” when following one of the prescribed approaches. The “How it feels” approach is very powerful in that it instantly draws readers in for more detailed explanations. Complimentary to this is the “Keeping your balance” suggestions which provide useful insights to many of the challenges one might face when trying to apply the learnings of a particular subject. “Keeping your Balance” tips answer questions which would otherwise be left to the reader to figure out.

I first read Practices of an Agile Developer almost 4 years ago, and to this day I regularly find myself returning to it time and time again for inspiration. A seminal text by all means, I highly recommend it as a must read for Software Developers of all levels and disciplines.

February 10, 2011 Agile / APIs / Code Review / Continuous Integration / Design Patterns / Object Oriented Design / Refactoring / Software Engineering / Test Driven Development
No comments

Bindable Map

Recently I was going through some old drafts I had pending when I happened to notice I had never published this one, so I am finally doing so now…

Since first publishing an AS3 HashMap implementation back in December of 2006, much to my surprise the original post through which I released the API still yields a good amount of feedback each month.

In the time since I have extended the functionality of the HashMap to include a LocalPersistenceMap and ResourceMap in addition to the original HashMap; all of which implement the IMap interface and can be used interchangeably by client code.

The single most requested feature I have received has by far been to provide a Bindable HashMap implementation, and, just recently, I decided to implement one and share it with the community.

The implementation of the BindableMap is quite straightforward as it simply provides an API which wraps an IMap implementation in order to facilitate data binding capabilities to all read methods of the underlying Map.

Using the various IMap implementations with BindableMap yields some interesting possibilities; specifically when using BindableMap with LocalPersistenceMap as it essentially provides a bindable implementation of a LocalSharedObject, as can be seen in the following example (e.g. add some values and refresh the page):

Get Adobe Flash player

You can download the source, binary and example here.

October 18, 2010 APIs / Design Patterns / Object Oriented Design
No comments

Web Timing Specification

The Web Timing Specification (draft) aims at providing a standard set of APIs which allow for true end-to-end instrumentation of page load times across browsers.

To quote the w3 spec: “This specification (Web Timing Specification) defines an interface for web applications to access timing information related to navigation and elements.” The API is based on the Navigation Timing and Resource Timing interfaces, respectively.

While I haven’t seen this specification mentioned as part of the HTML5 Family before, in many ways I would consider it to be a worthy candidate for membership as it provides a standards based API through which web applications can be tested for load efficiency. This is obviously something quite useful for any web application as, the ability to precisely measure page load times – and implement optimizations as needed – affords developers the opportunity to provide an improved user experience.

Historically, the ability to accurately measure page load times of web applications has been quite challenging for a number reasons. Just knowing when and where to begin is debatable and, determining the best means of doing so can be a challenge in of itself. Regardless of any current strategies being used, the result is never entirely accurate. With Web Timing developers need not be concerned with these specifics as the API provides the ability to truly measure page load times by encompassing the full scope of loading and parsing a page. This includes the time involved to request, receive and render an HTML document.

For more information, try out the examples in the current supported browsers; IE9, Chrome 6.

July 20, 2010 AJAX / Android / APIs / HTML5 / iPad / iPhone / JavaScript / Mobile
No comments

Metadata API update for Flex 4

Back in September 2008 I published a post on Class Annotations in Flex, through which I provided an API allowing for a unified approach for working with AS3 metadata. Just recently I intended to use the Metadata API in a Flex 4 project when I noticed it no longer seemed to work as expected. After a bit of debugging, I realized the bug appeared to be related to changes in the result returned from describeType; specifically, the addition of the “__go_to_definition_help” metadata. Considering the Metadata API leverages describeType in order to introspect metadata definitions, this made sense.

I made some simple modifications to the API to work with the new metadata returned from describeType and this resolved the issue. While I was in the process I also refactored operations to return Vectors as opposed to ArrayCollections, as was the case in the original design; effectively optimizing the API for Flex 4 (as well as Flex SDK 3.4).

You can download the source/tests/swc/docs dist here; all of which will be available soon via SVN and a public Maven repository, more on that once it’s ready.

January 30, 2010 APIs / Refactoring / Test Driven Development
1 comment

Vector Iterator for Flex

One of the many welcome additions to the Flex 3.4 SDK is the inclusion of the Vector class. Vectors in particular are especially welcome as they provide compile time type safety over what would otherwise not be available when implementing custom solutions, such as a typed collection.

Essentially, Vectors are just typed Arrays. And while not as robust or powerful, Vectors are similar to Generics in C# and Java. When it is known at design time that a collection will only ever need to work with a single type, Vectors can be utilized to provide type safety and also to allow for significant performance gains over using other collection types in Flex.

I recently wanted to convert quite a few typed Array implementations to Vectors, however, the Arrays were being traversed with an Iterator. In order to reduce the amount of client code which needed to be refactored I simply implemented a Vector specific Iterator implementation.

If you are familiar with Iterator Pattern in general, and the Iterator interface in particular, then usage will prove to be very straight forward. You can use the Vector Iterator to perform standard iterations over a Vector. Below is an example of a typical client implementation:

var abc:Vector.<String> = new Vector.<String>(3, true);
abc[0] = "a";
abc[1] = "b";
abc[2] = "c";

var it:Iterator = new VectorIterator( alpha );

while ( it.hasNext() )
{
    trace( it.next() );
    // a, b, c
}

Using an Iterator with a Vector ensures only a linear search can be performed, which proves useful with Vectors as they are dense Arrays. However, one consideration that must be made when using an Iterator with a Vector is that you loose type safety when accessing items in the Vector via iterator.next(). It is because of this I would suggest only using Iterator’s with Vectors to support backwards compatibility when refactoring existing Arrays which are being used with existing Iterators.

The VectorIterator and it’s associated test are available below:
VectorIterator
VectorIteratorTest

October 2, 2009 APIs / Design Patterns / Object Oriented Design
1 comment
← Older Entries