Comparison of Titanium Appacelarator 3.0.2 and Cordova 2.2

With multiple platforms and multi-vendor devices emerging in the market every other day, developing mobile applications that work seamlessly on all these platforms and devices is becoming challenge for enterprises. Creating the apps using native SDK is proving costly for enterprises both in terms of development and maintenance cost.  So enterprises are looking forward for Cross platform development frameworks with single source base and multi-platform deployments.

In this blog we will look at top 2 frameworks, Titanium Appacelarator 3.0.2 and Cordova 2.2 and compare the pros and cons of each framework.

a.   Cordova

Cordova architecture is elegantly designed to take advantage of HTML5 & UI frameworks and providing them with APIs to access the device features. It uses device Web View to render the HTML files. Its runtime engine allows the access to device features by means of common Javascript API calls. It also provides the feature to extend its runtime capabilities by means of custom plugin architecture. Using the custom plugins, developers can also create their own APIs to invoke native functionality that is not provided by Cordova.

At the runtime Cordova uses ‘Web View’ browser to render UI and execute the app. Developers have the flexibility to use standard UI frameworks like JQuery Mobile, Sencha Touch, Dojo Mobile for creating the UI. Cordova is essentially a markup driven development.

b.   Titanium Appcelerator

Appcelerator Titanium on the other hand uses JavaScript has the core development engine for building the mobile apps. Starting from building the UI to the writing process flow logic, it uses JavaScript.

Titanium comes with JavaScript Interpreter that runs directly on the device O/S. This Interpreter evaluates the JavaScript code at runtime by interpreting the code and combining it with the Titanium API (written in targeted device native language). The JavaScript calls to the Titanium API are mapped to native code in the Titanium framework and generate native components. This allows the Titanium to render the Native rich UI and invoke the device features.

Feature Comparison

The fundamental difference between Cordova and Appcelerator Titanium is that, while Cordova is a HTML5 markup based solution, Appcelerator Titanium is a pure JavaScript API that renders natively. Major differences between them are tabled below:

Cordova

Titanium

Development Framework:

Pro: Cordova uses HTML5, JavaScript and CSS3 for creating application UI and functionality

Development Framework:

Con: Titanium uses pure JavaScript & TSS for creating both UI and functionality

3rd Party Framework Integration:

Pro: Cordova allows use of UI frameworks like JQuery Mobile, Sencha Touch and Dojo Mobile

3rd Party Framework Integration:

Con: Titanium does not allow usage of 3rd party frameworks for UI development

Execution Environment:

Con: Cordova depends on device WebView component to render the HTML5 UI

Execution Environment:

Pro: Titanium Interpreter translates the javascript commands to platform specific commands and renders the Native controls

User Experience/Performance:

Con: Since Cordova uses WebView as its execution environment, UI rendering will be slow

User Experience/Performance:

Pro: Titanium provides near Native experience and performance

Platform Support:

Pro: Cordova supports iOS, Android, Windows Phone, Blackberry, Web OS, Symbian etc. by using UI frameworks

Platform Support:

Con: Titanium supports iOS and Android only

Look & Feel:

Pro: Cordova provides consistent UI across all platforms

Look & Feel:

Pro: Titanium provide native look and feel

Debugging:

Pro: Debugging Cordova application is way better than Titanium ones because they depend on the standard Webkit which can be debugged using web developer tools

Debugging:

Con: Titanium does not provide proper debugging tools/methods

Custom Plugins:

Con: Cordova plugin architecture requires separate custom plugin code to be written for each respective platform using Native language

Custom Plugins:

Pro: Single plugin code can be written using Titanium modules. Titanium will take care of generate the platform specific code for the plugin

Offline Data storage:

Pro: Cordova supports localstorage, IndexedDB, and WebSQL

Offline Data storage:

Pro: Titanium supports localstorage, SQLite embedded database

Conclusion

If you are looking to create an app using your existing team with web development skills and want to port it to various diverse platforms and devices easily, then Cordova is the one to go for.  But if your requirement is provide a rich user experience with native look and feel and platform choice is limited to Android and iPhone then Titanium is right choice.

My article on the same topic can also be read at http://www.articlesbase.com/information-technology-articles/comparison-of-cross-platform-mobile-application-development-frameworks-6796941.html

Kony’s approach towards creation of a Mobile Application Development Platform (MADP) tool

Kony is one among the few MADP tool providers which have support for multi-channel applications development, with an ease. In 2012, Kony was positioned as a “Visionary” in Gartner’s Magic Quadrant for Mobile Application Development Platforms.

This blog provides an overview of Kony’s approach towards creation of an MADP tool with capabilities to meet Gartner’s prescription of a good MADP solution, providing a robust platform for mobile application developers.

Integrated Development Environment (IDE)

Kony provides a sophisticated Eclipse-based IDE with a rich set of features. It provides a drag-and-drop form designing interface by following the open standards. KonyOne studio is completely a configuration-based IDE tool. In the entire Kony application development process, writing manual codes comprises only 10-25% of the effort, while the rest of the development involves drag and drops, data mapping editors, configuring property sheets, adding event handlers; all of this is done using GUI controls in the studio.

Developer can directly use the Kony provided cross platform widgets or dynamically create the widgets and use them. Kony Studio helps in mapping the data between different forms as well as between service input/output parameters to fields in a form.

Integrated native emulators and browsers help in testing the mobile applications quickly. IDE helps in visualizing the application form in different themes and verifying the form design changes very quickly.

It is much easier to develop an application with an i18n support, define i18n key/values for each language and apply i18n keys to the widgets using configuration widgets.

Multi-Device O/S support and integration

With Kony, by using a single and common code base, one can develop and build the mobile application for a wide range of mobile platforms like: iOS, Android, Blackberry, Windows Phone, web OS and Java ME.

Kony provides the platform-specific client runtime component that interprets the code generated by the Kony Studio and renders the output in platform specific native language. This brings a greater UI experience and performance to the mobile app.

By using the user-friendly configuration wizards, one can easily customize the Kony applications as per device specific requirements. One can also define the configuration attributes, both, at a non-platform/device specific level as well as to a particular platform/device specific level.

While developing cross platform apps, the developer spends most of the time by tweaking the margins and paddings across different platforms/devices. Apart from pixel based support, Kony also provides a % based margins and padding feature. This will greatly reduce the application development effort.

Packaging and Provisioning Mobile Apps

With a single code base, one can easily build and package mobile applications for multiple platforms. KonyOne studio provides various device-specific options for packaging the application for a specific platform.

Enterprise Application Integration

Kony has the support for connecting to a wide range of backend enterprise systems. Few of the supported enterprise systems connecting services are: XML, JSON, Webservice-SOAP, SAP, SIEBEL and Mainframes. One can use either XML, JSON, or, SOAP based services, for invoking the backend services.

By using its service definition view feature, one can easily define a service and test it. Also, request and response data mapping across different forms and services can be done very easily.

Middleware Server

It provides a middleware server for hosting the services provided by the KonyOne Platform. The services include connecting to the backend systems for fetching the data, application security, and transaction management. The services which are developed using KonyOne Studio will be deployed to the Kony middleware server.

It has a capability for pre- and post- processing of the service request and response messages and sending only the required information to either backed service provider or mobile device. This chunking of data will reduce the data processing load on the device side.

It also provides caching the requested data at the server side using the Kony provided ‘memcache’ server and sends only required data to the device. This helps to greatly reduce the backend service calls.

Security and Remote Management

Kony provides its own Mobile Application Management (MAM) tool for provisioning, deploying and managing mobile applications. It can easily manage the users, applications and devices from a single point.

Kony, without any doubt, is one of the best MADP complaint platforms available in the market. Kony has the support for developing native as well as hybrid mobile applications. However, the Kony platform is more suitable for developing native applications, by using its platform-specific client runtime to render the output in platform-specific native language. This brings greater UI experience and performance to the mobile app

More detailed explanation on this classification is provided in the thought paper published on iGate website.

Read the full blog post here:http://www.igate.com/thought-leadership/konys_approach_towards_creation_of_madp_tool.aspx

Mobile Application Development Platforms (MADP) Classification

With the phenomenal growth of mobile app adoption, enterprises are faced with challenges to develop and maintain the apps that work on all these diverse platforms and devices to reach wider audience. Developers also face the challenge of maintaining consistent look-and-feel across device/OS.

Mobile Application Development Platform (MADP), as the name suggests, provides development tools and frameworks for building Business-to-Employee (B2E) and Business-to-Consumer (B2C) mobile applications. In addition to providing the tools, these platforms also provide middleware servers to connect and synchronize the data with the back end systems, eliminates the duplicate work by allowing business logic to be written and maintained in one place. You can build tighter integration with device features by using these MADP tools.

On a broad level these MADP tools can be classified into two categories based on their support for MADP characteristics and their development framework & packaging style:

  • Native Build tools: This is a standard and traditional approach being following by the tool vendors who are in mobile market for long time. Products built on this approach provide sophisticated IDE tools to build application using their propriety frameworks. In this approach it is the responsibility of the tool to make the mobile application device agnostic. Top MDAP products that fall under this category are KonyOne, Verivo, Antenna AMPchroma, Syclo etc.,
  • Hybrid Build tools: As the name suggests mobile apps built using these tools depend on HTML5 hybrid frameworks for building device agnostic applications. Products in this category, primarily concentrate more on providing the middleware server features that act as a gateway between the mobiles apps and backend enterprise systems. Most of these tools use REST Web services for integration with backend systems. Top MDAP products that fall under this category are IBM Worklight, Convertigo, OpenMEAP etc.,

The support level of MADP characteristics by these tools should be more or less in line with the below definition as per the category:

MADP Characteristics Support

More detailed explanation on this classification is provided in my thought paper published on iGate website.

Read the full blog post here: http://www.igate.com/thought-leadership/mobile-application-development-platform-tools.aspx

Social Media Integration with Android 4 and above devices

Social media employ web and mobile-based technologies to support interactive dialogue and communication between organizations, communities, and individuals.

Prior to Android 4.0.x (Ice Cream Sandwich), Android was providing its developers the ability to integrate their apps with the social networking sites primarily by using two ways – 1) by using, SocialAuth Android SDK (Android version of SocialAuth Java library) and 2) by using, Facebook-Android-SDK (provided by Facebook)/Twitter4J (Java library for Twitter API). Another requirement is to create test accounts in the social networking site so that you get the keys and ID’s that would be required by your android app. While Facebook-Android-SDK allows users to share data by creating a share button, the SocialAuth Android library could allow users to choose from list of providers. Implementing this used to be tedious and time consuming process.

With the introduction of SDK 4.0.3 (API Level 15), Android allows developer integrate with any social media service, without writing the sharing code themselves, instead by simply creating a Share Intent. This can be achieved by creating a button (or an options menu or context menu) in your activity and launching the share intent on user action (such as button click). The code snippet is as shown below-

       Intent shareIntent=new Intent(android.content.Intent.ACTION_SEND);

       shareIntent.setType(“text/plain”);

       shareIntent.putExtra(android.content.Intent.EXTRA_SUBJECT,”Some subject”);

       shareIntent.putExtra(android.content.Intent.EXTRA_TEXT,”Text to share”);

       startActivity(Intent.createChooser(shareIntent, “Share via”));

With these five lines of code, you are avoiding the lengthy process of

  • Authenticating, credential storage/management, web API interaction via http posts etc.
  • Registration for obtaining keys and ID’s
  • Coding to the corresponding provider API (Facebook/Twitter etc.

 

(By Swati Bhat)

Cross Platform Mobile Apps: Is HTML5 a way forward or due we require consortium for standardizing mobile app development?

We are almost 5 years into release of iPhone that brought smart phone revolution; even today we don’t find a single frameworks or development platform that can make a mobile app work on all available mobile platforms. Whenever a new mobile app project is started, the project team is always posed with a question “What all platforms do we need to support”?

Though native mobile app development is pretty straight forward and allows you to leverage all features of mobile, there are major drawbacks:

  • First and foremost, they cater only to specific device users (either iPhone or Android or BB or Mango etc.,)
  • If we decided to support multiple device platforms, developing and managing the projects for each platform involves huge budget. When we look at cost benefit analysis, this option does not make sense.
  • Third option is go for cross platform development frameworks. But big question is how far these frameworks stand out to their claims of being cross platform?
  • The last option is HTML5, a standard that can make your application run on multiple platforms. But this is still in a premature stage and does not leverage most of the device specific capabilities.

Today there are many frameworks starting from Phone Gap, Rhomobile Rhodes to Titanium that are slowly building support for all the popular mobile platforms, but their support is limited to only popular smart phone platforms (iPhone, Android, BB, Windows).

This reminds me of days before James Gosling came up with ‘Java’, when applications need a platform specific compiler and there are no standardized ways of developing cross platform (windows/linux/mac etc.,) software. Each vendor used to provide his own solution to popular platforms and protocols used by their top clients. ‘Java’ has brought a new wave of thought into software industry, “creating standards and building solutions around standards”. There is no doubt industry has benefited a lot with these standardizations.

So I think time has come for major players in mobile apps and mobile hardware industry to come together and form a consortium to create standards and specifications for a unified mobile application development. One way forward is to start with HTML5 and create new HTML standard to cater mobile phones.