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.