The Android Cloud to Device Messaging Framework

JSON vs XML

It depends on what type of client will be connecting to that web service. If you plan to contact the web service from inside a browser a'la AJAX calls from Javascript, then JSON is the hands-down winner because it essentially is the serialization of Javascript objects. This property of JSON makes it a much better fit for client-side scripting in Javascript. JSON data can be regurgitated right into living, breathing Javascript objects without much hullabaloo. XML and JSON were designed for two distinct purposes. XML originated as a way to give semantic definition to text in documents. JSON on the other hand is specifically for serializing data structures. Both can do what each other can do, but those fundamentally different base design rationales are I think evident in how you work with each type of markup. True, XML can represent data structures, but an example of describing structures like empty arrays in XML shows off how JSON is much better at describing data structures. JSON on the other hand is woefully mismatched to describe semantic meaning behind text in documents, which is where XML excels (think HTML). No easy answer. The requirements of your connection client and the type of data you need to serialize should drive the decision between XML and JSON. JSON for web services answering in-browser callbacks, and XML for, well, XML for when, well.

Android - NDK

NDK allows you to develop parts of your Android application in C/C++.
You cannot develop native-only apps in NDK – your app is still subject to security sandboxing.
Main motivation for native code is performance.

  Using NDK

Android - Building and Running JNI Code

Android Application Runtime Native Daemon Library

Android Application Native Service Lib

Android Application Runtime Service Lib

Android Runtime Overview

Android Startup

Android Application Security

Each Android application runs inside its own Linux process.

Additionally, each application has its own sandbox file system with its own set of preferences and its own database.

Other applications cannot access any of its data, unless it is explicitly shared.

Android Application Framework

Activation manager controls the life cycle of the app

Content providers encapsulate data that is shared (e.g. contacts)

Resource manager manages everything that is not the code

Location manager figures out the location of the phone (GPS, GSM, WiFi)

Notification manager for events such as arriving messages, appointments, etc

Android and Java

Android Java = Java SE – AWT/Swing + Android API

Dalvik Virtual Machine

Dalvik VM is Google’s implementation of Java Optimized for mobile devices

Key Dalvik differences:
Register-based versus stack-based VM
Dalvik runs .dex files
More efficient and compact implementation
Different set of Java libraries than SDK

Android Native Libraries

Bionic, a super fast and small license-friendly libc library optimized for embedded use.

Surface Manager for composing window manager with off-screen buffering.

2D and 3D graphics hardware support or software simulation.

Media codecs offer support for major audio/video codecs.

SQLite database.

WebKit library for fast HTML rendering.

Linux Kernel

Android runs on Linux.

Linux provides as well as:
     Hardware abstraction layer
     Memory management
     Process management
     Networking
     Users never see Linux sub system

The adb shell command opens Linux shell

Android Stack

Android Architecture

Five tips for saving battery life on an Android phone

1. Shut off unnecessary services

I have found the GPS does little to get me through the day. So unless I am using an application that absolutely must have the GPS turned on (and it’s an app that I must use), I leave that feature turned off. It can drain the battery the fastest, so when you need battery life over location discovery, turn it off and leave it off. Turn off WiFi as well. It’s another top offender. Although many might argue against this, I find the speed gain of WiFi is not significant enough to offset the battery drain.

2. Upgrade your firmwar

You would be surprised how much better 2.x is at retaining battery life than is 1.x. It was a significant upgrade on many levels, but none was more significant than battery life. One of the critical issues that was fixed was the ever-present messages application not going to sleep. Now the tool goes to sleep, thus saving your battery from an untimely demise.

3. Turn off notifications

Believe it or not, notifications can seriously drain your juice. I like to leave on notifications for text messages but no more. Turn off both sound notifications and LED notifications to save as much battery as you can. Just remember that you will have to manually check your email to see if anything is new since the last time you checked. Common sense, but you never know.

4. Turn off keyboard feedback

This one may not seem so obvious to most users, but that vibration does use power. As often as you use your keyboard, you’re adding to the decline of your battery power click by click by click. This actually serves two purposes. With the feedback turned off, your keyboard will also respond much faster than it would with it on.

5. Add a task killer

I like Advanced Task Killer Free. This tool allows you to kill any task that is currently running. I actually place a shortcut to this tool on my desktop so that a single press will kill any unnecessary tasks that are slowly chomping away at my battery life. I will randomly hit this during the day (especially when I feel my phone heating up) to kill those background apps. I have yet to experience an app like this taking the phone down with it, so you can generally feel pretty safe using such tools. And the battery life they will save is certainly worth the price of admission (even the non-free apps).

Android tips and tricks

Use voice activation

 

If you’re walking down the street and need to send a text message, you can use the voice activation feature to instruct your Android phone what to do. This is a much better option than potentially falling headfirst into an open manhole or crashing into a pole and winding up on YouTube, only to become the laughingstock of your company and friends. To use voice activation, long press the Search button on the handset (it looks like a magnifying glass) and then speak into the phone. It is also possible to use the voice activation for various purposes, which include the following:

• Text: send text to [recipient] [message] example: send text to stephanie meet me for burritos after work
• Email: send email to [recipient] [subject] [body] example: send email to jack wallen reminder don’t forget to pick up pizza
• Directions: navigate to [location] example: navigate to bazos
• Place phone call: call [contact] [phone type] call stephanie mobile
• Listen to music: listen to [artist/song/album] example: listen to rush tom sawyer moving pictures
• Write note: note to self [note] example: note to self found model for among you book cover
• Search Google: [query] example: jack wallen books
• Open website: go to [website] example: go to amazon
• View a map: map of [location] example: map of munich

App Formatting Problems Faced by Developers

Mobile applications have become the backbone of our mobile communication system these days. But formatting issues can spell big trouble for the developer, especially if he/she intends to create a multi-platform mobile app.

Today, mobile browsers can get easy access to mobile device hardware, which results in improved speed and performance. This and also the employment of advanced user graphics far reduce the need for a platform-specific native mobile application.

The Mobile Web, which implies the use of browser-based mobile applications, offers end users many functionalities and features, but sadly suffers from many issues today. These issues mostly deal with incompatibility and usability problems.

Incompatibility or interoperability issues are a consequence multiple mobile platforms, operating systems, a vast degree of platform fragmentation and browsers. Usability problems arise due to the small form factor of a mobile device, resolution, sound quality, difficulty in operation and so on.

The emergence of smartphones with a multitude of operating systems has further added to the list of worries for the developer.

Cross-formatting issues faced by developers

• The mobile apps industry is highly fragile and fragmented, with developers working on tight schedules and highly limited budgets. To make matters more complicated, there are numerous devices, brands and smartphone apps coming into the market every day. Developers are constantly trying to create more innovative apps for giants like the iPhone, Android and BlackBerry and brands such as Nokia, HTC, Samsung and so on.
• Developers hence start to wonder what they should start on first - the hardware or the software. Budgeting concerns take foreground too, with so many apps working on an unimaginably low budget.
• While you need to stick to a very low budget, it is imperative that your venture succeeds too. Even the slightest slipup is not tolerated and you may end up losing all your investment and hard work on it.
• Yet another point of import is that not all devices go down well with all sections of society. For example, it is generally seen that the business community largely prefers smartphones such as BlackBerry and HTC, whereas the younger generation prefers more flashy devices such as the iPhone. So a developer has to keep his apps open to all these platforms, without having to spend too much on purchasing dedicated software and too much time on debugging issues.
• Then there is the pertinent problem of popular app stores not accepting a developer's apps, no matter how good they may be. Many app stores stipulate stringent restrictions and submission processes, which can further frustrate the developer.

Though most developers continue creating apps because it is their passion, profits are still important to them. Offering a pittance by way of profits and slapping severe restrictions on them can interfere with their creative app writing skills.

Of course, the clear winner in this conundrum is the consumer, who receives a wide choice of devices, platforms and apps. It is this consumer who finally decides the fate of the developer and the performance of his apps in the market.

Pros and Cons of the Android OS and the Apple iOS

With the number of smartphone users increasing each day, there is an equal increase in the number of app developers for the same. Though developers have a whole lot of mobile platforms to choose from, they would most probably select one of the two most sought-after mobile OS’ today, Apple’s recently upgraded iOS 4 and Google’s Android. So, which of these is better for developers and why? Here is a detailed comparison between the Apple iOS and the Android OS for developers.

Programming Language Used

 

The Android OS uses mainly Java, which is the common programming language used by developers. Hence, developing Android gets that much easier for most developers.

The iPhone OS uses Apple’s Objective-C language, which can mostly be unravelled by app developers who are already familiar with C and C++. This being more exclusive, may become a stumbling block for developers who are not too proficient in other programming languages.

Developing Multi-Platform Apps

 

Developing multi-platform apps seems to be the “in” thing today. Of course, you cannot run Java-based apps on the iPhone or Objective-C-based apps on Android devices.

There are tools for multi-platform app development today. But they may not be effective when it comes to actually displaying the original information on another mobile OS. Mobile game developers especially find cross-platforming a huge challenge.

Hence, the only viable, long-term solution here would be to rewrite your app in the device’s own native language.

App Development Platform

 

Android offers developers an open development platforms and allows them the liberty to use third-party tools for app development. This helps them play around with many features of their app, adding more functionality to them. This is vital to the success of this platform, which comes with an impressive range of mobile devices.

Apple, on the other hand, is pretty restrictive with their developer guidelines. The developer here is given a fixed set of tools to develop apps and cannot use anything outside of those. This would eventually curb his creative skills to a large extent.

Multitasking Abilities

 

The Android OS is very versatile and can help developers create dynamic apps for multiple purposes. But this very multitasking ability of the Android OS very often creates problems for the amateur Android developer, since it takes a lot of time to learn, understand and master. This, combined with Android’s highly fragmented platform, poses a real challenge to the Android developer.

In contrast, Apple presents a more stable, exclusive platform for app developers, clearly specifying tools, defining both their potential and boundaries. This makes it much easier for the iOS developer to proceed with the task ahead of him.

Mobile App Testing

 

Android offers an excellent testing environment for its developers. All the testing tools available are neatly indexed and the IDE offers a good model of the source code. This lets developers test their app thoroughly and debug wherever required, before presenting it to the Android Market.

Apple’s Xcode lags far behind Android’s standards here and has miles to go before it can even hope to catch up with the latter.

App Approval

 

The Apple App Store takes 3-4 weeks for app approval. They are also finicky and place many restrictions on the app developer. Of course, this factor has not deterred the several hundreds of developers approaching the App Store every month. Though Apple also offers an open API using which developers can host the app on their site, this is not very effective, as the app cannot get even a fraction of that exposure outside the App Store.

The Android Market, on the other hand, presents no such stiff resistance to the developer. This makes it very convenient for the Android developer.

Payment Procedure

 

iOS developers can earn 70% of the revenue generated from the sales of their app in the Apple App Store. But they have to pay an annual fee of $99 to gain access to the iPhone SDK.

Android developers, on the other hand, only need to pay a one-time registration fee of $25 and can earn 70% of revenue of the sales of their app in the Android Market. They can also feature the same app in other app marketplaces too, if they so wish.

Conclusion

 

In conclusion, both the Andriod OS and the Apple iOS have their own pluses and minuses. Both are equally strong contenders and are bound to rule the app marketplace with their own strengths and positives.

Top 6 Tools for Multi-Platform Mobile App Development

We all know how bothersome multi-platform mobile app formatting can get. Each platform is unique and exhibits different features, capabilities and behaviour. But then, multi-platform apps are truly “in” today, so you as the developer, need to find solutions to develop the best cross-formatted apps, without emptying up all your resources on developing for just a couple of platforms at one time.
Fortunately for you, there are some really great multi-platform developer tools in the market today, using which you can easily achieve your aim. Here is a list of the top 5 dev tools for cross-formatting mobile applications.

1. RhoMobile

 

 

  

 

RhoMobile offers Rhodes, which is an open-source framework based on Ruby. This permits the developer to create native apps, spanning over a stunning range of OS’ and smartphones. The OS’ include Android, Windows Mobile, Symbian, iPhone and RIM, which pretty much covers it all.

The framework supplied by RhoMobile is such that you only need to code once. This code can be used to build apps for most of the major smartphones. Native apps are great for working with available hardware, so your job gets done with ease, speed and accuracy.
RhoMobile also offers developers RhoHub, which is a hosted development environment, and RhoSync, which can be employed as a standalone server to keep all the app data current on the users’ handhelds.

2. PhoneGap

PhoneGap, which won great acclaim at Web 2.0 Expo San Francisco’s 2009 Launch Pad event, is an FOSS environment that allows developers to create apps for Android, Palm, Symbian, BlackBerry, iPhone, iTouch and iPad devices. This platform uses standard web development languages such as HTML and JavaScript.
PhoneGap allows the developer to work with device hardware features such as accelerometer, GPS/location, camera, sound and much more.
PhoneGap additionally offers an Adobe AIR app and also online training courses to help the developer access native API’s and build mobile apps on its own platform.

 3. Appcelerator

The Titanium Development Platform from Appcelerator, which incidentally has a formidable fan following in Twitter, aids the development of native mobile, tablet and desktop apps via web programming languages such as HTML, PHP, JavaScript, Ruby and Python. It now powers over a 1,000 native apps per month. The best thing about Titanium is that if gives users easy access to over 300 APIs and location information.
Additionally, Appcelerator also offers customizable metrics for actions and events. Apps can be totally hardware-based and all app data can be stored either in the cloud or on the device. 

4. MoSync

   

MoSync, yet another FOSS multi-platform mobile app dev SDK tool, is based on standard web programming. This SDK offers the developer integrated compilers, libraries, runtimes, device profiles and other useful tools. While support for JavaScript, PHP, Ruby, Python and such other languages is planned, MoSync now includes Eclipse-based IDE for C/C++ programming.

MoSync offers support for several types of OS’, including Windows Mobile, Android, Symbian, Moblin and even a mobile Linux distro. Support for the iPhone OS and BlackBerry will be coming soon, after the release of MoSync 2.4.

 5. WidgetPad

   

 

WidgetPad is a collaborative, open-source environment for development of smartphone apps. This program uses standard web technologies, such as JavaScript, HTML5 and CSS3.

Included in this platform are source code editing, collaboration, debugging, project management, versioning and distribution. WidgetPad, which is now in private beta, can be used to create apps for the iOS, Android OS and WebOS.

6. Whoop

  

 

This one, though not really a top tool, is interesting. Whoop confidently states that they are “The one-stop mobile app publishing platform for non-developers”. Even if you are not a developer, you can still get some cross-formatting done with Whoop.

Of course, we cannot guarantee that your product will have the same glossy look as those of your geeky coder counterparts, but Whoop is still definitely worth more than just a look.
The Whoop Creative Studio is basically a WYSIWYG editor that lets you easily drag and drop mobile app elements onto it, to achieve desired effects. What is more, you can even export your app in many formats, depending on the OS, including Windows Mobile, BlackBerry, Android, iPhone and more.

Top 3 OS Systems (2011)

Top 10 Smartphones (by Traffic) Dec'09

Android Overview

Android

• Android is an open platform, and it’s open source

• Free, no licensing required
• Develop mostly in Java and XML – C/C++ for Native development (NDK)
• Source code available SDK and core apps http://source.android.com

Key Platform Features

• Multiple Screen Sizes

• User Interface
• Concurrent Applications
• Inter-app Communication
• Speech Input
• Location and Mapping Services
• Hardware Sensors
• Native Development Kit

Multiple Devices, Single App

• Shipping 100K+ devices per day
• More devices = more business
• SDK supports: Many screen sizes/resolutions Screen density independence

Multiple Devices, Single App

Screen Size & Density Breakdown

Note: This data is based on the number of Android devices that have accessed

Android Market within a 14-day period ending on May 17th 2010

http://developer.android.com/resources/dashboard/screens.html

Application Components

 An Android application is actually a collection of several components, each defined in AndroidManifest.xml

• Activities
• Services
• Content Providers
  Broadcast Receivers

Surfacing your UI

Building better Adobe AIR applications

This Post describes ten techniques I've used to improve performance, usability, and security of AIR applications, and to make the development process faster and easier:

• Keeping memory usage low
• Reducing CPU usage
• Storing sensitive data
• Writing a "headless" application
• Updating the dock and system tray icons
• Handling network connectivity changes
• Creating "debug" and "test" modes
• Detecting when the user is idle
• Managing secondary windows
• Programming for different operating systems 

1. Keeping memory usage low

I recently wrote an email notification application called MailBrew. MailBrew monitors Gmail and IMAP accounts, then shows Growl-like notifications and plays alerts when new messages come in. Since it's supposed to keep you informed of new email, it obviously has to run all the time, and since it's always running, it has to be very conservative in terms of memory usage (see Figure 1).

Figure 1. MailBrew consumes some memory while initializing, and uses a little every time it checks mail, but it always goes back down.

Since the runtime does automatic garbage collection, as an AIR developer you don't have to manage memory explicitly, but that doesn't mean you are exempt from having to worry about it. In fact, AIR developers should still think very carefully about creating new objects, and especially about keeping references around so that they can't be cleaned up. The following tips will help you keep the memory usage of your AIR applications both low and stable:

• Always remove event listeners
• Remember to dispose of your XML
• Write your own dispose() functions
• Use SQL databases
• Profile your applications

Always remove event listeners

You've probably heard this before, but it's worth repeating: when you're done with an object that throws events, remove all your event listeners so that it can be garbage collected.
Here's some (simplified) code from an application I wrote called PluggableSearchCentral that shows adding and removing event listeners properly:

private function onDownloadPlugin():void
 {
     var req:URLRequest = new URLRequest(someUrl);
     var loader:URLLoader = new URLLoader();
     loader.addEventListener(Event.COMPLETE, onRemotePluginLoaded);
     loader.addEventListener(IOErrorEvent.IO_ERROR, onRemotePluginIOError);
     loader.load(req);
 }

private function onRemotePluginIOError(e:IOErrorEvent):void
 {
     var loader:URLLoader = e.target as URLLoader;
     loader.removeEventListener(Event.COMPLETE, onRemotePluginLoaded);
     loader.removeEventListener(IOErrorEvent.IO_ERROR, onRemotePluginIOError);
     this.showError("Load Error", "Unable to load plugin: " + e.target, "Unable to load plugin");
 }    

private function onRemotePluginLoaded(e:Event):void
 {
     var loader:URLLoader = e.target as URLLoader;
     loader.removeEventListener(Event.COMPLETE, onRemotePluginLoaded);
     loader.removeEventListener(IOErrorEvent.IO_ERROR, onRemotePluginIOError);
     this.parseZipFile(loader.data);
 }

Another technique is to create a variable that holds an event listener function so that the event listener can easily remove itself, like this:

public function initialize(responder:DatabaseResponder):void
 {
     this.aConn = new SQLConnection();
     var listener:Function = function(e:SQLEvent):void
     {
         aConn.removeEventListener(SQLEvent.OPEN, listener);
         aConn.removeEventListener(SQLErrorEvent.ERROR, errorListener);
         var dbe:DatabaseEvent = new DatabaseEvent(DatabaseEvent.RESULT_EVENT);
         responder.dispatchEvent(dbe);
     };
     var errorListener:Function = function(ee:SQLErrorEvent):void
     {
         aConn.removeEventListener(SQLEvent.OPEN, listener);
         aConn.removeEventListener(SQLErrorEvent.ERROR, errorListener);
         dbFile.deleteFile();
         initialize(responder);
     };
     this.aConn.addEventListener(SQLEvent.OPEN, listener);
     this.aConn.addEventListener(SQLErrorEvent.ERROR, errorListener);
     this.aConn.openAsync(dbFile, SQLMode.CREATE, null, false, 1024, this.encryptionKey); }

Remember to dispose of your XML

In Flash Player 10.1 and AIR 1.5.2, we added a static function to the System class called disposeXML() which makes sure all the nodes in an XML object are dereferenced and immediately available for garbage collection. If your application parses XML, make sure to call this function when you're finished with an XML object. If you don't use System.disposeXML(), it's possible that your XML object will have circular references which will prevent it from ever being garbage collected.
Below is a simplified version of some code that parses the XML feed generated by Gmail:

var ul:URLLoader = e.target as URLLoader; 
var response:XML = new XML(ul.data); 
var unseenEmails:Vector.<EmailHeader> = new Vector.<EmailHeader>(); 
for each (var email:XML in response.PURL::entry) 
{
     var emailHeader:EmailHeader = new EmailHeader();
     emailHeader.from = email.PURL::author.PURL::name;
     emailHeader.subject = email.PURL::title;
     emailHeader.url = email.PURL::link.@href;
     unseenEmails.push(emailHeader); 
} 
var unseenEvent:EmailEvent = new EmailEvent(EmailEvent.UNSEEN_EMAILS); 
unseenEvent.data = unseenEmails; 
this.dispatchEvent(unseenEvent); 
System.disposeXML(response);

Write your own dispose() functions

If you are writing a medium to large application with a lot of classes, it's a good idea to get into the habit of adding "dispose" functions. In fact, you will probably want to create an interface called IDisposable to enforce this practice. The purpose of a dispose() function is to make sure an object isn't holding on to any references that might keep it from being garbage collected. At a minimum, dispose() should set all the class-level variables to null. Wherever there is a piece of code using an IDisposable, it should call its dispose() function when it's finished with it. In most cases, this isn't strictly necessary since these references will usually get garbage collected anyway (assuming there are no bugs in your code), but explicitly setting references to null and explicitly calling the dispose() function has two very important advantages:

• It forces you to think about how you're allocating memory. If you write a dispose() function for all your classes, you are less likely to inadvertently retain references to instances which could prevent objects from getting cleaned up (which might cause a memory leak).
• It makes the garbage collector's life easier. If all instances are explicitly nulled out, it's easier and more efficient for the garbage collector to reclaim memory. If your application grows in size at predictable intervals (like MailBrew when it checks for new messages from several different accounts), you might even want to call System.gc() when you're finished with the operation.

Below is a simplified version of some MailBrew code that does explicit memory management:

private function finishCheckingAccount():void 
{
     this.disposeEmailService();
     this.accountData = null;
     this.currentAccount = null;
     this.newUnseenEmails = null;
     this.oldUnseenEmails = null;
     System.gc(); 
}  

private function disposeEmailService():void 
{
     this.emailService.removeEventListener(EmailEvent.AUTHENTICATION_FAILED, onAuthenticationFailed);
     this.emailService.removeEventListener(EmailEvent.CONNECTION_FAILED, onConnectionFailed);
     this.emailService.removeEventListener(EmailEvent.UNSEEN_EMAILS, onUnseenEmails);
     this.emailService.removeEventListener(EmailEvent.PROTOCOL_ERROR, onProtocolError);
     this.emailService.dispose();
     this.emailService = null; 
}

Use SQL databases

There are several different methods for persisting data in AIR applications:

• Flat files
• Local shared objects
• EncryptedLocalStore
• Object serialization
• SQL database

Each of these methods has its own set of advantages and disadvantages (an explanation of which is beyond the scope of this article). One of the advantages of using a SQL database is that it helps to keep your application's memory footprint down, rather than loading a lot of data into memory from flat files. For example, if you store your application's data in a database, you can select only what you need, when you need it, then easily remove the data from memory when you're finished with it.
A good example is an MP3 player application. If you were to store data about all the user's tracks in an XML file, but the user only wanted to look at tracks from a specific artist or of a particular genre, you would probably have all the tracks loaded into memory at once, but only show users a subset of that data. With a SQL database, you can select exactly what the user wants to see extremely quickly and keep your memory usage to a minimum.

Profile your applications

No matter how good you are at memory management or how simple your application is, it's a very good idea to profile it before you release it. An explanation of the Flash Builder profiler is beyond the scope of this article (using profilers is as much an art as a science), but if you're serious about building a well-behaved AIR application, you also have to be serious about profiling it.

Back to top

2. Reducing CPU usage

It's very difficult to provide general tips about CPU usage in AIR applications since the amount of CPU an application uses is extremely specific to the application's functionality, but there is one universal way to reduce CPU usage across all AIR applications: lower your application's frame rate when it's not active.
The Flex framework has frame rate throttling built in. The WindowedApplication class's backgroundFrameRate property indicates the frame rate to use when the application isn't active, so if you're using Flex, simply set this property to something appropriately low like 1.
As I learned when writing MailBrew, sometimes frame rate throttling can be slightly more complicated, however. MailBrew has a notification system that brings up Growl-like notifications when new messages come in (see Figure 2), easing them in with a gradual alpha tween. Of course, these notifications appear even when the application isn't active, and require a decent frame rate in order to fade in and out smoothly. Therefore, I had to turn off the Flex frame rate throttling mechanism and write one of my own.

Native Vs Web Mobile Application

Introduction

 

Increasing usage of Smartphone as primary device to access web and to stay connected has led to many developers and corporation to rethink their web strategy . Should a business require both a website and a mobile application? Coupled with fact that developer need to think on various deployment platforms like iPhone , Android , Symbian , W7 easily create the paradox of choice.

This report discusses differences between native and web app and some of the cross platform web based mobile mobile application development framework . These mobile application platfrom, are used to create native like applications which can utilize the majority of the native features of mobile devices, such as the GPS, camera, contacts, accelerometer, etc. report aims to make sense of choices available and how one can go about evaluating what suits the need.

Definitions

Native Apps

 

Native applications have binary executable files that are downloaded directly to the device and stored locally. The most popular way to download a native app is by visiting an application store such as Apple’s App Store, Android’s Marketplace, or BlackBerry’s App World, . Native app interfaces directly with the mobile operating system is free to access all of the APIs that are made available by the OS vendor . To create a native app, developers must write the source code (in human-readable form) and create additional resources such images, audio segments and various OS-specific declaration files. Using tools provided by the OS vendor, the source code is compiled in order to create an executable in binary form that can be packaged along with the rest of the resources and made ready for distribution.

These tools, as well as other utilities and files, are normally called the SDK of the mobile OS. Although the development process is often similar across different operating systems, the SDK is platform-specific and each mobile OS comes with its own unique tools. The following table presents the different tools, languages, formats and distribution channels associated with the leading mobile operating systems.

 Mobile Web App

Modern mobile devices consist of powerful browsers that support many new HTML5 capabilities, CSS3 and advanced JavaScript. recent advancement of HTML5 and support of webgl turning into a powerful development standard for rich, browser based applications.

Access to rich media types, geo-location services and offline availability features and many more that are under development, developers are able to create advanced applications using nothing but web technologies can be installed just like other native application. There is other approach to web based development where some website enhance the user experience by creating a mobile website that looks like a native app and can be launched from a shortcut that is indistinguishable from that used to launch native apps.

There is a wide range of possibilities between these two extremes, with most websites implementing their own mix of features. Mobile web apps are a very promising trend. To capitalize on this trend and help developers build the client-side user interface, a growing number of JavaScript toolkits have been created, such as Sencha Touch and jQuery Mobile, which generate user interfaces that are comparable in look and feel to native.

Hybrid App

 

The hybrid approach combines native development with web technology. Using this approach, developers write significant portions of their application in cross-platform web technologies, while maintaining direct access to native APIs when required. The native portion of the application uses the operating system API’s to create an embedded HTML rendering engine that serves as a bridge between the browser and the device API’s. This bridge allows the hybrid app to leverage all the features that modern devices have to offer.App developers can choose between coding their own bridge or taking advantage of ready-made solutions such as PhoneGap – an open source library that provides a uniform JavaScript interface to selected device capabilities that is consistent across operating systems The native portion of the app can be developed independently, but some solutions in the market provide this type of a native container as part of their product, thus empowering the developer with the means to create an advanced application that utilizes all the device features using nothing but web languages. In some cases, a solution will allow the developer to leverage any native knowledge he or she might have to customize the native container per the unique needs of the organization.The web portion of the app can be either a webpage that resides on a server or a set of HTML, JavaScript, CSS and media files, packaged into the application code and stored locally on the device. Both approaches carry both advantages and limitations. HTML code that is hosted on a server allows developers to introduce minor updates to the app without going through the process of submission and approval that some app stores require. Unfortunately, this approach eliminates any offline availability as the content is not accessible when the device is not connected to the network. On the other hand, packaging the web code into the application itself allows for better performance and accessibility, but does not allow for remote updates. The best of both worlds can be achieved by combining the two approaches. Such a system is architected to host the HTML resources on a web server for flexibility, yet cache them locally on the mobile device for performance.

Why consider web or Native app

 

The choice over a web or native (i.e. device specific) application holds important implications on, or is dictated by, a number of launch considerations for any mobile publisher or service provider:
User Experience design – native apps are traditionally superior in terms of performance and the only means to access device attributes such as geolocation API, camera, address book, and accelerometer.

Billing – web apps or mobile-optimized web sites typically offer greater billing options and allow for open distribution, independent of third-party vendors such as carriers or OEM app stores.( some OEM are tightening this door for web apps )

Reach – while mobile app stores attract more active users overall, web apps allow publishers and service providers to serve all smartphone audiences without the compatibility issues facing native app distribution.
ROI – the costs of development and updates are generally higher for native apps, but native app stores are said to generate higher returns thanks to the benefits of larger consumer bases and integrated billing, for example.

Go-to-market – web apps are often quicker to deploy particularly since they are not subjected to distributor approval , although in recent time app stores are fast to reach reducing the distribution time to weeks
Discoverability – with an influx of new applications into proprietary app stores it is increasingly hard to generalize whether visibility is higher over the web or native interfaces.

User analytics – web apps or web sites generally offer more direct, unfiltered access to user behavior data, which in turn enables product cross-selling opportunities and helps build customer loyalty.
Finally the constant evolution of web (e.g. HTML 5) and browser APIs, coupled with the increasing connectivity of native applications, continue to blur the lines between web and native applications in terms of end user experience.

Mobile Web App Platforms

 

over couple of year there has been growth of multiple mobile web based application platform specifically targeting the support for popular mobile devices , these platform specifically address the developers need for cross platform support prompting idea of “Develop once Deploy multiple” below table list the feature set for some of these platform which will be analyzed in in detail in later sections

PhoneGap

PhoneGap is tool for building the mobile apps using the web technology , it make use of:
HTML for layout
JS for accessing device functionality
CSS for rich look and feel
based on W3C standard , PhoneGap offer consistent cross-device API , the app developed using this can be just web pages that have access to the device functionality , apps use CSS for providing UX , PhoneGap enhance UX by making of hardware acceleration in platform like iPhone , support for JS like jQuery, XUI is provided for creating native looking UI

Feature support details

There is usually a server component involved for apps developed , JS calls the server via XHR to get the JSON data , HTM/JS/CSS+ graphic assets are usually residing in the device packaged as part of build process , JS can store retrieved data in SQlLite Db for offline access , some optimization is possible as JS is allowed to cache images and other stuff
PhoneGap support the device functions like GeoLocation , Compass, Accelerometer , Telephony,Camera, Media Playback+Recording, Contacts ,Video with HTML5 video tag, FileIO, vibration , SMS, MAP,Orientation change support

Titanium

Titanium applications are divided into 4 main parts:
1.The html/css/javascript code that makes up the core application logic and UI
2.The APIs that access native device/desktop functionality, analytics or other modular functionality
3.The language-OS bridge that compiles web code into native application code
4.The run-time shell that packages the application for cross-platform distribution.
Once built, Titanium-based applications can be tested, packaged, and distributed through the Appcelerator Network’s cloud services. The Titanium platform is open source, so you may also access the source code to the complete application at any time for your own us

Feature support details

Currently support is limited to Android and iPhone platform , using this platform developer have access to the device features like Geo Location , Vibration ,sound play and record , camera , File IO, multitouch , SMS, Telephony , camera , video play back Contact support to name few .

Rhodes

Rhodes is tool for building the mobile apps using the web technology , it make use of:
HTML for layout
JS for accessing device functionality
CSS for rich look and feel
it also support Ruby which is compiled into Ruby 1.9 bytecode , and provides VM for apps to run on the native platform , this platform consists of two essential component of RhoSync which is sync frame work for access the Ruby based backend. other component being RhoHub which makes building Rhodes applications easier, reducing the overhead of getting started and as well as streamlining ongoing development effort by taking care building the app for multiple platform for user .

Feature support details

Rhodes support device features like Geo Location , Vibration ,sound play and record , camera , File IO, multitouch , SMS, Telephony , camera , video play back Contact support to name few .

Comparing the Different Approach

 

.So to summarize, let’s take a look at all three development approaches compared to each other
Native excels in performance and device access, but suffers in cost and updates. Web is much simpler, less expensive and easier to update, but is currently limited in functionality and cannot achieve the exceptional level of user experience that can be obtained using native API calls. The hybrid approach provides a middle ground which, in many situations, is the best of both worlds, especially if the developer is targeting multiple operating systems.

As can be inferred from the table above, no single approach delivers all of the benefits all of the time. Choosing the right approach depends on the specific needs of the organization
and can be driven by many parameters such as budget, time frame, internal resources, target market, required application functionality, IT infrastructure and many others. But one thing is clear; most companies today face an obvious trade off between user experience and application functionality.

Summary

 

As mobile applications continue to take a center role in the business landscape, organizations around the world are mobilizing a growing number of mission-critical services. Many companies are striving to find the optimal development approach to achieve their goals, but what many are quickly realizing is that each carries inherent limitations and no single approach can address all the growing needs and complexity of the modern mobile enterprise. As this paper points out various approach in application development , the selection of method should be based on one that can harness the benefits that each provides and support not only the development of optimal mobile app for your needs, regardless of their development approach.
Companies forming their mobile strategy must also consider the future of this market;
Further fragmentation of mobile devices and technologies, which in turn, will continue to increase the overall costs and complexities that are associated with mobile application development, integration and ongoing management;

Accelerated mobile adoption by consumers and within the enterprise increasing the requirements around security, scalability and ongoing control;

New device features and complementing technologies such as near-field communication, Geolocation, augmented reality, social networks, and others which will undoubtedly give rise to new types and new use cases of mobile apps;

And new distribution channels for the apps, both public and private, allowing organizations to easily place the apps in the hands of the user, quickly deploy updates and manage its entire portfolio of apps without going through a long submission and approval process.

Taking all these parameters into consideration, companies must choose a solution that is not only flexible enough to support all types of apps but would also support the secure and scalable integration of the apps into the IT infrastructure

Web App vs. Native App

What is a Web App?

To me, a web app is basically a web site that is specifically optimized for use on a smartphone. The site content could be anything from a standard small business brochure site to a mortgage calculator to a daily calorie tracker–the content is irrelevant. The defining characteristics of a web app are that the user interface is built with web standard technologies, it is available at a URL (public, private, or perhaps behind a login), and it is optimized for the specifics of a mobile device. A web app is not installed on the phone, it is not available in the Android Market, and it is not written with Java.

 

What is a Native App?

In contrast, native apps are installed on the Android phone, they have access to the hardware (speakers, accelerometer, camera, etc.), and they are written with Java. The defining characteristic of a native app, however, is that it’s available in the Android Market–a feature that has captured the imagination of a horde of software entrepreneurs worldwide, me included.

Pros and Cons

Different applications have different requirements. Some apps are a better fit with web technologies than others. Knowing the pros and cons of each approach will help you make a better decision about which path is appropriate for your situation. 

Here are the pros of native app development

    * Millions of registered credit card owners are one click away
    * You can access all the cool hardware features of the device

Here are the cons of native app development

    * You have to pay to become an Android developer
    * Your app will only run on Android phones      
    * You have to develop using Java
    * The development cycle is slow (develop, compile, deploy, repeat)

Here are the pros of web app development
    * Web developers can use their current authoring tools      
    * You can use your current web design and development skills
    * Your app will run on any device that has a web browser      
    * You can fix bugs in real-time
    * The development cycle is fast

 Here are the cons of web app development
    * You cannot access the all cool hardware features of the phone      
    * You have to roll your own payment system if you want to charge for the app
    * It can be difficult to achieve sophisticated UI effects

Next Version Of Google TV Will Be Featuring TV Specific Android Apps

The first version of Google TV may be a flop, but the company is currently working on its next version and this could be unveiled at I/O conference next month.
According to an industry source the upcoming version of Google TV has got much more potential than the existing version due to three main reasons:
Android apps: Google has confirmed that it is going to in a tiny while be possible to run Android apps on Google TV. A source claims that Google is building a TV-specific version of the Android Market which can be accessed right into the Google TV interface, and this will be offering Android developers a lot of motivation to build apps for it. Performance:It will incorporate a faster chip set. Better user experience. In the main, the source believes that Android is scheduled for a bang of brand new video content and apps, driven in part by the brand new crop of Android tablets as well as the merging of Android into Google TV.

BlackBerry PlayBook Will Support Android Applications

The BlackBerry PlayBook launching with support for Android applications was considered nothing more than a rumor by some but today RIM has announced in a lengthy press release their upcoming 7-inch tablet will support Android applications in addition to their own BlackBerry Java applications. The Android applications will be accessible through what RIM is calling an app player.
Coming off the heels of announcing prices and release dates for the US and Canada RIM is on a roll this week with updating the public on their PlayBook tablet. With this new update on Android application support the first BlackBerry tablet is starting to look even more attractive let alone the competitive pricing, the PlayBook will start at $499 for a 16GB Wi-Fi only model when launched next month here in the US.

Android Device Usage

Android Device resolutions

Android Tablet Multi-Tasking

Test Automation for Smartphone

Test Automation for Mobile Devices: iPhone, Android, BlackBerry, Windows Mobile

Next Desired Smartphone OS

Checklist for Mobile Applications

No.	Module	Sub-Module	Test Case Description	Expected Result
1	Installation		Verify that application can be Installed Successfully.	Application should be able to install successfully.
2	Uninstallation		Verify that application can be uninstalled successfully.	User should be able to uninstall the application successfully.
3	Network Test Cases		Verify the behavior of application when there is Network problem and user is performing operations for data call.	User should get proper error message like “Network error. Please try after some time”
4			Verify that user is able to establish data call when Network is back in action.	User should be able to establish data call when Network is back in action.
5	Voice Call Handling	Call Accept	Verify that user can accept Voice call at the time when application is running and can resume back in application from the same point.	User should be able to accept Voice call at the time when application is running and can resume back in application from the same point.
6		Call Rejection	Verify that user can reject the Voice call at the time when application is running and can resume back in application from the same point.	User should be able to reject the Voice call at the time when application is running and can resume back in application from the same point.
7		Call Establish	Verify that user can establish a Voice call in case when application data call is running in background.	User should be able to establish a Voice call in case when application data call is running in background.
8	SMS Handling		Verify that user can get SMS alert when application is running.	User should be able to get SMS alert when application is running.
9			Verify that user can resume back from the same point after reading the SMS.	User should be able to resume back from the same point after reading the SMS.
10	Unmapped keys		Verify that unmapped keys are not working on any screen of application.	Unmapped keys should not work on any screen of application.
11	Application Logo		Verify that application logo with Application Name is present in application manager and user can select it.	Application logo with Application name should be present in application manager and user can select it.
12	Splash		Verify that when user selects application logo in application manager splash is displayed.	When user selects application logo in application manager splash should be displayed.
13			Note that Splash do not remain for fore than 3 seconds.	Splash should not remain for fore than 3 seconds.
14	Low Memory		Verify that application displays proper error message when device memory is low and exits gracefully from the situation.	Application should display proper error message when device memory is low and exits gracefully from the situation.
15	Clear Key		Verify that clear key should navigate the user to previous screen.	Clear key should navigate the user to previous screen.
16	End Key		Verify that End Key should navigate the user to native OEM screen.	End Key should navigate the user to native OEM screen.
17	Visual Feedback		Verify that there is visual feedback when response to any action takes more than 3 seconds.	There should be visual feedback given when response time for any action is more than 3 second.
18	Continual Keypad Entry		Verify that continual key pad entry do not cause any problem.	Continual key pad entry should not cause any problem in application.
19	Exit Application		Verify that user is able to exit from application with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.	User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.
20	Charger Effect		Verify that when application is running then inserting and removing charger do not cause any problem and proper message is displayed when charger is inserted in device.	When application is running then inserting and removing charger should not cause any problem and proper message should be displayed when charger is inserted in device.
21	Low Battery		Verify that when application is running and battery is low then proper message is displayed to the user.	When application is running and battery is low then proper message is displayed to the user telling user that battery is low.
22	Removal of Battery		Verify that removal of battery at the time of application data call is going on do not cause interruption and data call is completed after battery is inserted back in the device.	Removal of battery at the time of application data call is going on should not cause interruption and data call should be completed after battery is inserted back in the device.
23	Battery Consumption		Verify that application does not consume battery excessively.	The application should not consume battery excessively.
24	Application Start/ Restart		1. Find the application icon and select it 2. “Press a button” on the device to launch the app. 3.Observe the application launch In the timeline defined	Application must not take more than 25s to start.
25	Application Side Effects		Make sure that your application is not causing other applications of device to hamper.	Installed application should not cause other applications of device to hamper.
26	External incoming communication – infrared		Application should gracefully handle the condition when incoming communication is made via Infra Red [Send a file using Infrared (if applicable) to the device application presents the user]	When the incoming communication enters the device the application must at least respect one of the following: a) Go into pause state, after the user exits the communication, the application presents the user with a continue option or is continued automatically from the point it was suspended at b) Give a visual or audible notification The application must not crash or hung.