Tag Archives: Mobile

Steps to implement TelemetryApp in Windows Store apps using API:


1. Create Telemetry account (telemetryapp.com)
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 telemetryapp.com, 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

GET https://api.telemetryapp.com/account

This method will return your current account.

For Account Update

PATCH https://api.telemetryapp.com/account

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

GET https://api.telemetryapp.com/boards

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

Board Details

GET https://api.telemetryapp.com/boards/:id

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

Export Board

GET https://api.telemetryapp.com/boards/:id/export

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

Create a Board

POST https://api.telemetryapp.com/boards

This method will create a new board.

Import a Board

POST https://api.telemetryapp.com/boards/import

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

Update a Board

PATCH https://api.telemetryapp.com/boards/:id

This method will update a board object.

Delete a Board

DELETE https://api.telemetryapp.com/boards/:id

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

GET https://api.telemetryapp.com/widgets

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

Display a Widget

GET https://api.telemetryapp.com/widgets/:id

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

POST https://api.telemetryapp.com/widgets

This method will create a new widget.

Update a Widget

PATCH https://api.telemetryapp.com/widgets/:id

This method will update a widget object.

Delete a Widget

DELETE https://api.telemetryapp.com/widgets/:id

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 telemetryapp.com, 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 = “https://api.telemetryapp.com/flows/Flow 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 = "https://api.telemetryapp.com/flows/testtelemetry_piechart_1/&quot;;
            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

HTML5, jQuery Mobile and ASP.NET MVC 4–Using ViewModel between the model and controller

You can download from Windows Store at http://apps.microsoft.com/webpdp/en-US/app/emergency-help-me/477b898a-6781-4b75-a439-44dee5904f14

To get started with the development, we have seen the post Introduction to HTML5 Development Using VS 2010, HTML5, jQuery Mobile and ASP.NET MVC 4.

In an enterprise application development scenario, we might need to aggregate some of the models/data sources and present it as a whole to the controller. For simplicity, let us take a case where we need to enter new student Name, Grade and the State as shown in Fig 1.

The Grades are A, B & C. But it might make much sense if we can show these grades as First Class, Second Class, Third Class instead of A,B & C in the UI. So in the UI, we need to show  First Class, Second Class, Third Class but while saving the data we need to save the corresponding values in the DB. Same holds for the state as well. When the user clicks on state dropdown selection icon, the states list pops up and displays all the states. When a state is selected, it is shown in the UI but when saved to the DB, the code names are saved like CA for California as shown in figure 2.


Fig 1: Form for entering new student information


Fig 2: When clicked on the State drop down list, the above screen pops up.

The Magic of ViewModel: ViewModels allow you to shape multiple entities from one or more data models or sources into a single object, optimized for consumption and rendering by the view. The below figure 3 illustrates the concept of a ViewModel:


Fig 3: StudentViewModel aggregating the different models and data sources and supplying the information to the view as a single entity.

The purpose of a ViewModel is for the view to have a single object to render, alleviating the need for UI logic code in the view that would otherwise be necessary. This means the only responsibility, or concern, of the view is to render that single ViewModel object, aiding in a cleaner separation of concerns (SoC). Concerns are distinct aspects of the application that have a particular purpose (i.e., concern), and keeping these aspects apart means your application is more organized, and the code more focused. Putting data manipulation code in its own location away from the view and controller, enforces SoC. Using ViewModels in MVC  leads to more easily maintainable and testable code.

Let us create our data sources. The first one is the grade and the code is as follows. The Grades class is a simple Dictionary object containing two type parameters of type string. The class also contains the definitions for all the members in the Dictionary (i.e., the grades data). The only property in the Grades class is the GradeSelectList, which is an object that Html Helpers use with to render an HTML <select> element that displays a listing of grades. The type Dictionary<string, string> in the GradeSelectList property maps to the grades abbreviation then grade name, respectively.

public class Grades
    public static SelectList GradeSelectList
            return new SelectList(GradeDictionary, "Value", "Key");


    public static readonly IDictionary<string, string>
            GradeDictionary = new Dictionary<string, string>
            , { "First Class", "A" }
            , { "Second Class", "B" }
            , { "Third Class", "c" }


The same login for the states. The code for StatesDictionary is as follows.

public class StatesDictionary
    public static SelectList StateSelectList
        get { return new SelectList(StateDictionary, "Value", "Key"); }

    public static readonly IDictionary<string, string>
        StateDictionary = new Dictionary<string, string> {
    , { "Alabama", "AL" }
    , { "Alaska", "AK" }
    , { "Arizona", "AZ" }
    , { "Arkansas", "AR" }
    , { "California", "CA" }
    , { "Colorado", "CO" }
    , { "Connecticut", "CT" }
    , { "Delaware", "DE" }
    , { "District of Columbia", "DC" }
    , { "Florida", "FL" }
    , { "Georgia", "GA" }
    , { "Hawaii", "HI" }
    , { "Idaho", "ID" }
    , { "Illinois", "IL" }
    , { "Indiana", "IN" }
    , { "Iowa", "IA" }
    , { "Kansas", "KS" }
    , { "Kentucky", "KY" }
    , { "Louisiana", "LA" }
    , { "Maine", "ME" }
    , { "Maryland", "MD" }
    , { "Massachusetts", "MA" }
    , { "Michigan", "MI" }
    , { "Minnesota", "MN" }
    , { "Mississippi", "MS" }
    , { "Missouri", "MO" }
    , { "Montana", "MT" }
    , { "Nebraska", "NE" }
    , { "Nevada", "NV" }
    , { "New Hampshire", "NH" }
    , { "New Jersey", "NJ" }
    , { "New Mexico", "NM" }
    , { "New York", "NY" }
    , { "North Carolina", "NC" }
    , { "North Dakota", "ND" }
    , { "Ohio", "OH" }
    , { "Oklahoma", "OK" }
    , { "Oregon", "OR" }
    , { "Pennsylvania", "PA" }
    , { "Rhode Island", "RI" }
    , { "South Carolina", "SC" }
    , { "South Dakota", "SD" }
    , { "Tennessee", "TN" }
    , { "Texas", "TX" }
    , { "Utah", "UT" }
    , { "Vermont", "VT" }
    , { "Virginia", "VA" }
    , { "Washington", "WA" }
    , { "West Virginia", "WV" }
    , { "Wisconsin", "WI" }
    , { "Wyoming", "WY" }    
    // more states

Data that lives in small lists and infrequently changes, like the Grades, StatesDictionary class, exists in all types of applications.

Creating Model:

Now we need a model that collects the student’s name, the grade, and the state he is from as shown in Figure 1.  The StudentModels class definition captures these features in simple data structure. Let us now create a StudentModels class as shown below. Create a file StudentModels.cs under Models folder and add the following code.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;

namespace TagStatus.Models
    public class StudentModels
        [Display(Name = "Student Name here")]
        public string StudentName { get; set; }
        public string Grade { get; set; }
        public string State { get; set; }


Creating ViewModel:

Because of the data coming from different sources that needs to be displayed in the view, coding and maintenance will be easier if you use a ViewModel. ViewModels are a combination of one or more types that together shape data that goes to the view for consumption and rendering. A ViewModel is just a class. To get started, create a new folder named ViewModels and add a new code file StudentViewModel.cs to it. To create the StudentViewModel ViewModel, add the StudentModels, Grades  and StatesDictionary types as properties to form one StudentViewModel class. In the source code below, the StudentViewModel class contains the newly defined properties.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

using TagStatus.Models;

namespace TagStatus.ViewModels
    public class StudentViewModel
        public StudentModels Student { get; set; }
        public Grades Grades { get; set; }
        public StatesDictionary States { get; set; }

        public StudentViewModel(StudentModels student)
            Student = student;
            Grades = new Grades();
            States = new StatesDictionary();

        public StudentViewModel()
            Student = new StudentModels(); ;
            Grades = new Grades();
            States = new StatesDictionary();


Creating Controller:

After creating the ViewModel, the next steps are to instantiate it in a controller and return it to the view. I am doing R & D on this new MVC4 and so you will see some messy code.

The following code  creates a Controller Passing the ViewModel to the View and the code of interest for us is public ActionResult StudentInfo() and this gets executed while the application is firing up.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

using TagStatus.Models;
using TagStatus.ViewModels;

namespace TagStatus.Controllers
    public class StudentController : Controller
        //public string StudentName { get; set; }
        //public int Grade { get; set; }

        // GET: /Student/

        public ActionResult Index()
            StudentModels stdm = new StudentModels();
            StudentViewModel stdvm = new StudentViewModel(stdm);
            return View(stdvm);

        //public ActionResult StudentInfo()
        //    return View();

        public ActionResult StudentInfo(StudentModels model)
            if (ModelState.IsValid)
                model.StudentName = model.State;

            return View(model);

        public ActionResult StudentInfo()
            StudentViewModel model = new StudentViewModel();

                //model.StudentName = model.State;

            return View(model);


Creating HTML5 Mobile Forms in ASP.NET MVC 4 Views:

In Visual Studio 2010, Right click on project and  Add New Item command to create StudentInfo.cshtml, the view that will host your HTML5 form. Inside the view, various ASP.NET MVC 4 Html Helpers present components of the StudentViewModel by rendering HTML elements that best fit the data types they map to in the ViewModel. For example, Grade renders as an HTML drop-down list so that the user can easily select an item rather than manually enter it.

The code for StudentInfo.cshtml is as follows.

@model TagStatus.ViewModels.StudentViewModel;
    ViewBag.Title = "Student Info";

<h2> New Student </h2>
@using (Html.BeginForm("Results","Home"))
        <legend>Enter Student Information!</legend>
        <div class="editor-label">
            @Html.LabelFor(model => model.Student.StudentName)
        <div class="editor-field">
            @Html.TextBoxFor(Model => Model.Student.StudentName)
           @Html.ValidationMessageFor(Model => Model.Student.StudentName)
        <div class="editor-label">
            @Html.LabelFor(model => model.Student.Grade)
        <div class="editor-field">
            @Html.DropDownListFor(Model => Model.Student.Grade, Grades.GradeSelectList)
        <div class="editor-label">
            @Html.LabelFor(model => model.Student.State)
        <div class="editor-field">
            @Html.DropDownListFor(Model => Model.Student.State, StatesDictionary.StateSelectList)
            <input type="submit" value="Save" />


Download the source code from here and make the following change in the Global.asax file.

                name: "Default",
                url: "{controller}/{action}/{id}",
               //defaults: new { controller = "Tag", action = "Lookup", id = UrlParameter.Optional }
                defaults: new { controller = "Student", action = "StudentInfo", id = UrlParameter.Optional }
                //defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }

If you don’t go after what you want, you’ll never have it. If you don’t ask, the answer is always no. If you don’t step forward, you’re always in the same place.Nora Roberts

Introduction to HTML5 Development Using VS 2010, HTML5, jQuery Mobile and ASP.NET MVC 4

You can download from Windows Store at http://apps.microsoft.com/webpdp/en-US/app/emergency-help-me/477b898a-6781-4b75-a439-44dee5904f14

Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. Browser adoption for HTML5 features is accelerating rapidly. Many of the modern browsers (Chrome, Safari, Firefox, and Opera) already support between 75% and 90% of the feature set and this number is increasing daily. With the wide range of platforms to support, combined with the sheer power of mobile browsers, HTML5 is the “Write once, run anywhere” (WORA)solution. Modern mobile devices consist of powerful browsers that support many new HTML5 capabilities, CSS3 and advanced JavaScript. To see what features your browser supports, check out sites like html5test.com, caniuse.com. jquerymobile.com and html5please.com

In this post we will learn how to create a mobile Web applications that take advantage of HTML5, jQuery Mobile and ASP.NET MVC 4, you can effectively target multiple platforms with a single code base. Any browser, including mobile Web browsers, can render the HTML pages created with these technologies. You’ll still need to consider dealing with different browsers, but overall, Web applications are much easier to develop and maintain than multiple native applications in different languages.

Lets get started with the latest tools for Microsoft Web development: HTML5, jQuery Mobile and ASP.NET MVC 4

Tools Needed for development (download and install):

See the Windows Phone getting started guide at http://create.msdn.com/en-us/home/getting_started. After we develop in MVC4, use the Windows Phone Emulator to test the page with something closer to an actual mobile device.

JQuery Mobile is also part of the MVC 4 Mobile Web Application template in Visual Studio 2010. With the MVC 4 template, you can develop mobile Web sites with a consistent look and feel by using prebuilt themes, navigation and widgets. Additional features include built-in accessibility, touch and an API, so you can easily customize your applications. Click here to see a comprehensive list of supported platforms.

Creating a HTML5 application:

To create a new application, Open VS 2010 , select New from the File menu, and then  New Project.  The New Project dialog box pops up as shown in figure 1. Name it as tag status.

The application displays the information related to a bar code tag. So we need a place holder to enter barcode tag number and a button to retrieve the description through the API. And then another read only textblock to display its description.


Fig 1: New Project dialog box – ASP.NET MVC4 Web application

The Mobile Application template contains the necessary jQuery and jQuery Mobile scripts as well as other necessary markup, such as semantic elements and the data-* attributes.

Figure 2 shows the application in windows phone 7. As you can see, we have a textbox so that the user can enter a barcode tag number and click on submit. Then we display the description in the textbox below the button. For simplicity, when the user clicks on the submit button, I am displaying the information entered by the user in tag number as the description.


Fig 2: HTML5 mobile application

Adding Model Class:
  • In the Solution Explorer, expand the solution files
  • Right Click on Models –> Add –> Class. Name it as TagModels (TagModels.cs) and add the following code. Regardless of whether the target is mobile or desktop, HTML5 form elements map to a property of an entity in a model. Because models expose varied data and data types, their representation in the user interface requires varied visual elements, such as text boxes, drop-down lists, check boxes and buttons.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;

namespace TagStatus.Models
    public class TagModel
        [Display(Name = “Enter Tag Number”)]
        [Required(ErrorMessage = “The Tag Number field is required.”)]
        public string Name { get; set; }
        public string Description { get; set; }


In the above model code, you can see the Data Annotations Display and Required. Before the form submission process sends the HTTP Request to the server, client-side validation needs to happen. Annotating the data model accomplishes this task nicely. In addition to validation, data annotations provide a way for the Html.Label and Html.LabelFor helpers to produce customized property labels. The figure 3 shows the data annotation after the search button is clicked without entering data in the Windows Phone 7 Emulator.


Fig 3: Data Annotations in HTML5

Adding controller Class:

The idea here is that the controller must pass the model to the view for rendering.

  • In the Solution Explorer, expand the solution files
  • Right Click on Controllers–> Add –> Controller. Name it as TagController(TagController.cs) and add the following code. The names are very important. You can see that the class is derived from Controller class. Here we added two methods for Lookup() action.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using TagStatus.Models;
using System.Net;
using System.IO;
using System.Text;
using System.Net.Http;
using System.Dynamic;
using System.Data;
using System.Json;

namespace TagStatus.Controllers
    public class TagController : Controller
        // GET: /Tag/

        public ActionResult Index()
            return View();

        public ActionResult Lookup()
            return View();

        public ActionResult Lookup(TagModel model)
            if (ModelState.IsValid)
            //    //string url = “https://myapicom/svc1/v2/tags?project=usax&format=JSON&#8221;;

                model.Description = model.Name;

            //   /* CallApi apiPOItems = new CallApi()
            //    {
            //        ApiUrl = ConfigurationManager.AppSettings[“Url_PO_LineItems”].Replace(“{PO_NUMBER}”, PONumber),
            //        Format = “xml”,
            //        PageSize = intPageSize.ToString(),
            //        Page = mintCurPage.ToString(),
            //        Filter = getFilterString(),
            //        OrderBy = ((hdnPOLNSortOrder.Value != “”) ? hdnPOLNSortOrder.Value : “poln_lineno asc”)
            //    };

            //    ds = apiPOItems.RetrieveData(ref strErrorMsg, ref intRecordCount);*/

            //    string strErrorMsg = “”;
            //    int intRecordCount = -1;
            //    DataSet ds;

            //    CallApi apiPOItems = new CallApi()
            //    {
            //        //ApiUrl = “https://myapicom/svc1/v2/tags/00-RIE-FF-03?project=usax&#8221;,
            //        ApiUrl = sApiUrl,
            //       // Format = “xml”,
            //        Format = “”,
            //        PageSize = “10”,
            //        Page = “1”,
            //        Filter = “”,
            //        OrderBy = “”
            //    };

            //    CallApi.ConnectCallComplete = true;

            //   // ds = apiPOItems.RetrieveData(ref strErrorMsg, ref intRecordCount);
            //    string strjsonres = apiPOItems.RetrieveJSON();
            //    JsonObject jsonObject = (JsonObject)JsonValue.Parse(strjsonres);

            //    var strvar = JsonValue.Parse(strjsonres);

            //    var t1 = strvar[“tags”];
            //    var t2 = t1[“tags”];

            //    var t3 = t2[“tags_delivery_status”];

            //    String strdeliverystatus = t3.ToString();
            //    strdeliverystatus = strdeliverystatus.Replace(“\””,””);
            //    strdeliverystatus = strdeliverystatus.Replace(“\\u000a”, “<bR>”);
            //    strdeliverystatus = “<b>” + strdeliverystatus + “<b>”;

            //   // var v = jsonObject[“tags”];
            //   //// JsonArray items = (JsonArray)jsonObject[“tags”];
            //   // var vv = v[1];
            //   // JsonValue jsval;
            //   // bool b = jsonObject.TryGetValue(“tags_delivery_status”, out jsval);

            //    if (strErrorMsg != “”)
            //    {
            //        // There was an ERROR
            //    }

            //    //model.Description = ds.Tables[2].Rows[0][“tags_description”].ToString();


            // If we got this far, something failed, redisplay form
            return View(model);


Adding View:
  • In the Solution Explorer, expand the solution files
  • Right Click on Views–> Add –> New Folder. Name it as Tag as shown in fig 4.
  • Right Click on Tag Folder –>Add  New Item to create Lookup.cshtml as shown in figure 5.


Fig 4: Solution Explorer folder layout


Fig 5: Selecting a new View

  • Add the following code to the Lookup.cshtml
@model TagStatus.Models.TagModel

    ViewBag.Title = “Tag Status Application”;

<h2>Tag Status Lookup</h2>

@using (Html.BeginForm())
    //style=”background-color: #C0C0C0″
        <div class=”editor-label”>
            @Html.LabelFor(m => m.Name)

      <div class=”editor-field”>
            @Html.TextBoxFor(Model => Model.Name)
           @Html.ValidationMessageFor(Model => Model.Name)
            <input type=”submit” value=”Search” />
     <div class=”editor-label”>
            @Html.DisplayTextFor(m => m.Description)

@*@using (Html.BeginForm())
    //style=”background-color: #C0C0C0″
    <p>Enter tag number to get tag status:</p>
    @Html.TextBoxFor(m => m.Name)
    <input type=”submit” value=”Search” />
    @Html.DisplayTextFor(m => m.Description)



The view is the one that will host your HTML5 form. ASP.NET MVC 4 favors a development technique named convention over configuration, and the convention is to match the name of the action method (Lookup) in the controller with the name of the view, that is, Lookup.cshtml.

Inside the view, various ASP.NET MVC 4 Html Helpers present components of the ViewModel by rendering HTML elements that best fit the data types they map to in the ViewModel.

Final step (Global.asax):

To get the Tag status page displayed when the application is run, change the RegisterRoute and add the Tag Controller and the action Lookup as shown below in Global.asax file.

public static void RegisterRoutes(RouteCollection routes)

                name: “DefaultApi”,
                routeTemplate: “api/{controller}/{id}”,
                defaults: new { id = RouteParameter.Optional }

                name: “Default”,
                url: “{controller}/{action}/{id}”,
               defaults: new { controller = “Tag”, action = “Lookup”, id = UrlParameter.Optional }
                //defaults: new { controller = “Student”, action = “StudentInfo”, id = UrlParameter.Optional }
                //defaults: new { controller = “Home”, action = “Index”, id = UrlParameter.Optional }

With the Model, View and Controller in place, let us execute the project.

Testing the HTML Form on the Windows Phone 7 Emulator:

Running the app from Visual Studio through browser is the easiest way to test the form, but the look and feel doesn’t behave in a very mobile-like way. For viewing the output and testing the form, the Windows Phone 7 Emulator works perfectly.

The HTML5 form displays in the Windows Phone 7 Emulator, as shown in figure 2 . You can enter a tag number and submit the form. Submitting the form directs the browser to send the form information to the Tag controller because of the call to the Html Helper, Html.BeginForm( ). The BeginForm method directs the HTTP request to the TagController controller and then runs the Lookup action method when the submit button is pressed.

Once the user taps the submit button on the phone—and assuming the form passes validation—an HTTP POST Request is initiated and the data travels to the controller and to the Lookup action method. The controller code that lives in the TagController and processes the data that the HTTP Request sends. Because of the power of ASP.NET MVC 4 model binding, you can access the HTML form values with the same strongly typed object used to create the form – your Model.

You can immediately examine the modifications the jQuery Mobile library made by taking the following steps:

  1. Launch a Web page from within Visual Studio (F5/Ctrl).
  2. Open the browser’s developer tools to expose the runtime source (F12 in most browsers).
  3. Use the View Source command to expose the originally rendered source.

You can see the html returned to the client is different from our source.

Software development is shifting toward the mobile space. Businesses want to carve their niche in the mobile marketplace with native mobile applications and mobile Web sites – the two types of applications available for mobile devices. Creating native applications with native code means developing separate software that targets each platform of interest (e.g., one XAML app for Windows Phone 7 and one Objective-C app for iOS). Maintaining and supporting multiple code bases is challenging, in part because most software developer teams don’t have the resources to do so, especially across a large number of customers. Independent contractors often have to focus on only one or two platforms, limiting their prospects.

Download source code here.

“The future belongs to those who see possibilities before they become obvious.” — John Scully

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