Category Archives: Mobile Application Development

Steps to implement TelemetryApp in Windows Store apps using API:


1. Create Telemetry account (
There are two types of telemetry accounts
Telemetry Enterprise Edition – It is a premium account offering by telemetry. For more information Enterprise Edition account page.
Telemetry Community Edition – It is a free account which has very limited features to provide a preview of telemetry for new organizations. For more information please see our Community Edition account page.
telemetry comunity Account

2. After Successful login in to the, initially you will be prompted to add a Board.

create board
A Board (dashboard) is a collection of widgets linked to metrics organized across a user determined layout. Below is an example screenshot how a board looks after adding widgets.

view board


After successful creation of board now we need an agent to communicate with the board.

– Go to Agents tab and select Add agent

Add Agent

– Give a name and click on create

Agent Name

– Copy the Agent token to secure place, you will not be able to see it again.

Agent API tocken


Boards contain widgets. A widget may be a chart, a number or simply a box to contain other widgets

Adding a widget to the board:

a. Select Add Widget option right above board properties

Add properties

b. Now select a widget which is suitable for your application.

sample widgets

c. After adding widget the board looks like below

view widget


Flows are objects that represent the flow of metrics within Telemetry.

widget properties

Adjusting Board Properties:

Here you can title your Board and adjust the settings, or properties, of your Board.

board properties

Widget Properties:

After adding Flows to your Board, you can select a Flow and edit the properties of the selected Flow.

view widget properties


  • All your widgets on a board can be found as a list of layers under the Layers tab.


  • Each widget box can be moved around, resized, and even layered.
  • Select a widget you want to adjust, and on hover you can see options to drag out and resize your box or to move it.
  • You can even have just one or two very large widgets on a board.

Adding a Logo:

  • The best way to personalize and brand your board, is to add a custom logo to your board.
  • From our Image widget, upload an image of your logo directly to your board if you have a paid plan with us.
  • You can then change the background color of the Image widget so your logo looks its best.

Board Backgrounds:

  • Add an image or color background to give your board(s) a custom theme.
  • Adjust your widget background color and opacity so your widgets and background are visible.

Widget Background:

  • Adjust your widget background color and opacity so your widgets and background are visible.

Board Layout:

  • Do you want to create 5 tidy columns on your board but notice you have extra space or one column is smaller or larger than the others? You can adjust the number of rows and columns your widgets snap to under Board Properties.

3. API
a. Accounts:

The account object represents your account. Typically you’ll see this referenced by other objects. This is a read only object.

Account Object




A globally unique static string identifying the object.


The name of your account.


The contact email address.


The contact phone number.


API soft limit.


API hard limit.


API usage of the last 24 hours.


API usage of the last hour.


Users limit.


Boards limit.


Agents limit.


Viewers limit.


API version.


The plan of your account.


The plan expiry date (if any).

To read Account Details


This method will return your current account.

For Account Update


This method will update your current account.

b. Boards

The boards object represent the boards (dashboards) within your account.

Boards are collections of widgets and their flows contained together for display.

Board Object




A globally unique static string identifying the object.


The name of the board.


The theme for the board.


The number of columns in the board grid.


The number of rows in the board grid.


An array representing the native size of the board.


A string with the aspect ratio of the board.


Whether to show the board name at the top of the board or not.


The tag for the default channel for the board.


The external margin of a widget, defaults to 3.


The internal padding of a widget, defaults to 8.


The size of the font to use, can be ‘small’, ‘normal’ or ‘large’.


The font family to use, defaults to ‘normal’ which uses the theme default.


The background color of the board.


The background image URL of the board.


The background color of the widgets.


The color of the widgets’ titles.


The size of the widgets’ titles.

Boards Listing


This method will return a list of all boards on your account.

Board Details


This method will return a specific board on your account by id.

Export Board


This method will return a specific board on your account by id and also its widgets details.

Create a Board


This method will create a new board.

Import a Board


This method will create a new board and widgets based on the json input.

Update a Board


This method will update a board object.

Delete a Board


This method will delete a board object.

c. Widgets

Widgets are mostly hidden from the Telemetry web interface however they’re

Critical elements to position flows within a board.

Widget Object




A globally unique static string identifying the object.


A globally unique static string identifying the board that the widget belongs to.


The variant of the widget: barchart, box, bulletchart, clock, compass, countdown, funnelchart, gauge, graph, grid, icon, iframe, image, log, map, multigauge, multivalue, piechart, scatterplot, servers, status, table, text, tickertape, timeline, timeseries, upstatus, value, video, waterfall, weather.


The column of the top left of the widget on a board.


The row of the top left of the widget on a board.


The width of a widget in columns.


The height of a widget in rows.


The layer sorting order of the widget within the board.


The background color of the widget. Possible values are:
“default” => The background will be dark/light depends on the selected theme of the board
“none” => Transparent background
Hex code (e.g. #09ab3f) => Hex code of a color.


An optional parameter that specifies a specific renderer to use. Things like changing a line chart from a spline to an area. See the renderer options below.

List all Widgets


This method will return a list of all widgets on your account.

Display a Widget


This method will return a specific widget on your account by id. It also return an array of flows for the default channel of the board. There’s an optional channel_id parameter to return the flows for that channel instead of the default.

Create a Widget


This method will create a new widget.

Update a Widget


This method will update a widget object.

Delete a Widget


This method will delete a widget object.

Renderer Options

Different Widgets support different renderer options. You can select the renderer using the Telemetry Manager when designing a board. When embedding a specific widget however in order to use something other than the default renderer you must specify it in the embed tag.

The following renderer options are supported for the following flow variants:




gauge, heading


circle, combined, vertical, horizontal


line, spline, area, bar, scatter


equal, number, label, icon


spline, line, bar, area


line, spline, area, bar, scatter

4. Implement telemetry in Windows store or Phone app using API

In this article I am using bar chart to explain how to implement in windows store apps. The procedure is same for all widgets.
Bar Chart:

A bar chart is a stack of horizontal bars, each with a label, value and colour. The value determines the length of the bar. The bars will be sorted from top to bottom in terms of length by default. You can choose to turn off sorting. Send data with a hash of bars containing an array with each bar as a hash. Bar charts can display a maximum of 20 bars. There may be less than 20 shown if your widget box is too small. Resize your widget box if all your data is not being displayed.








array of objects

The bars



CSS color

The color of the bar.




The text to overlay on top of the bar.




A number representing the value of the barchart. This will determine the length of the bar.




The min possible value of the bar.




The max possible value of the bar.




Whether to sort the bars by value or not. The default is true.

– Adding a Bar Chart into board.
Log in into, go to boards and select edit board.

edit board

– Now click on add widget, under charts select Bar Chart.

add widget bar chart

select bar chart

After adding Bar chart into board, select the bar chart on board, now go to widget tab in properties window and expand general tab.

bar chart properties

Copy the Flow Tag to a note pad.

bar chart flow tag name

Now we have a widget to display the flow data on board.

5. Create a Windows store or Phone app (Phone 8.1 or Windows 8.1) project in visual studio to send flows to bar chart from windows app, in my example I created a Universal Hub App project.

create windows store app

Open HubPage.xaml.cs, under load state method write the following code to send the flow data to recently created Bar Chart.

To use API we need the following information

  • URI
  • API Token (refer step 2 under Agents)
  • Flow Tag (In earlier step we copied flow tag for bar chart)

URI = “ Tag/”;

For Authentication/Authorization we need to pass Agent Token as user name and password as blank in POST method.

Prepare list of bars information:

In this example I am using bar chart 

public class Bar
            public string color { get; set; }
            public string label { get; set; }
            public int value { get; set; }

        public class BarRootObject
            public List<Bar> bars { get; set; }


BarRootObject barRootObject = new BarRootObject();
            barRootObject.bars = new List<Bar>();
            var bar = new Bar();
            bar.color = "#66CC00";
            bar.label = "Users";
            bar.value = 4;

            bar = new Bar();
            bar.color = "#FF8900";
            bar.label = "Sessions";
            bar.value = 30;

            bar = new Bar();
            bar.color = "#FFFF33";
            bar.label = "Crashes";
            bar.value = 26;

            bar = new Bar();
            bar.color = "#FF0000";
            bar.label = "Exceptions";
            bar.value = 75;

In above code I am passing four bars information which include colour, label and value (If you want to know/pass more properties info please refer Bar charts Flow Object table above).

POST Method:

string URI = ";;
            HttpClient httpClient = new HttpClient();
            httpClient.DefaultRequestHeaders.Authorization = CreateBasicHeader("**Replce with Agent Token**", "");
            metrics metric= new metrics();
            metric.values =new int[]{10,70,25,5};
            metric.labels = new string[] { "A", "B", "C", "D" };
            metric.colors = new string[] { "#1F1F33", "#669900", "#7A0000", "#334C4C" };
            string postData = JsonConvert.SerializeObject(metric);
            StringContent c = new StringContent(postData, Encoding.UTF8, "application/json");
            httpClient.MaxResponseContentBufferSize = 100000;
            var result = await httpClient.PostAsync(URI, c);
            var content = await result.Content.ReadAsStringAsync();


Method for creating Authentication Header Value:

public static AuthenticationHeaderValue CreateBasicHeader(string username, string password)
            byte[] byteArray = System.Text.Encoding.UTF8.GetBytes(username + ":" + password);
            return new AuthenticationHeaderValue("Basic", Convert.ToBase64String(byteArray));

6. Run the App

Now go to telemetry dashboard and check the bar chart has added four new bars with values.

bar chart with bars info

Cross-Platform Mobile Application Development Tools: Interest and Capability Expected to Grow

Cross-platform development tools for mobile applications will become more capable
through 2012, and increasingly popular through 2015.


Cross-platform mobile development tools will become more numerous, more capable and more popular in the near term. Architects, developers and strategists should consider such tools to deal with the growing challenge of supporting mobile applications on several platforms.

Key Findings
  • Cross-platform mobile application development tools will become more numerous and more capable, driving a slow shift from platform-specific to platform independent application development technologies.
  • Until mobile platforms start to consolidate, the increasing demand for mobile
    applications will require cross-platform tools to manage the cost of addressing
    multiple platforms.
  • New Web standards will enable mobile Web technology to address a wider range of mobile applications needing features such as offline operations and persistent data.
  • Consider cross-platform tools for new mobile applications that must address two or more platforms.
  • Mobile Web technology will evolve into a more flexible, capable and broadly
    available cross-platform mobile development tool. Official standards will take
    several years to become established, but developers may be able to adopt some elements of the technology, as many platforms will implement parts of the standards before they are finalized.

What You Need to Know
The proportion of mobile applications that are developed using cross-platform tools will grow through 2012, as more tools become available and all tools become more
sophisticated. All mobile application developers should consider such tools to maximize their addressable markets and provide some degree of insulation from the mobile platform wars.

Mobile application development is important for corporations delivering applications to
their employees, and for the growing band of developers wanting to profit from mobile
application stores. All mobile developers face a difficult trade-off between application
sophistication and audience size. If they develop for a specific platform using its native tools, they can create excellent functionality, but the application will be limited to one platform or even specific device models within that platform. In 2009, cross-platform mobile tools offered a much greater range of target devices, but often at the cost of reduced functionality.
However, the options available to developers are increasing with the emergence of more and better cross-platform mobile tools. Such tools abstract many aspects of native platform APIs, such as the user interface, tasking, networking, handset services and persistent storage. Such abstractions are seldom perfect or complete; despite this, they are important because they offer mobile developers more flexibility in the trade-off between functionality and audience size. Several of these tools also extend the native platform with support for features such as rich media and enhanced interfaces, allowing more compelling applications.
Adobe Flash Player
Summary: Flash Lite is Adobe’s current mobile subset of Adobe Flash Player (Flash
Player). Starting in 2010, Flash Lite will be replaced by two Flash Player versions for
mobile devices. Adobe Flash Player 10.1 (Flash Player 10.1) will provide a PC-compatible Flash experience on high-end devices, such as smartphones and Web tablets, with processor speeds exceeding around 600MHz. Flash Player 10.1 is intended to provide access to mobile device APIs such as touchscreens and accelerometers. Flash Lite will continue to be available on lower-end devices to provide a subset of Flash Player capability.
Platforms: In 2011, Flash Player 10.2 is available on Windows, Macintosh and Linux devices; Flash Lite is available on smartphones and some enhanced phones. Application Types: Rich Internet applications.
Target Market: Adobe’s goal for Flash Player 10.1 is for it to run on about 50% of
smartphones, which would equate to over 300 million Flash-capable devices shipped in
2012, although the number that actually have Flash Player installed could be rather
smaller, perhaps 200 million. Approximately 75% of handsets shipped are Flash-Lite capable, but fewer handsets ship with Flash Lite preinstalled.
Adobe AIR
Summary: Adobe AIR provides a superset of Flash functionality and runs rich Internet
applications on the desktop, rather than in a browser. AIR is available on desktop
systems, and Adobe plans to develop a mobile version for some platforms starting with Android in 2010, and extending to other platforms in 2011.
Platforms: Similar to Flash Player 10.2.
Application Types: A broader range of mobile applications than Flash.
Target Market: We expect AIR to be runnable on approximately the same target devices as Flash Player 10.2 — i.e., 50% of smartphones.
Java Platform, Micro Edition (Java ME)
Summary: Java ME is the most mature cross-platform mobile environment. Two basic
versions of Java ME are available:

  • Connected Limited Device Configuration (CLDC)/Mobile Information Device Profile (MIDP) supports basic and low-end enhanced phones.
  • Connected Device Configuration (CDC) supports high-end enhanced phones,
    smartphones and consumer devices .

A Lightweight User Interface Toolkit (LWUIT) consisting of code and tools was released in 2008 to address the challenges of creating portable mobile user interfaces on mass market devices. Java ME is available on a very wide range of devices, but does not
entirely solve portability problems because of individual device variations and the optional Java packages that may not be installed on all devices. As Java ME has matured, the baseline capability of the environment has continued to grow. Influential devices, such as BlackBerry, use Java as their primary development environment.
Java ME is now an open-source technology controlled by the Java community process
(JCP), which is dominated by mobile industry representatives such as network operators and handset manufacturers; therefore, its evolution is somewhat biased by these industry representatives’ concerns.
Platforms: Mobile handsets and consumer electronics.
Application Types: A very wide range of applications can be developed in Java ME. The platform is typically used in situations where the application complexity demands client side code and where the application must run on the widest possible range of handsets. Java ME applications include games, mobile payment, utilities and media applications.
Target Market: Various versions of Java ME are available on approximately 80% of mobile devices, which indicates that shipments could be more than 1.2 billion units a year by 2012.
Summary: JavaFX is a rich application development tool that is layered on Java ME. A
desktop version is already available; a mobile version was demonstrated on some
platforms in 2009 and is intended to run on handsets with 200MHz or faster processors. JavaFX is immature and has very limited support in the mobile marketplace; its success is uncertain. Even in optimistic scenarios, we don’t see significant take up occurring before 2012.
Application Type: Rich Internet applications and general-purpose applications if Java ME features are used.
Platforms: Windows; Mac OS X, Linux PCs in 2009; mobile handsets starting in 2010.
Target Market: We estimate the proportion of mobile devices capable of running JavaFX to be approximately 40% of total shipments; and if we assume modest success with 30% of potential handsets having JavaFX installed, the number would be approximately 200 million units a year by 2012. Because JavaFX has very limited developer/operator and handset manufacturer acceptance, the installed base is likely to be much smaller than the addressable market.
Summary. Microsoft Silverlight is a general-purpose environment with a strong set of
features for media such as video, graphics and animation, which competes with Adobe
Flash and Adobe Air. Mobile Silverlight will be a subset of desktop Silverlight, and has
been announced (but not delivered) for Windows Mobile and Nokia S60 platforms. No firm release date for mobile Silverlight has been announced, so enterprises should not make plans for the technology at this time.
Platforms: Windows PCs, mobile versions are planned only for Windows Mobile, Moblin
and Symbian.
Application Types: Rich Internet applications.
Target Devices: Silverlight-capable devices will likely include all Windows mobile handsets plus a proportion of the high-end S60 handsets. This could total more than 200 million handsets a year shipped by 2012 (assuming the product is released by then).
Summary: Qt is a mature cross-platform development framework and toolkit that Nokia acquired through its purchase of Trolltech in 2008. Qt applications are written in C++ so can leverage mainstream development skills. A new member of the Qt technology family, known as Qt Markup Language (QML), likely will be released in 1H10. QML is a declarative user interface development language that will make Qt accessible to a wider population of Web developers. Qt abstracts a wide range of operating system services, including 2D and 3D graphics, tasking, networking, threading and inter application communications. Qt will become the preferred Symbian and Maemo development framework for native applications, and the latest version of Qt will be part of open Symbian in 2H10. Although Qt is a powerful tool, it has been a relatively niche application. We estimate the worldwide mobile Qt developer population in 2009 was only a few thousand individuals. We expect Nokia will deliver improved mobile Qt tools in 2010, and Qt will become a de facto standard for Ovi application developers.
Platforms: Windows PC, Mac OS X, Linux, Windows CE, Windows Mobile, Open Symbian, and Maemo.
Application Types: Qt is a rich and flexible environment that has been used to develop a wide range of applications — for example, from KDE and Google Earth to embedded
graphical applications in consumer electronics.
Target Market: In mobile terms, Symbian, Maemo and Windows Mobile are viable Qt
mobile targets. More than 100 million handsets shipped in 2009, and more than 350
million are expected to ship in 2012.
Enhanced Mobile Web
Summary: The Web was originally designed for connected applications with limited
processing being carried out on the client. However, proprietary browser extensions, such as Google Gears, already support offline Web applications, persistent storage and multitasking to make applications more responsive. The latest draft of HTML 5 from the World Wide Web Consortium (W3C) also proposes extensions for offline Web applications, including persistent storage, an embedded SQL database inside the browser, server initiated events, enhanced JavaScript, and an improved user experience, all of which would be very valuable to mobile developers. Standards are unlikely to be formalized before 2015 (if then), although companies such as Google, Research In Motion and Opera are strong supporters of such Web extensions and are already adopting them. Mobile browsers based on the latest WebKit code are likely to exploit pre standard HTML 5 features. Improvements to offline mobile Web technology will also benefit related technologies such as widgets (installable Web applications). We believe a future enhanced mobile Web standard will be attractive to a large number of developers as a standards compliant alternative to tools such as AIR, JavaFX and Silverlight.
Application Types: In 1H09, most smartphones supported Ajax browsers and could deliver simple Web functionality, such as forms and media. The HTML 5 standard, combined with JavaScript extensions for multitasking, would enable future Web applications to support all six styles of mobile architecture and to create a much richer range of applications.
Target Market: We expect that a future enhanced mobile Web platform will be available on all smartphones, where license conditions permit, and on a proportion of high-end enhanced handsets. Prerelease HTML 5 features are already being deployed and could be shipped on more than 400 million handsets a year in 2012. However, the absence of formal standards implies significant fragmentation through 2015, and possibly beyond.
Other Tools
The platform-independent tools described in this research were selected because we
believe they will be important or interesting to our clients. Such lists are invariably
incomplete. A selection of other tools that are more niche, and that may be of interest to some developers, include:

  • Python — a popular and very powerful open-source scripting and application
    development language available on Windows, Linux and a number of mobile
    platforms, including a port by Nokia for the S60 platform. Mobile Python has gained very little traction to date. It will likely grow in importance as it is extended to access handset-specific APIs and features, although the lack of a single mobile Python standard implies inconsistent implementations and portability issues. Python may also gain some traction in Linux-based netbooks. However, interpreted languages like Python may impact mobile battery life and may be best for prototyping, rather than production, systems.
  • Ruby — another very popular high-level Web application development language, a subset of which has been used as the basis of Rhomobile Rhodes, a platform independent mobile application development tool that supports iPhone, BlackBerry, Windows Mobile, Android and Symbian. As with Python, we expect that performance issues may be a challenge, as well as some strategic risk, because the product is available only from one small vendor.

Various platform-independent versions of Basic are available for mobile development.
Examples include NS Basic and tools such as Mobile Basic, which implement a Basic
environment in Java ME. Although platform-specific Basic such as Visual Basic for
Windows Mobile have been popular, platform-independent Basic has gained little traction among mobile developers.
A number of proprietary tools have emerged from companies that are attempting to make mobile application development simpler or faster by tool technology and also integration with App Store submission workflows. Selected examples include:

  • Appcelerator — multiplatform application development using JavaScript APIs with proprietary extensions.
  • Mobil On Services "BuildAnApp" — hosted menu-driven application generator for simple applications.
  • MotherApp — HTML-like programming and application generation for multiple
  • Genuitec’s MobiOne — an Eclipse-based mobile Web integrated development
    environment for HTML 5/Cascading Style Sheets (CSS)/JavaScript mobile

Such tools should generally be treated as tactical decisions, because they may lock
developers into small companies, proprietary technologies or inappropriate business
Corporate developers can also consider a range of mobile enterprise application platform (MEAP) tools, many of which are packages of technology rather than simple development tools. A typical MEAP includes middleware, development tools, server-side replication, simple security, simple software distribution and management. Many MEAP products support multiple platforms and are usually intended for corporate applications. MEAPs commonly include prebuilt applications and integration with popular packages, such as SAP. Other examples include those from Antenna Software, Sybase, Syclo, Spring Wireless and Pyxis Mobile.

Recommended Reading
"Magic Quadrant for Mobile Enterprise Application Platforms"
"Magic Quadrant for Mobile Consumer Application Platforms"
"Mobile Architectures 2009 Through 2012: A Trend Toward Thin"

Strategic Planning Assumption(s)
By 2013, new HTML standards will be widely deployed in mobile browsers, allowing Web applications to manage persistent, structured data.

Well, this report includes several misleading statement.  It states that Silverlight runs only on windows, in fact it runs on: Apple Mac and Windows.  In reality it could be stated that Silverlight also run on Linux, but in this case using the Novel  implementation of Silverlight (it is open source) for Linux called Monlight/(Mono platform).  This is significant from development and maintenance, because the same code that is used for the Windows and Mac desktop could be used for the Linux desktop.. In addition same code that is used on the Win server could be deployed to a Linux server if required.  As for the mobile version of Silverlight, it is planned for Microsoft Mobile in Q3, Symbian (Nokia) in 2010 (not sure when)

Source: GR

Mobile Application Development : Design and Tools

In late 1990s and early 2000s, developers as well as users  were confused about the choice of the platform  for their applications. They had to decide a solution from two choices – (1) An installable PC based software or (2) a Web application. Web applications was the unpopular choice for a few reasons – among them, Bandwidth limitations and a general insecurity about how safe using a software on internet would be.

But as the years passed by, the requirements too changed. When people started working collaboratively, (which was made much easier with the internet and with bandwidth growth) people slowly started moving into web based applications. Web based Emails are possibly the first web applications used widely. Software companies started developing cross-browser compatible web applications. Now Web 2.0 has changed the perspective of ’software’ totally. And Hybrid applications became possible with APIs etc.

Likewise, in Mobile development, there are three ways to create  applications. (1)Installable (or Native) Mobile applications. (2)Mobile browser based applications – which are websites optimized for Mobile browsers and (3) Hybrid mobile applications.

Three Design Approaches – Native, Web or Hybrid(blended)
Native – Performance, offline mode, findability, device attributes and monetization

Native design builds the code using the code library provided by the phone vendor.  Four primary targets are IPhone, Android, MS Windows Mobile and Blackberry. Native (installable) applications resides in your cell phone, and you  launch it directly from there, with whatever search parameters  are stored within your mobile (E.g.. The names of the 50 states in the USA, your favorite locations, daily weather, etc.). Except for free text search, all of  the search parameters can be stored in the mobile – OR they can be updated just one time.  The communication between the Data/Web server and the mobile phone could be drastically reduced. An application like a stock portfolio can be created within your Phone and stored. Every day you just need to update the stock prices. You need not download the entire portfolio each day. Also, the application resides within the phone, and can access your phone’s features such as your camera, phone book /contacts, etc. The disadvantage is obviously the development cost. No two mobile platforms can share the same mobile application, and there are too many Mobile operating systems (or platforms) existing in the market. If you develop a mobile application to market it widely, you need to develop that in J2ME (for phones that support only Java with no loaded OS), Symbian, Mac iPhone, Android, RIM, WebOS( for Palm pre), LinMo and Windows mobile.


  • Application runs faster
  • Able to run offline (provided that all the needed data can exist on the device)
  • Able to use all the phone capabilities – e.g. Shake, Accelerometer, Camera,


  • Need to build for each target platform
  • Must deploy like Client server.
  • IPhone Apple Store is controlled by Apple

Web based applications are built using a web toolkit.  Nothing is loaded on the device.  It uses the device browser to load and run the application.  It can be shown as an icon on the desktop that links the web server. The advantage of a mobile browser based application is the low development cost, and the disadvantage is the bandwidth limitations and the limitations of Mobile websites, which does not access your Phone’s components like your Address book, Camera, etc. Mobile Brower based applications are slow due to the bandwidth limitations and will eat up your data usage in your phone plan. Also, the user needs to remember the URLs and type it, which every cell phone user knows is just plain  hard. One advantage is that the development cost is low since the developer only needs to consider how to make it compatible with most mobile browsers, and not each type of cell phone. Also, now that many Mobile browsers support HTML and smart phones come with bigger screens to see full sized websites, and users can zoom in and out. We have keyboards too to manage this. But, if you want to browse websites, you can do that in your tiny Netbook, which you always carry with you, right?


  • Build once for multiple target platforms
  • Deploy changes on the server side with no client changes


  • Some limitations on functionality and features.
  • Lower performance
  • Cant run offline

They are Applications that use BOTH browser interfaces and native mobile components. The blended model builds a native application but uses HTML to provide some content and features. With HTML5 and JQuery, now the browsers are becoming capable of accessing a phone’s built in features like contacts, camera etc. Finally, what would be the disadvantages of  hybrid mobile applications? Two things comes to my mind…(1) Application security, and (2) the learning curve for the developers. Mobile developers need to know HTML and Web developers need to know mobile phone APIs.


  • Existing web content (IF implemented properly) can be reused to reduce costs of native development
  • Maintenance overhead potentially reduced by less frequent updates


  • It has all the drawbacks of native development, although potentially diminished (this depends on how much of the functionality is in the native portion of the app and how much is in the web content portion)
  • Properly designed web apps that can be reused without overhead are more of an ideal than reality

Following is the chart of different mobile development approaches used in the industry.


Some of the concerns for the business managers are:

  • Disconnected operation IS a big deal. Not for the business traveler so much, but for the people at the jobsite and the people working away from the office on a regular basis. On the jobsite, wireless coverage is often limited, particularly in remote areas and inside structures. For mobile workers (FedEx delivery people, telecoms workers, etc.) wireless access might not be guaranteed. With web-based mobile apps, no connectivity means the applications just won’t run. With proper design, native apps can always be accessible, even though the user may have to defer connectivity until he returns to the office.
  • The mobile apps will have narrow functionality. The best approach is to have a large number of small apps, rather than the traditional model of large applications with tons of functionality. This narrow functionality in turn results in a very narrow user base for each app, which in turn minimizes the need for apps than run on any device. There won’t be many apps that will have wide spread usage.
  • Designing for the lowest common denominator will mean that all applications will have limited functionality. To me, it makes a lot more sense to evaluate each app on an individual basis, rather than trying to come up with a one size fits all model. For an app with a broad user base, it makes sense to build something that will run on any device. But to say that an app used by 1% of the workforce has to sacrifice functionality and usability just so everyone can run it from their own personal devices doesn’t make sense.

The bottom line –

  • Go native on apps with narrow (small user base) functionality, and issue standard devices (one or two standard device types) to the users that run those apps
  • Go web on apps with a large user base, and let the users install the apps on their own devices
  • Hybrid apps are yet to see the light but I believe this is where the future is…

The choice of platform solely depends on your goals. You need a UI that is either:

1. truly usable
2. inexpensive

For option 1, native is the best solution; web is ruled out by its inability to optimally exploit the device.
For option 2, web is the best solution; native is ruled out by its costs; it is to be mentioned though, the price for this is a very austere UI.

Native Application are comparatively easier to maintain, whereas application written to run across multiple platforms may have complex code thus maintenance may not be that simple and testing will have to be intense to ensure a fix for particular platform does not impact anything else.

The advantage of non-native applications is one code base. one iteration of fix will take care of multiple platforms.

The very essence of leadership is that you have to have vision. You can’t blow an uncertain trumpet. – Theodore M. Hesburgh