Earlier this morning, Microsoft unveiled Azure, their foray into the burgeoning cloud computing industry.  This, coming days after the announcement of Rackspace’s acquisition of virtual private server provider Slicehost (Disclosure: I’m a happy Slicehost customer) and online storage provider Jungledisk, means there will soon be some big league competition for the incumbent Amazon’s Elastic Compute Cloud (EC2) and Simple Storage Service (S3) for the estimated $42 BN this market will grow to by 2012.

This trend toward more affordable big-league server capacity for companies is a boon to start-ups and small companies who can’t finagle the cost of building and running their own server farms, but at the same time bodes poorly for those companies currently operating under the Software as a Service (SaaS) / Application Service Provider (ASP) model. These services we all know and love were, and still are in some circumstances, ideal for keeping technical infrastructure out of the way of creating complex solutions to elegantly address the business needs of all sized interests.

The biggest caveat (or best feature, depending on what side of the desk you’re sitting at) with the SaaS/ASP model was the overhead they introduced to terminating your contract; when all your eggs are in someone else’s basket, they’ve got some leverage when you need those eggs somewhere else. This new-ish wave of cloud computing (I love buzz words) has effectively established a middle ground: you can own your data without owning your hardware, albeit introducing a need for technical staff to pull all the cords and levers to get your blimp off the ground. 

What does this mean for agencies like Molecular? We fill that need for expertise in getting our clients’ dreams into the skies, and with a new slew of infrastructural options to build upon, we’re able to provide more choices and, ideally, better-fitting options to our clients, and to stay in the picture to meet their needs and steer their business forward as their enterprise floats in the cloud.

Often times in the fight to develop web pages quickly we forget how important it is to make sure our page is optimized to the best of your ability.  Simple things like placing CSS and Javascript files externally are an easy and well known example of page optimization but many times we can do more. Yahoo! has provided a set of recommendations on their site called Best Practices for Speeding up your Website. This list spans all areas of a page that can be tweaked with to minimize page size and loading time.  Now many of these recommendations have their downsides as well but overall I found some good ideas on improving my web page performance.

The obvious question now is how do I make sure I am complying to all these best practices while I am developing.  Well luckily Yahoo! has provided a very well integrated addon for Mozilla Firefox called YSlow. YSlow provides automatic feedback in your browser status bar for every page you load.  It gives a performance grade (very strict) on each page along with the page size and load time.  I find this very helpful while developing so I can quickly glance at these stats every time my page loads.  YSlow also provides a detailed list of every HTTP request made when loading the page. This is nice so you can see how long it takes to download certain images or script files.  Improvements can then be made to cache those large images if they tend not to change often or with a script maybe minify it before deploying it.  Lastly this addon provides a nice way to view overall stats of the page including images, css, and JS downloaded.

Next time you go searching for Firefox addons be sure to pick this one up!

or

“jQuery’s noConflict in Action”

As Interactive Developers, we all have our preferred javascript frameworks to aid our quest in building rich, interactive sites.  Some popular (and cost-free) frameworks out now include Prototype, MooTools, and YUI, but emerging as a leader in this space is jQuery, the “write less, do more” framework (as it’s been dubbed…)  These frameworks allow us to focus on the actual quality of interaction rather than spending time (and our clients’ money) writing widgets like sliders, accordions and drag-and-drop from scratch.  A common best practice is to use only one framework per page, but what happens when you absolutely, positively *must* use two frameworks on the same page?  What happens when the libraries you choose have numerous conflicts in their namespaces?   Molecular interface developers were recently tasked with overcoming this obstacle for a client and we found that jQuery had the easiest and most complete implementation of conflict evasion between javascript libraries.   I explain after the break:

Recently, Molecular was tasked with creating an interactive wrapper (header, menus, footer) for a global company which hosted hundreds of companion microsites around which this new wrapper framework would live.  The catch — these microsites were created by agencies around the world who were free to use whatever javascript libraries they chose. To save time and budget on the project, we already knew that we would need to utilize a library, the question was ‘which one?’  Conventional wisdom was that with hundreds of agency-developed microsites out there, two or more would certainly be using a library different than whatever library we chose.  Additionally, we didn’t want any of the agencies to be forced to change any javascript code that had previously been verified bug-free by numerous QA processes. One danger to these objectives was that some libraries such as Prototype, mooTools and jQuery all use a selector shortcut called ‘$‘.  If we chose one of these libraries, how would we be able to avoid such namespace collisions?   What would happen if one of these microsites was using a previous version of the *same* library?

Thankfully, jQuery’s core framework contains the ability to avoid any namespace collisions with other libraries via its noConflict method.   This would turn out to be another reason we chose jQuery as the framework for this navigation wrapper.  Not only could we seamlessly integrate with sites leveraging other libraries, we could also allow agencies to keep using earlier versions of jQuery without modifying their code at all.  Below are examples in how we tackled each scenario:

Scenario 1: Integrating with a conflicting library (not a different version of jQuery)

Here, we call the basic ‘noConflict’ method which removes jQuery’s ‘$’ alias from scope and leaves any selection work to the original “jQuery” function. At this point, any conflicting methods (like ‘$’) are relegated to the non-jQuery library. Note: Here, it doesn’t matter in what order the libraries are introduced into the page.

Step 1: Call jQuery (Note: script tags don’t contain “type” or “language” attributes for space reasons…)

<script ... src="js/jquery-1.2.6.js" ></script>

Step 2: Call your non-jQuery library (Note: script tags don’t contain “type” or “language” attributes for space reasons…

<script ... src="js/otherlibrary.js" ></script>

Step 3: set jQuery to noConflict mode.

jQuery.noConflict();

Step 4: Now, any time you utilize a conflicting method, it will be call via the non-jQuery library. Now to call a jQuery method, use the jQuery namespace.

$(selector).dosomething(); //not jQuery
jQuery(selector).dosomething(); //this is jQuery

Step 4a: You also have the option to encapsulate functions using the “$” command in self-executing functions like the one below:

(function($) {
$(function() {
$(selector).dosomething(); //this is jQuery
});
})(jQuery)

$(selector).dosomething(); //this is the other library

Scenario 2: Integrating with a different version of jQuery

In this instance, we call the ‘extreme’ version of noConflict which requires the developer to create an alias for their version of jQuery and assign it the value of noConflict. This scenario would resolve BOTH challenges. An important point here is that if you are attempting to use any jQuery plugins with a version of jQuery set to “noConflict” mode, any plugins you intend to use should be updated as well (you’ll need to change any references to “jQuery” or “$” to the alias you create.)    Note: Here, it *does* matter in what order the libraries are introduced into the page. YOUR jQuery must must be declaired and aliased before making a reference to the other library.

Step 1: Call jQuery (Note: script tags don’t contain “type” or “language” attributes for space reasons…)

<script ... src="js/jquery-1.2.6.js" ></script>


Step 2: Create a new object and assign it the noConflict method (with a parameter of the boolean “true”)

var $jQ= {};
$jQ = jQuery.noConflict(true);


Step 3: Call your other library. Again, this must come *after* the jQuery.js has been referenced and set to noConflict mode.
<script ... src="js/jquery-1.2.1.js" ></script>


Step 4: At this point, to call a jQuery method, you will use your new alias. To call your other library (or different version of jQuery), continue to use “$” or “jQuery”

$jQ(selector).dosomething(); //your "noConflict" jQuery method
$(selector).dosomething();//your other library's method


Following these easy steps will allow you to overcome any library namespace collisions. For more information on this topic, check out the jQuery documentation on noConflict() or this tutorial.

We (that is, “we” developers) all have our favorite secret weapons when it comes to making the complicated (read: RIA) applications seem easy, stuff like JQuery, YUI, Flex, mootools (hahaha, funny right?) Flash, ZK, Openlazlo, etc. But allow me to introduce a new discovery, Appcelerator.

What is it? Well, its not just a collection of javascripts and CSS snippets, its more like a fully integrated development platform with its own (very ant-like) build system and (perl-like) updating system. Appcelerator, an open source (using the more friendly, flexible and down-to-earth license of Apache) system provides developers (not so much designers) with tools to make RIA applications less of a chore.

How it works is that Appcelerator’s SDK basically “compiles” a series of templates (HTML/CSS) and Java code and creates all the appropriate JavaScripts, and a WAR file. Using a message-oriented-architecture all communications between the front-end and back end occurs through discreet “messages” which are just serialized chunks of JSON. Appcelerator handles all of the marshaling/unmarshaling for you so your only concern is making the individual pieces of functionality.

Integration is what appears to be Appcelerator’s real strong point. With the ability to fit in nicely with a Java application, it’ll be more than happy to be in your Perl, PHP, Ruby, or Python application, as well as your Google Gears application as well. With a full suite of widgets and plugins most common pieces are probably already built for you… um, so you don’t have to!

The magic of Appcelerator happens by a dynamic HTML scripting-like language where the developer simply assigns IDs to HTML elements and an “on” attribute which defines (for Appcelerator) the action to perform:

<div id="my_comment" on="r:app.my.package.response then effect[fade]“></div>

What that basically says is when the id “my_comment” receives a response (r) of app.my.package.response then it will fade in the value.

Pretty cool huh? Yes, its way more sophisticated than just this ridiculously simple example, but the idea is that everything is done through a very human-readable scripting syntax and all of the heavy lifting and tedious code of calling the server, marshaling the objects and dealing with the output is done for you.

In-vehicle multimedia, informational, and entertainment systems have evolved significantly in the past decade. Before the last decade, in-car entertainment was considered advanced if the car included in-dash multi-disc CD changers. However, since the introduction of the first generally available in-car navigation systems in the 1990s, manufacturers and vendors have gradually started to realize the potential in this area. Cars now come with a lot more advanced informational and entertainment systems, most with significantly sized display screens. The evolution of vehicle design in this department provides us with a glimpse of the trends to come and emphasize the importance of designing usability into in-vehicle displays and controls.

One of the first changes in car displays came with the introduction of larger screen multi-information screens. These displays initially started off monochromatic, and housed data from the on-board computer, climate control, and audio systems. The general idea was to centralize information display in a vehicle to reduce driver distraction. Thus, the screens were often mounted in a prominent location on the dashboard close to drivers’ line of vision. With time, multi-information displays grew in complexity, functionality, and display quality. BMW introduced their new iDrive system in 2001, which relied on a 10 inch color display screen housing entertainment, navigation, communications, climate, and car settings. Audi and Mercedes soon followed suit. Data types also varied, ranging from display-only text, editable fields, text fields, diagrams for navigation maps and for backup sensors, to videos for entertainment, rearview, or surround view features. The increased amount and types of information being presented meant deeper menu structures and more intricate information architecture. What started off as a consolidated display for basic vehicle information had essentially evolved into a mini on-board “Web site.”

Following the integration of larger color displays in cars and the advancement in multimedia and entertainment features, designers saw the opportunity to levitate in-car entertainment to the next level. Chrysler introduced built in hard drives that allowed owners to store and playback photos, music files, and videos. Users could even download pictures from their cameras onto the hard drive on the go. Chrysler also announced the arrival of uConnect Web, which offers Wi-Fi technology in their vehicles and allows passengers with Wi-Fi enabled mobile devices to connect to the Internet. Other manufacturers have once again followed suit in this area. Just recently, BMW and Mercedes launched in-car Internet connection and Web browsing in Europe. Owners are now able to use the in-vehicle multi-information display screen and integrated control interface to browse the Internet, email, and even purchase items or make hotel reservations from the car! While this technology has not yet launched in the US market, this heralds an entirely new generation of in-car informational and entertainment systems.

So what exactly does all this mean for the future of in-car multimedia, informational, and entertainment systems? All signs seem to point in the direction of a narrowing feature gap between in-car systems, mobile devices, and home PCs. In the very near future, expect growing availability of more advanced multimedia and navigation systems as these technologies trickle down from more expensive cars to more affordable models. Some of you may already have integrated hard drives that store photos and videos, or navigation systems that leverage real time traffic and weather information. Honda’s navigation systems in Japan also leverage up-to-date crime rate data in providing routing guidance. Farther out, expect wider spread availability of mobile Web browsing in cars. Web access could also be better integrated into the car’s systems, such as searching on Yelp for a recommended restaurant and navigating there or using the Web to diagnose an engine error code. In addition, the availability of Internet connection in vehicles sets a great foundation for the maturation of an advanced communications network between individual vehicles. A good example of where this might be beneficial is the ability for a car ahead to notify cars behind of potentially slick conditions or even an accident. A communications network like such would go great lengths in improving situational awareness for drivers.

From an interface design perspective, this advancing trend definitely opens doors for opportunities to design creative and innovative interactive experiences with car displays and controls. Think customizing Google driving routes via drag-and-drop on your car’s touch screen navigation system (which Volkswagen and Google are reportedly working on), an iPhone-esque interaction method, or a point and drag schema first seen on “Minority Report.” While all of these developments and opportunities are extremely exciting, there are also issues to factor in while dreaming up next generation car interfaces and features. On the information side, one thing to clearly be aware of is the impact of managing increased amount and types of information being displayed. Users would have to navigate through levels information to access all the different features, oftentimes while operating the vehicle. While usability will vary from system to system depending on how the physical and software interface are designed, the inherent nature of browsing through information levels means that an increased focus on usability and user interface design will be needed. Also, in addition to optimizing Web sites and applications for mobile devices, interface designers will eventually need to factor in vehicle information systems for future Web sites.

These are by no means limiting factors, but definitely remind us of the effort that needs to be spent on ensuring that the user’s needs are in mind when dreaming up gorgeous and innovative new in-car multimedia, informational, and entertainment systems. If so, we could all get our hands on and truly benefit from a lot of cool car features in the years to come.

On my current project, every change is accompanied by a long and tedious regression testing. Most of it is testing the JavaScript validation and the UI. This usually involves 100,000 clicks on different browsers!!

I was always looking for a chance to play with Selenium IDE and this was the perfect opportunity. Selenium is a suite of test tools to automate web app testing. There are usually two types of scenarios you would like to test:
1) Checking the style of the page
2) Validating if certain actions result in particular content on the page

Selenium offers three different tools to accomplish UI testing :

1) Selenium IDE : is a firefox plugin that records your activity and converts it to a Selenium test!! IDE can also convert your test in various programming languages that you can use with RC. The only disadvantage is it does not allow multi browser testing. Check out the intro video here

2) Selenium Remote Control: allows you to automate testing using different browsers in a programming language of your choice (Java, C#, PHP, Ruby, Python are supported). RC requires a server which acts as http proxy and launches browsers against any http website. You can use local-host as the RC server. The best way is to create your test scenarios using IDE and add a test case in RC code.

I have created a simple project for Selenium testing using C#. The source code can be checked out here. This can be used as a good starting point to add more complex testing scenarios.

3) Selenium Grid: allows you to scale out testing using multiple servers.

Selenium is perfect for testing Ajax apps and can be easily incorporated in a Continuous Integration System. Selenium cannot test Flash interactions (as expected).

Happy Testing!!

Building an application to reside and execute on a mobile device brings a whole other set of considerations and issues versus thin client development. Unlike browser based mobile applications, resident applications are going to be more dependent on their device platform.

When talking about development of downloadable applications it is important to distinguish whether the app is going to be written to a device platform or application platform. I will use term ‘device platform’ to mean mobile device hardware with its operating system or its integrated software. I will use term ‘application platform’ to mean combination of programming language, general development API, and the runtime environment for that language on the mobile device. The application platform runs on top of the device platform.

When writing to device portability is not much of a concern, so you want to explore and use the SDK, tools and device emulator provided by the device or OS provider. Most of the major device platform vendors provide such tools for their devices. Since you are working with a specific device, many of the other issues that must be considered when working with a vast array of products such as performance and access to the device’s features and functionality (phone, camera, GPS, and so on) are probably more straightforward. The table below lists some of these device platforms and what they offer in the way of SDKs, tools, etc.

Application Development Platforms

When considering application platform for your next mobile development project the choice is quite similar to the non-mobile world. Whether you are proponent of Java and open source platforms or prefer Microsoft tools there is always a question why do you like one platform vs. the other?

Mobile development re-raises this question, and you may have to re-evaluate your answer in light of your mobile application development. Java, .NET (C#, VB), C, C++, Python, and other languages are all options available in mobile development. In some ways, the same criteria used to compare these on a desktop or server can be used to evaluate the languages use for mobile apps. However, mobile development does bring in other considerations which distort the old desktop/server application development environment discussions.

For example, Java’s strength has always been portability. Java is a widely available platform on all sorts of mobile devices. Sun touts some 2.1 billion devices with Java as indicated earlier. However, the exact same Java is not on all these devices. In order for Java to fit on so many different styles and shapes of platform, the Java architecture has been broken into a set of configurations and profiles. The configurations and profiles differ according to device and device capabilities.

Take the .NET platform as example number two. .NET shines in that you can use your choice of programming language (C#, VB, etc.) written to a single platform; that of .NET and the Microsoft operating system. Yes, efforts in projects like Mono attempt to make .NET more cross-platform, but the number of actual platforms and devices using these cross-platform .NET implementations is limited. Microsoft tools (for the most part those in Visual Studio) do a great job of making development to this particular platform very easy. In the mobile platform world, however, Microsoft is not the dominate OS. Thus, writing to this platform may not get you to those customers you want to capture.

Let us look at three of the more popular application platform choices and look at ways to compare these platforms.

Java Micro Edition (Java ME)

Java ME, formerly called Java 2 Micro Edition (J2ME), functions as Java for mobile devices as well as the Java embedded in consumer electronics such as TV set-top boxes and printers. It is a runtime environment that goes on the device and a set of Java APIs and tools to create the applications. Java’s ubiquity on a number of platforms of all shapes and sizes is notable.

.NET Compact Framework

This platform is a version of the .NET Framework for Windows Mobile OS platforms. It’s a subset of the standard .NET framework, but also includes some additional classes that address specific mobile device needs. For example, the library includes classes to work with the device’s touch screen. Classes specific to the PC platform were removed, such as classes associated with remoting. The CLR execution engine was rebuilt so that it runs more efficiently on mobile devices that may have limited memory, resources and power. Like Java ME, this platform targets both mobile devices and other consumer electronics. For example, the XBox 360 consoles include a version of the .NET Compact Framework. You can write applications for the platform in C# or VB.NET. The Windows Mobile OS holds a significant market share on high-end PDAs and “smart phones.”

Binary Runtime Environment for Wireless (BREW)

BREW is an application runtime platform created by Qualcomm for mobile phones. It was originally created for Code Division Multiple Access (CDMA) devices, and more specifically, for Qualcomm’s CDMA devices and chipsets. Qualcomm spearheaded the development of standards for this communication technology’s use in digital cellular communications. BREW has since been ported to other devices, but largely remains a Qualcomm-specific platform. BREW provides a small runtime environment (approximately 150K in size) that runs on top of the device’s Application Specific Integrated Circuit (ASIC) or essentially its OS. Applications run atop the BREW runtime. Applications can be written in different languages, although most use C or C++. There are some Java implementations for BREW, but they require that the application run on the JVM—which runs on BREW, which runs on ASIC.

How do these environments compare to each other? A direct comparison can be difficult, given that many features provided through the application platform are a product of their targeted devices. However, some features worth examination are listed below.

Portability and Standards

Java’s ubiquity on a number of platforms of all shapes and sizes is notable. In 2006, Sun claimed that Java was available on 3.8 billion devices and 1.2 billion phones. Sun’s developer web site lists the hundreds of devices already outfitted with Java ME capability. Java, at its core, is meant to be platform-independent, but as indicated above, Java ME is a collection of specifications that outline a layered architecture:

• Configurations provide the basic services, libraries, and virtual machine capabilities for a broad range of devices based on the memory, power, and connectivity of the device.
• Profiles define the user interface, data storage, and other APIs for a narrower set of devices in a configuration.
• Optional API Packages add capability to a configuration and profile to support device capabilities not present on all devices (such as multimedia and Bluetooth).

This architecture allows Java to be added to devices large and small. However, the portability of an application depends on how many devices and, therefore, how many configurations, profiles, and APIs are targeted. The Java ME architecture can also impact how simple or complex application development can be.

Microsoft is .NET’s standard bearer. Proponents of .NET will claim other implementations of the .NET Common Language Infrastructure, such as Portable .NET and Mono, give .NET applications portability to other operating systems and devices, but portability is limited and these are not major players in the mobile arena. Windows Mobile OS is not a ubiquitous platform. It is common on relatively high-end “smart phones” and PDAs, but that popularity has not extended to lower end cell phones. Even on smart phones, a fourth quarter 2007 market data report from Canalys indicates that Windows Mobile has only a 12 percent market share. Competitors such as Symbian have a much bigger share worldwide (about 2/3 of the market) and others, such as Apple, are also working to cut into Microsoft’s market share.

Unlike Java ME, BREW offers portability without the numerous APIs and environments. However, BREW is tightly controlled by Qualcomm. Developers must register (or, “authenticate” in Qualcomm terms) with Qualcomm and submit their applications for BREW testing before the applications can be put on a device. This is supposed to ensure a BREW application behaves properly and is able to port to any BREW-capable device without issue. However, the cost (at least $400) of the authentication/testing is not trivial and a barrier to the software enthusiasts. Also, there are complaints that BREW is implemented differently and inconsistently on different phones. The emulator is generic and does not demonstrate these differences.

Development Tools and Integrated Development Environments (IDEs)

Java ME SDKs and basic tools are free from Sun. However, given the multiple Java ME environments and APIs, there are multiple SDKs and toolkits. Plenty of open source and commercial IDEs exist for creating Java ME applications. Eclipse and Sun’s NetBeans are the two most popular open source IDEs. Commercial products like Rational Application Developer from IBM are also available and popular. Device vendors like Motorola also offer their own SDKs. If anything, the Java ME environment suffers from having too many development choices rather than too few. The complexity of Java ME’s architecture allows for its adaptation to a great number of platforms, but also can make finding or assembling a proper development environment more of a challenge.

In this area, .NET Compact Framework development shines. While it is possible to write applications without it, few developers would write applications for the .NET Compact Framework (or .NET for that matter) without Microsoft’s Visual Studio. Visual Studio is not free. The latest version is Visual Studio 2008 and it can cost, depending on where purchased, $150 and up. Without question, this tool greatly simplifies mobile development for the .NET Compact Framework and has a low learning curve for those already familiar with .NET and C#/VB development.

BREW’s SDK is free and can be obtained from Qualcomm. However, developers also need an IDE. If writing BREW with C++, this means having a copy of Visual Studio 6.0, Visual Studio 2003 .NET, or Visual Studio 2005. Again, don’t forget the cost to be authenticated and have your application tested before deployment. This can be a significant hit to total cost of development.

Emulation/Testing

Through its SDKs and IDEs, Java ME environments offer a host of generic emulators for a number of devices. The Sun IDEs provide generic emulators that have “skins” that give the device emulator the appearance of a type of device with certain buttons, screen size, color depth, fonts, device controls, etc. Additionally, device vendors (Nokia, Motorola, etc.) provide SDKs that often offer more precise emulation for a particular device or set of devices. Some are able to be integrated with IDEs while others are stand alone.

The generic emulators don’t test vendor specific APIs. Additionally, as these emulators are generic in nature, they do not always accurately reflect specific device issues and capabilities. Testing on the actual target devices is always recommended, especially when it comes to Java ME applications.

The Device Emulator 2.0 is part of the Windows Mobile 6 SDK. This emulator does a great job of representing Windows OS devices and can be considered one of the strengths of developing mobile applications to the .NET platform. This emulator provides fake GPS, low battery emulation, and even goes to some length to provide an emulator that tests the behavior of your application with cellular communications state changes (incoming call, hang up, busy signal, and so on). This emulator is a true Advanced RISC Machine (ARM) emulator, which means the emulator runs the same code as real devices.

BREW’s emulator comes with the BREW SDK. However, it only runs on Windows. The testing and debugging of BREW applications is not easy and requires a lot of outside assistance. First, the BREW Emulator (called a Simulator) does not truly emulate the handset’s hardware. Instead, BREW applications are compiled to native code and linked with an x86-compatible BREW runtime library. “Simulation” hides issues related to the actual hardware. In order to avoid these issues, developers should test their applications on real BREW handsets. For this, an application must first be compiled and linked into ARM binary form to run on BREW handset. The compiler/linker is available from Qualcomm. The application must then be digitally signed. Again, another tool from Qualcomm is required. Finally, the application can be uploaded to a BREW handset for testing via another tool (and USB or serial cable) called the AppLoader that is available from… Qualcomm. After the application has tested out, it can then be submitted to Qualcomm for its “TRUE BREW” testing. By the way, once an application has been tested and ready for deployment, the operator that owns the relationship with the handset customer must be convinced to offer your application. They may choose to do more testing of your application before offering it to the customer.

Device Feature Access

Java ME’s access to a device’s fundamental capabilities (like camera for instance) typically requires them to be included in the configuration, profile, and/or optional API for that device. This varies greatly according to platform. Only one of the configurations (CDC) allows native interface access (JNI), so accessing the device’s feature even outside of Java may not be possible.

The .NET Compact Framework is written to the Windows Mobile OS, and so it has access to the same device capabilities as the OS. Which means the .NET Compact Framework application has access to just about everything and the device has and there is usually a convenient API to access it.

BREW allows direct access to the features of the device like the screen buffer, which is important for graphics intensive applications like games. At the discretion of the handset provider, BREW extension modules can add access to non-standard device functions.

Performance

Java ME runs on a virtual machine and its performance can be an issue especially on limited power/processing mobile devices. Like the Java virtual machine, the .NET Compact Framework requires applications to ride atop a runtime environment so performance of .NET apps is considered average by most accounts.

BREW applications, on the other hand, typically have very good performance. This is because the BREW applications run closer to the hardware layer than Java ME or .NET Compact Framework applications.

Platform and Application Provisioning

Getting the application platform and applications onto the devices can be problematic especially since the devices can literally be anywhere in the world.

Java ME’s application provisioning strategy depends on the configuration. An Over-the-Air (OTA) Provisioning specification defines how applications can be obtained on devices that run Java ME’s Connected Limited Device Configuration (CLDC). While the specification is in place, carrier and/or vendor support for the specification and how end-users can obtain their Java ME application is not always seamless (see the blog So, you want to deploy a J2ME app in the US?). There is no OTA specification for Connected Device Configuration (CDC) applications and therefore no consistent technology or strategy for getting these applications to their devices—particularly over the air.

As for the Java ME runtime environment, it is often factory installed by the vendor, especially on cell phones. In some cases, however, the runtime must be installed along with the application by developers or consumers, which adds to deployment frustrations.

The .NET Compact Framework is already installed with Windows Mobile OS, so getting the base application platform in this environment shouldn’t be an issue. ActiveSync allows Windows Mobile OS devices to be updated quickly and easily via connection to a desktop. In addition, over-the-air provisioning is technically possible, but it requires the support of the carrier and/or vendor. In particular, they must provide a device management (DM) server. In its documentation on Windows Mobile OS, Microsoft notes that “Microsoft does not provide an OMA DM or an OMA Client Provisioning server. The OEM, Operator, or a third party must create their own server”.

The effort to get an application to the point of delivery can be extensive with BREW. However, once ready, BREW’s application deployment and provisioning plans are well thought out and where BREW excels, especially for application developers targeting devices in the hands of the general public. The operator manages the available BREW applications for download through the BREW Distribution System (BDS). This system allows handset users to select and download applications over the air and bill them accordingly. The operator and Qualcomm conveniently handle all the distribution and billing details. Of course, this comes at a cost. This document indicates that developers receive 80 percent of the application’s wholesale price while Qualcomm and the operator take 20 percent. This over-the-air provisioning also allows the applications to be quickly updated or fixed. In fact, the handset manufacturers provide new features and fix bugs over-the-air also using BREW extensions.

Other Resident App Options

Again, this is not a complete list of resident application development technologies. The Open Handheld Alliance, whose members include Google, HTC, Intel, Motorola, Qualcomm, Samsung, LG, T-Mobile, and Nvidia, released Android in November of 2007. Android applications are written in Java with an Android Java SDK, but this Java is not Java ME or Java SE. Android applications are targeted to run on a custom virtual machine (Dalvik) and Linux OS. While there is considerable interest in Android, there are no major devices that run this application platform today.

Apple released its SDK for the iPhone. This is certainly an application platform that is impacting mobile development and attracts the business community to think about the iPhone as a possible platform. iPhone SDK comes with xCode IDE, iPhone simulator, Interface Builder and Performance Analysis tools. Sun is also developing a JVM for the iPhone OS.

Still there are other mobile development platforms that may not fit under a heading of “major” but might be worthy of exploration given your particular platform and application needs. Nokia has released a Python interpreter for some of its mobile phones. Lazarus provides a Pascal (Object Pascal) environment for select devices. Straight C/C++ applications can be written for Windows Mobile and other platforms. And regular Java (Java SE) is available on some mobile device platforms and James Gosling has hinted that this is ultimately where Java is heading in the mobile space.

Other Application Considerations

In addition to the considerations listed above in thin and resident application development, there are some additional issues to consider when assembling a mobile application. These issues apply to both browser-based and resident applications, but are unique to mobile development.

Data Entry Complications

A while ago, a story on CBS Sunday Morning featured a Japanese woman that wrote and distributed novels via her cell phone! She wrote an entire novel in six months on her cell phone! Some have been clocked at text entry of about 100 words a minute. Amazing feats considering that while many are becoming more familiar with the user interface of mobile devices, it is often a clumsy interface compared to that of the desktop; especially to those of us that are older than the cell phone.

In 2006, the World Wide Web Consortium came out with the proposed Mobile Web Best Practices 1.0, Basic Guidelines recommendation. In it, they state “User input is typically more or a lot more restrictive on Mobile devices, which may lack pointing devices and usually do not have a standard keyboard with which to enter text.” So what do they recommend? Some of the recommendations include keeping the number of keystrokes required to a minimum, avoid free text entry where possible, and provide pre-selected default values where possible.

This same group indicated that URL’s maybe one of the worst offenses to the mobile Web user interface. The length of the URLs to many web sites makes getting to sites painful using mobile devices.

Many devices also lack a pointing device (mouse, pen, etc.) for interaction. Even when a device has a touch screen, the precision of one’s finger to act as a pointing device on a small screen makes many common desktop UI “widgets” like spin boxes difficult to use. Also, mouse movements are not tracked on most mobile devices. Technically, it is a challenge to differentiate mouse movements and mouse events when there is a touch screen. Therefore, mouse events that trigger tooltips and other such actions are not available. Gestures on mobile devices may even differ from those on the desktop. For example, dragging on an iPhone is for scrolling.

These limitations are not killers, but they do require consideration when building an application for the mobile device and typically cause current Web sites to be revisited before they can be considered “mobile ready.”

Interruptions and Interactions

The mobile device is many things today. In some cases, it’s a camera, text messenger, music player, personal information management system, GPS navigational system, and, oh yes, a phone. Does your mobile application interact well with all these capabilities? Does it need to interact with any of these features? What happens when a user is browsing your site or using your resident mobile application and a cell phone call comes in? As indicated earlier, it is interesting to note that the new Windows Mobile 6 developer platform goes to some length to provide an emulator that tests the behavior of your application as the state of cellular communications changes.

Do you need a picture from the user’s cell phone camera or a position from its GPS? Does the mobile device give your application runtime access to these features? Do these devices and their associated applications interrupt your applications use or vice versa? All points to consider (and test!) when looking at mobile application development. Also, when considering resident- vs. browser-based client application, note that access to these types of features may be tougher or impossible via the browser approach.

Display Differences

Of course, the mobile device display is generally smaller than that of a desktop, but display limitations aren’t restricted to just the number of pixels available. Fewer colors and slower display speeds can also hamper the experiences of mobile users.

The Nokia N series devices have been manufactured to provide great multimedia capabilities. The N82 has a 2.4″ display, LCD screen that offers a 240 x 320 pixel display and 16M of colors. It’s impressive, especially given most competitive mobile products today. But remember, most of our desktops and laptops have at least 800 x 600 pixels (minimum and what most of the web is built to) and 32bits (> four billion colors). Doing the math for you, that’s about 1/6th the display and ½ the color of our “normal” displays.

The display of mobile devices is certainly better than it was five years ago. According to a Report Trend report on mobile trends for 2008, we may have Apple to thank for continued improvements in the display in the not too distant future:

“The idea that User Interface = Culture Code is spreading in the market, and Apple iPhone can be taken as a prime example. Against this backdrop, handset vendors are expected to pursue mergers with UI companies while introducing a variety of new UI technologies, with a view to delivering differentiated OEM UI to the users.”

The display restrictions and limited interfaces provided by mobile devices do not mean these devices can never serve as a powerful instrument to get information and product to customers. Proof positive is again from that fast-thumbed community in Japan. The New York Times reported in January of this year that five of the top ten novels in Japan last year were originally sold on cell phones! If thousands are willing to read a 200+ page novel over the mobile web using a cell phone, I have to believe there are still a lot of applications yet to be written and utilized on the mobile devices and technology at our disposal today.

Time to Get in the Game

With the arrival of so many mobile devices (and by default mobile users), there is no time like the present to bring mobile applications to life. Mobile development technology has arrived and is ready for prime time. As with all application development, the tough part of developing mobile apps is going to be trying to make the best architectural choices and design decisions given the needs and available technology.

The internet gives us an amazing ability to quickly and effectively influence people, friends and businesses. From blogs to message boards and from Yelp to Facebook, the power of user-driven, or “grassroots” content (I’m not a big fan of the term “netroots”), has never been greater.

I’m exited about this year’s election because it is our first real intersection of this power with politics. Sure, Howard Dean first used the internet to raise money, but now we’re seeing mass text-messaging, Facebook apps, Twitter feeds, YouTube uploads, Flickr albums, blog entries, etc.

There are so many innovative and interesting ways individuals can organize, evangelize, and campaign for the candidate of their choice. And so much of it’s driven by user-empowerment through social media.

Here’s an example of how the Obama campaign is equipping their supporters with web 2.0 tools as ways to organize and campaign.

"Here, YOU do it..."

So between now and November, who will have the most interesting example(s)? Who will be more effective? Will social media change politics forever? Or will politics help drive advancements in social media?

And ultimately, will it really matter on election night?

IDC has reported that it believes 1.3 billion (that’s about 1/5 of the world’s population) will be connected to the internet via mobile phone by the end of this year. With that much thin-client capability and connectivity, it’s hard to ignore the mobile browser as a very viable means of putting mobile applications in the hands of the consumer.

Developing for mobile browser however is a tricky business since the choice of browsers running on mobile devices is much greater than in the desktop world. The good news is that thin client development allows many organizations to reuse most, if not all, of the backend of their applications. Getting the apps to the device is also a lot easier. It’s the user interface portion of the application that needs to be addressed to support the mobile browser thin client.

Most of the mobile devices come with the built in browser however more and more devices allow you to download third party browser.

Here is the list of built-in default browsers:

• Android (mobile phone platform) by Google (based on WebKit)
• BlackBerry Browser by Research in Motion (proprietary)
• Blazer by Palm, installed on all newer Palm Treos and PDAs (based on NetFront).
• Danger browser by Danger (proprietary), installed on all Danger-designed devices including the T-Mobile Sidekick.
• Embider by Infraware[4] (proprietary).
• Internet Explorer Mobile by Microsoft
• jB5 Mobile Browser by Jataayu Software, available on Symbian Series 60, Windows Mobile and Linux Platforms
• MOTOMAGX by Motorola (based on WebKit).
• NetFront by ACCESS Co., Ltd. (proprietary).
• Nokia Series 40 Browser by Nokia (proprietary).
• Novarra nWeb (proprietary).
• Obigo Browser by Obigo AB (Sweden), 100% owned by Teleca AB (proprietary).
• Openwave Mobile Browser by Purple Labs (newly aquired from Openwave) (proprietary).
• Opera Mobile by Opera Software ASA (Norway). - Capable of reading HTML and reformat for small screens (proprietary).
• Picsel Browser by Picsel Techologies (Scotland) (proprietary).
• PlayStation Portable web browser by Sony (based on NetFront).
• Safari by Apple Inc on iPhone and iPod Touch (based on WebKit).
• Iris Browser by Torch Mobile for Pocket PCs (based on WebKit).
• Wapaka Browser Java micro-browser by Digital Airways.
• Web Browser for S60 by Nokia (based on WebKit).

And here is the list of browsers that can be downloaded and install on your mobile device:

• Bluelark Bluelark bought by Handspring Inc.
• Deepfish Beta from Microsoft
• Doris by Anygraaf Oy (Vantaa, Finland)
• iPanel for Palm OS,
• jB5 Mobile Browser Beta from Jataayu Software.
• JOCA by InteracT!V, another proxy-rendering free software.
• Minimo by Mozilla Foundation (based on Gecko).
• Opera Mini by Opera Software - supports most features of stand-alone Opera, but can run on less capable phones by offloading memory-intensive rendering to proxy server (based on Opera Mobile running on a server).
• Opera Mobile by Opera Software - supports all modern web standards supported by desktop browsers, including XHTML, CSS2 and Ajax. Has advanced Small Screen Rendering that adapts regular pages to small screen (proprietary).
• Pixo by Sun Microsystems (Pixo acquired by Sun July 2003)
• PocketWeb by tlogic.de
• RocketBrowser Rocket Mobile, Inc.
• SAS
• Stanford Power Browser created in Stanford’s InfoLab
• TeaShark - a free Java-based browser with a desktop-like layout
• ThunderHawk by Bitstream Inc.
• UCWEB by UCWEB Technology
• Universe by OpenMobl Systems
• Webby Mobile by AnOriginalIdea
• WebViewer - a free Java based browser by Reqwireless
• WinWAP by Winwap Technologies

As you can see the diversity is staggering. However there is good news on the horizon – Forrester assures as that:

“over the next few years, the highly fragmented mobile browser market will begin to settle out as regular Web developers target fully capable browsers like Opera Mini and Internet Explorer (IE) Mobile and those based on WebKit.”

Some of the browsers mentioned above such as Opera Mobile or Safari can display HTML (or XHTML) complete with cascading style sheets and client-side scripting. Therefore, the “normal” web site written largely with HTML/XHTML, CSS and client side scripts might be completely accessible in these browsers, even if they don’t always offer the best interface given the constrains of display space and interactivity. However, in other cases, a web site or web application may need to be rewritten or otherwise dynamically converted into an alternative markup/wireless protocol. Again, there are plenty of choices. However there seems to be increased consolidation toward XHTML-Mobile Profile (MP). A lot depends on where (United States vs. Japan vs. …) and when (today, in a couple of years, etc.) you intend to offer your application and on what types of devices. Below is the list of most popular markup options in use today.

Another option for developers of the mobile Web applications is to use Mobile Development Platform such as Netbiscuits or Swift. I will describe how such platform may be used using Netbiscuits as an example.

When a mobile device requests a URL of your Mobile Web Application, this HTTP Request

will be routed to and processed by the Netbiscuits platform. The platform is working similar to a proxy server. In a first step, Netbiscuits will forward the HTTP-request to your Web- & Application-Server (e.g.

Apache, Tomcat, IIS, etc.) which hosts the BiscuitML (BiscuitML is an XML-based markup language used to build mobile web pages with the Netbiscuits Platform)Application. As in a normal web application, you will process the request and retrieve content from a Content Management System or database for example. Instead of creating HTML output, your application has to send a HTTP response back containing a valid BiscuitML document. The BiscuitML markup will then be processed by the Netbiscuits platform and be transcoded into the right markup (XHTML MP, WML etc.), specifically optimized for the mobile device that sent the initial request (Software such as WURFL or DeviceAtlas is used to determine parameters of the device) . Although BiscuitML pages can be static pages, in most cases you would create dynamic applications, of course. You can do that by using your preferred programming language like Java, PHP, C#/VB.NET, etc., whatever you find useful to create dynamic web applications. Plugins for certain IDEs are available as well, which make development with BiscuitML easier. The page content itself and also images that should be displayed inline in the pages of your mobile portal can reside on your Web- and Application server. Other multimedia files, especially those used as downloads (e.g. wallpapers, videos etc.), need to be uploaded to the Netbiscuits Media Repository first.

Below is high level architecture diagram of a Netbiscuits web application:

Mobile Web 2.0?

Now we know how create Web Apps for Mobile devices. Next question is – Can we make it Rich? Can we give customers what they come to expect using regular Web? It may be surprising but the Rich Mobile Internet dubbed Mobile 2.0 is the current battleground , with companies such as Microsoft, Sun and Adobe offering their own solutions. Unlike their desktop counterparts, mobile RIA solutions are not always integrated as part of the browser. So each technology/RIA application may require users to install yet another engine the mobile device in order to load and display. This certainly blurs the line between RIA applications and other native or resident applications for the mobile devices. So what are the options for RIA on mobile platforms?

Flash Lite

Adobe’s Flash Lite is a scaled-down version of Adobe’s ever-popular Flash Player that is engineered specifically for mobile devices.

This RIA technology provides access to a mobile device’s features, including Bluetooth, camera, microphone, and GPS. Developing with Adobe Flash products is considered easy, and a large and active community is available for support and help. Flash Lite’s strength is that it uses vector-based graphics (although it also supports bitmapped graphics) which scales well on screens of varying resolutions—but sometimes at the cost of poor performance. You can conveniently convert desktop Flash content to mobile Flash Lite displays with minimal effort, which helps if your organization already uses a lot of Flash on its web site or in its web applications. Flash Lite can also run on top of other runtime environments such as Java ME or BREW.

Flash Lite has not been widely available on mobile devices outside of Japan and Korea, but this is rapidly changing. Adobe’s 2007 Financial Analyst Meeting notes indicate that over one billion handsets will include Flash capability before the end of 2009. Access to Flash Lite content can be expected to blossom as more carriers and devices support the platform. Most of the major cell phone providers (LG, Motorola, NEC, Nokia, Sony Ericsson, etc.) now ship with products that have Flash Lite pre-installed.

Silverlight

Straight from Microsoft’s Silverlight web site, Silverlight is described as: “a cross-browser, cross-platform, and cross-device plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the web.” What does that mean? Well, Silverlight is intended to be a competitor to Adobe Flash. However, instead of compiled applications (such as Flash delivers), Silverlight applications are delivered to the browser in the form of Extensible Application Markup Language (XAML), which is an XML-based language. The XAML is then read and used by a browser plug-in to display rich content. The plug-in reads the XAML files, which can declaratively specify the UI, and play MP3, WMV, and WMA files without a Windows Media Player or the WMP ActiveX control. Microsoft is expected to make Silverlight available for use with some mobile browsers.

On the positive side, because XAML is text and not a compiled file, supporters say Silverlight applications will be more “searchable” via engines like Google than Flash applications. Silverlight 1.0 is expected to be released for mobile platforms (specifically Windows Mobile 6 platforms and Nokia S60 devices) by the end of the year.

JavaFX Mobile

JavaFX is meant to compete with both Silverlight and Flash. JavaFX is a family of products initially comprised of JavaFX Script and JavaFX Mobile. JavaFX Script (JavaFX for short) is a scripting language meant to provide rich user interfaces using syntax that resembles JavaScript and Scalar Vector Graphics (SVG). As its name implies, JavaFX Mobile is intended to be used on mobile platforms.

JavaFX Script is a scripting language that runs on top of a Java runtime. JavaFX resembles Java, JavaScript, and other scripting languages in some of its syntax, but developers can also use the standard Java syntax and make use of an extensive set of Java APIs. Sun claims that Java is the most ubiquitous application platform for mobile devices and can be found on over 2.1 billion devices—a lead it does not intend to give away to the likes of Silverlight or Flash technology. However, where Silverlight on mobile platforms may be considered a young technology, Java FX is, in fact, an infant technology - Java FX Preview SDK had just been released.

JavaFX Mobile is mostly based on technology which Sun acquired when it bought SavaJe in April last year. Sun has developed Java as a technology which it can license to others. However, JavaFX Mobile has been developed as a product it will sell.

Mobile AJAX

Mobile AJAX is nothing more than AJAX used on mobile browsers, in other words, mobile AJAX is just AJAX. Those who believe that writing native application software is the wrong approach to mobile software development (and that native mobile applications are on the way out) may find additional support for their case in “mobile” AJAX. Some mobile browsers do not provide all the necessary technologies and standards (such as JavaScript, CSS, and DOM) required to create usable AJAX applications on mobile devices. Increasingly, however, and as discussed earlier, many do. Opera Mobile and Mini(version 4), IE Mobile, Mozilla’s Minimo as well as browsers on the Nokia S60 and the iPhone, all run AJAX, albeit sometimes with limitations.

The mobile browsers listed above typically fall on mobile devices classified as smart phones or PDAs (or both). Even on these devices, some limitations of AJAX technologies on the devices can lead to issues. For example, JavaScript performance is quite poor on the first iPhone resulting in slow rendering of AJAX pages (on the new iPhone the performance should be much improved). Also, DOM manipulation and extensive JavaScript execution can tax the devices’ CPU and memory—which can impact the device’s performance and quickly drain its power supply. But as the capabilities of mobile devices increase, the availability and use of AJAX in all its forms may also increase. In fact, mobile AJAX may actually help resolve some of the issues associated with mobile browsing. For example, AJAX can be used to make it appear as if the content loads faster by loading only the necessary parts of a page (typically much smaller), on a mobile device. Also of note, in September of 2007, the World Wide Web Consortium (W3C) and the OpenAJAX Alliance held a workshop on Mobile AJAX.

Mark Shuttleworth, of Thawte fortune and Ubuntu fame, has some (IMHO) neat ideas on how to manage software development efforts that may be interesting to spend a few human processing cycles considering.

http://lwn.net/Articles/292031

Despite the article being written for Free Software and Linux, I think it’s incredibly relevant to all development efforts - read it as if he’s talking about Molecular projects, and not Linux distributions.

Here are two key paragraphs:

One of the key requirements that Shuttleworth sees is the need to “keep the trunk pristine”, by doing integration on the trunk and feature development on branches. Along with this is the need for more and better tests. While not necessarily believing in test-driven development, he certainly leans that way. In any case, all the tests should pass before committing to the trunk.

Many projects do not yet have an extensive test suite, but this needs to change. He quoted a Chinese proverb that “the best time to plant a tree is 20 years ago, the second best time is today”. He mentioned that he is working on a robot that controls the trunk of a development tree. Developers will request it to merge from a branch, so the robot merges the branch and runs all the tests. If the tests pass, it commits, otherwise it gets kicked back to the developer.

This approach sounds pretty good to me.