Tag Archives: html5

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.

image

Fig 1: Form for entering new student information

image

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:

image

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
    {
        get
        {
            return new SelectList(GradeDictionary, "Value", "Key");
        }

    }

    public static readonly IDictionary<string, string>
            GradeDictionary = new Dictionary<string, string>
            {
              {"Choose…",""}
            , { "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> {
      {"Choose…",""}
    , { "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")]
        [Required()]
        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);
        }

        //[AllowAnonymous]
        //public ActionResult StudentInfo()
        //{
        //    return View();
        //}

        [AllowAnonymous]
        [HttpPost]
        public ActionResult StudentInfo(StudentModels model)
        {
            if (ModelState.IsValid)
            {
                model.StudentName = model.State;
            }

            return View(model);
        }

        [AllowAnonymous]
        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"))
{
    @Html.ValidationSummary(true)
    <fieldset>
        <legend>Enter Student Information!</legend>
        <div class="editor-label">
            @Html.LabelFor(model => model.Student.StudentName)
        </div>
        <div class="editor-field">
            @Html.TextBoxFor(Model => Model.Student.StudentName)
           @Html.ValidationMessageFor(Model => Model.Student.StudentName)
        </div>
        <div class="editor-label">
            @Html.LabelFor(model => model.Student.Grade)
        </div>
        <div class="editor-field">
            @Html.DropDownListFor(Model => Model.Student.Grade, Grades.GradeSelectList)
        </div>
        <div class="editor-label">
            @Html.LabelFor(model => model.Student.State)
        </div>
        <div class="editor-field">
            @Html.DropDownListFor(Model => Model.Student.State, StatesDictionary.StateSelectList)
        </div>
        <p>
            <input type="submit" value="Save" />
        </p>
    </fieldset>
}

 

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

routes.MapRoute(
                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.

image

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.

imageimage

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.

image

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();
        }

        [AllowAnonymous]
        public ActionResult Lookup()
        {
            return View();
        }

        [AllowAnonymous]
        [HttpPost]
        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.

image

Fig 4: Solution Explorer folder layout

image

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())
{
    @Html.ValidationSummary(true)    
    //style=”background-color: #C0C0C0″
    
    <fieldset>
        <legend></legend>
        <div class=”editor-label”>
            @Html.LabelFor(m => m.Name)
        </div>

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

@*@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)
        {
            routes.IgnoreRoute(“{resource}.axd/{*pathInfo}”);

            routes.MapHttpRoute(
                name: “DefaultApi”,
                routeTemplate: “api/{controller}/{id}”,
                defaults: new { id = RouteParameter.Optional }
            );

            routes.MapRoute(
                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

Part 3: Introduction to WinRT, the new ‘Windows Runtime’ in Windows 8

To install visual studio 2011 developer preview + Window 8 beta, refer to post here.

To get started working with Windows 8 operating system, see post here.

Fig 1: Windows 8 Platform and Tools slide shared at Build conference.

Windows Runtime, or shortly WinRT, is Microsoft’s new programming model that makes the backbone of the new Metro-style apps (also known as Immersive) in the new Windows 8 operating system. WinRT solves many of the problems of Win32, from an apps perspective. Apps created for WinRT are safe, secure, and sandboxed, can’t wreck other apps and all install in just 2-3 seconds. They feature isolated storage, single folder installs (as per the Mac), and require user consent to access the general file system. This is part of it, a modern, truly different app platform that is far more different, and far more capable, than many people understand right now.

WinRT isn’t another abstraction layer; it’s a new runtime sitting directly on top of the Windows Kernel Services just like the good old Win32 API as shown in the above figure that allows developers to write Metro style applications for Windows 8, using a variety of languages including C++ (with WRL or  with Component Extensions – C++/CX), the managed languages C# and VB.NET, as well as JavaScript. In the above figure, right on top of NT kernel (like Win32) is WinRT. This WinRT has an application model and three boxes of capabilities that are expressed by APIs (Communications & Data, Graphics & Media, and Devices & Printing). "Above" WinRT is the two sets of presentation layer/programming language couples: XAML and various high level programming languages (C#, VB, and so on) and HTML/CSS and JavaScript, respectively. (DirectX is left out, but sits on top of WinRT too.) WinRT is an unmanaged native layer and its API is object oriented that can be consumed both from native or managed languages, as well as JavaScript. In short, WinRT is the Object Oriented Programming replacement for Win32.

This marks the first major break in the core of Windows since Win32 was introduced in 1993 with Windows NT. WinRT represents a new application execution environment with semantics that are very different than Win32. Unlike Win32, which was designed with C in mind, the WinRT APIs are written in C++ and designed from the beginning to be object oriented. Consistency, ease of use, and performance are key aspects of the new runtime API. Every object in the WinRT API supports reflection so that even dynamic languages such as JavaScript can use them efficiently. Along with this comes a unified object model, a rarity for C++ based libraries. The new Windows SDK for Metro style apps also includes a subset of traditional Win32, Component Object Model (COM), and .NET Framework APIs, as well as HTML5 and CSS3 APIs that are accessible to Metro style app developers. I.e. Metro style apps can use a subset of the Win32 and COM API. This subset of APIs was chosen to support key scenarios for Metro style apps that were not already covered by the Windows Runtime, HTML/CSS, or other supported languages or standards. The Windows App Certification Kit ensures that your app uses only this subset of the Win32 and COM API. The subset of the Win32 and COM API that can be used in a Metro style app is indicated in the header files in the Windows Software Development Kit (SDK) for Metro style Apps. Look for the following statements in the header files:

#pragma region Application Family

#pragma region Desktop Family

The compiler and object browser in Microsoft Visual Studio 11 Express for Windows Developer Preview use these statements to determine whether to show or hide a Win32 or COM API element.

One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. Well, the Windows Runtime is exposed using API metadata stored in .winmd files as shown in the following figure 2. In COM you were able to achieve that with type libraries(Type libraries contain metadata that represent COM types), but not every COM component had them.  The metadata (API definitions) of WinRT contained in .winmd files are encoded in ECMA 335 metadata format, the same format that .NET uses but with a few modifications. The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language of your choice. The shape and structure of the Windows Runtime APIs can be understood by both static languages such as C# and dynamic languages such as JavaScript. IntelliSense is available in JavaScript, C#, Visual Basic, and C++. This common metadata format allows for significantly less overhead when invoking WinRT from .NET applications compared to a P/Invoke, and much simpler syntax. Regular C++ (with COM-specific discipline) can also be used to program with WinRT components, with the help of new template library called Windows Runtime C++ Template Library (WRL), which is similar in purpose to what Active Template Library provides for COM. The MSDN documentation, however, recommends using C++/CX instead of WRL.

Fig showing the “C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\” folder in Windows 8 Developer Preview. You can observe that they are actually CLI assemblies with no code, just metadata tables. image

Fig 2: Windows RunTime Metadata files

As shown in the following Fig 3, you can open the .winmd file with ILDASM. Note, this doesn’t mean that WinRT itself is managed – it simply reuses the file format.image

Fig 3: Opening an C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\Windows.Applicationmodel.Activation.winmd file using ILDASM

For the structure of the Windows Runtime, see the Microsoft site.

There are a number of libraries implemented in terms of the new object model, i.e. defining WinRT interfaces and classes. Look at “Windows Metadata” folder mentioned above to see what’s there; or just fire up Object Browser in VS and select “Windows 8.0″ in the framework selector, to see what’s covered. There’s a lot there, and it doesn’t deal with UI alone – you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets. Then you get several libraries, which are specifically dealing with UI – mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces – e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; also for Windows.UI.Xaml.Documents etc.

The WinRT type system relies strongly on WinRT components, which are COM objects implementing a specific set of interfaces and adhering to a certain ABI (Application Binary Interface). WinRT is essentially a COM-based API, relying on an enhanced COM that implements the IInspectable interface. The IInspectable interface enables projecting Win32 and COM features into JavaScript and other languages, such as C# and Visual Basic. Implement the IInspectable interface when you want your class to be available in other programming environments. The IInspectable interface is the base interface for all Windows Runtime classes. All Windows Runtime classes must implement the IInspectable interface. The IInspectable interface inherits from the IUnknown interface. so every WinRT object implements IUnknown and does refcounting (WinRT objects are reference counted like COM for memory management, with weak references to avoid circularity), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET – for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parameterized (“generic”) interfaces. 

In short, Windows Runtime is a new set of libraries exposing Windows functionality and available to JavaScript/C#/VB/C++ as shown in figure 4. Each language has been made to understand and be able to call them directly rather than having to go through some thunking layer. Silverlight and WPF are flavors of XAML that run on the CLR. Among other functionality, Windows Runtime exposes a version of XAML very similar to Silverlight, but does so in a native way, not via the CLR. It can be accessed from the CLR, but also from C++.

Fig 4 : Microsoft Windows 8 Platform and Development Tools

Relation between .NET & WinRT

The important concept to understand is that the .NET framework now has two profiles.

  1. .NET Metro profile (CLR that deal with Metro application)
  2. .NET Client profile (CLR runtime for C#,VB.NET applications)

The .NET APIs for Metro style apps provide a set of managed types that you can use to create Metro style apps for Windows using C# or Visual Basic. The .NET APIs for Metro style apps include a subset of types from the .NET Framework and enable .NET developers to create Metro style apps within a familiar programming framework. You use these types with types from the Windows Runtime API to create Metro style apps.

In some cases, a type that you used in a .NET Framework application does not exist within the .NET APIs for Metro style apps; instead, you must use a type from the Windows Runtime. For example, the System.IO.IsolatedStorage.IsolatedStorageSettings class is not included in the .NET APIs for Metro style apps; instead, you use the Windows.Storage.ApplicationDataContainer class for app settings. You retrieve an instance of the ApplicationDataContainer class through the Windows.Storage.ApplicationData.Current.LocalSettings property.

  • The .NET Framework 4.5 is used in both Desktop Mode apps and in Metro style apps. There is a difference though. Metro style apps use what is best described as a different .NET Profile (e.g. Desktop apps use the .NET Client Profile and Metro style apps use the .NET Metro Profile). There is NOT actually a different profile, but the implementation of .NET in Metro style apps is LIKE a different profile. Don’t go looking for this profile – its basically rules built into the .NET Framework and CLR that define what parts of the framework are available.
  • There is only one CLR. Each application or application pool (depending on the app type) spins up a process and the CLR is used within that process. Meaning, a Metro style app and a Desktop Mode app running at the same time are using the same CLR bits, but separate instances of the CLR.
  • Whether a Desktop Mode app or a Metro style app, if it is a .NET app, it is compiled to the same MSIL. There isn’t a special Windows 8 Metro IL – there is, like the CLR, only one MSIL.

In the above diagram (Fig 4) you can see that the CLR and the .NET Framework 4.5 are used for C# and Visual Basic apps in either Desktop Mode apps (blue side) or Metro style apps (green side). Silverlight is still only available in Desktop Mode as a plug-in to Internet Explorer (yes, out of browser is still supported in Desktop Mode). Another addition in this diagram is DirectX, which was strangely absent from the original diagram. DirectX is the defacto technology for high-polygon count applications, such as immersive games. DirectX leverages the power of C++.

This biggest confusion, has been around the use of the .NET Framework across the blue side and green side. The reason for the .NET Metro Profile is because the Metro style apps run in an app container that limits what the application can have access to in order to protect the end user from potentially malicious apps. As such, the Metro Profile is a subset of the .NET Client Profile and simply takes away some of the capabilities that aren’t allowed by the app container for Metro style apps. Developers used to .NET will find accessing the WinRT APIs very intuitive – it works similarly to having an assembly reference and accessing the members of said referenced assembly.

Additionally, some of the changes in the Metro Profile are to ensure Metro style apps are constructed in the preferred way for touch-first design and portable form factors. An example is File.Create(). Historically if you were using .NET to create a new file you would use File.Create(string fileLocation) to create the new file on the disk, then access a stream reader to create the contents of the file as a string. This is a synchronous operation – you make the call and the process stalls while you wait for the return. The idea of modern, Metro style apps is that asynchronous programming practices should be used to cut down on things like IO latency, such as that created by file system operations. What this means is that the .NET Metro Profile doesn’t provide access to File.Create() as a synchronous operation.

Ultimately all of this means that you have some choice, but you don’t have to sacrifice much if anything along the way. You can still build .NET and Silverlight apps the way you are used to, and they will run on Windows for years to come. If you want to build a new Metro style app, you have four options to choose from:

  1. XAML and .NET (C# or VB): You don’t have to giving up too much in the .NET Framework (remember, you only give up what is forbidden by the Application Container), and you get access to WinRT APIs for sensor input and other system resources.
  2. XAML and C++: You can use your skills in XAML and C++ in order to leverage (or even extend) WinRT. Of course you don’t get the benefit of the .NET Framework. You can use WRL or  with Component Extensions – C++/CX
  3. HTML and JavaScript: You can leverage the skills you have in UI layout, and make calls from JavaScript to WinRT for access to system resources, and sensor input.
  4. DirectX and C++: If you’re building an immersive game you can use DirectX and access the device sensors and system resources through C++ and WinRT.

image

Fig 5 : Deciphering the new WinRT – Metro style application API’s.

.NET with WinRT:

C#/VB: The end of P/Invoke : Calling native functions from .NET usually involves building up structures and manipulating pointers. Under WinRT all APIs are exposed as objects that C# and VB can consume directly. This puts .NET developers on level footing with C++ developers.

Application responsiveness is very important to Microsoft. In order to convey that to developers all OS-level API calls that take longer than 50 milliseconds will be exposed as an asynchronous operation.

image

Fig showing the overview of CLR components.

A managed Metro application (e.g. written in C#) will still load the CLR.  The CLR version bundled with the preview is 4.0.30319.17020, and that’s the version that gets loaded inside a Metro app.  Symmetrically, a “fully” .NET application (e.g. a WinForms app) can reference the WinRT metadata assemblies and use WinRT APIs. This will be a necessity in some cases, for example to tap into the WinRT sensor APIs.

.NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop – you don’t need any intermediate artifacts such as interop assemblies, you just read a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that native C++ programs that use WinRT do not require CLR at all (WinRT libraries themselves are fully native) – the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you’ll see that it actually looks like an extern assembly reference – there’s no sleight of hand trickery such as type embedding there.

It’s not a blunt mapping, either – CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable and IVector become IEnumerable and IList; and so on. This goes both ways – if you have a .NET object that implements IEnumerable, and pass it back to WinRT, it’ll see it as IIterable.

Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT. When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8. And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed. What they did was that they only exposed to the compiler a set of APIs when you target the Metro profile. So your application will not accidentally call File.Create for example. At runtime though, the CLR will load the full class library, the very one that contains File.Create, so internally, the CLR could call something like File.Create, it is just you that will have no access to it. So for managed applications, the Metro projects in Visual Studio are targeting a special subset of the .NET framework, and will not have access to all the classes – not even all the classes of the .NET Client Profile. For example, the System.IO.FileStream class is not available.

Although these limitations may seem artificial, annoying, and counterproductive, there is probably a good reason for having them. The Metro UI and Metro apps are a fresh start for Windows applications and their developers. There is no trivial way to port an existing UI app to Metro without a considerable UI redesign. It’s also a great opportunity to enforce additional limitations that make sure Metro apps respect the user’s privacy, conserve battery power, integrate well with the UI guidelines, and live in harmony within the application sandbox.

Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which – particularly Windows.UI – look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight – data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted. WinRT itself doesn’t have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don’t need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app.

C++11 with WinRT: C++ Development

A good news for C++ developers is that User interfaces in C++ will be written primarily in XAML for immersive applications. However, this is not available for classical, Win32 applications. This libraries for working with XAML have all been ported to C++ and are compiled to native x86. Metro applications written with XAML and C++ do not run on top of .NET, they get compiled directly to x86 just like any other Visual C++ application. Calling methods on UI controls is just like calling methods on any other object in C++.

Microsoft has created a new language called C++ Component Extension, or simply C++/CX. While the syntax is very similar to C++/CLI, the language is not managed, it’s still native. WinRT components built in C++/CX do not compile to managed code, but to 100% native code.

App Container and Application Permissions : Metro applications run in what’s known as the “app container”. This appears to replace the windowing environment used by Win32 based applications.

Most API calls are sent directly to the underlying kernel. Some, however, some will be routed through the system broker. The system broker ensures that applications can only access features that the user has approved. For example, the first time an application tries to access the camera the service broker will prompt the user for their approval. Applications are required to include a manifest that indicates all of the restricted services the application may need. This model will be very familiar to mobile device developers.

All Metro applications run within WinRT’s app container and thus are monitored by the system broker, even those written in C++. The idea is to limit the ability of applications to damage the system. While probably not impossible, building malware with WinRT will be much harder than it is in Win32.

Overlapping Windows No Longer Exist : In Metro, there are no overlapping top-level windows. There’s still Popup (http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.primitives.popup). Dialog boxes, a core concept from previous versions of Windows, does not exist in WinRT. The performance cost and usability concerns are simply no longer justifiable to Microsoft. Applications that wish to use this pattern will have to develop other ways to express things such as message boxes. Another library that didn’t make it into WinRT is GDI. If an application is going to use the Metro interface it needs to do so from top to bottom, it appears that mixing Metro and classic user interfaces is not possible.

PlayTo Contract : Another contract that is being exposed is PlayTo. This allows applications to send media files such as audio and video to a charm. The charm will then allow the user to choose which application they want to use to view the file. Presumably these aren’t just physical files, but rather any form of media that can be expressed as a data stream.

All Metro Applications Must be Digitally Signed: Anonymous applications are not allowed. Applications can be self-signed for testing, but by the time they appear in the app store they will need to be signed using a real certificate.

JavaScript :

Another major language for Windows 8 is JavaScript. While it doesn’t use XAML, it does have direct access to the underlying WinRT API just like native and .NET applications. This isn’t just a container like PhoneGap, JavaScript developers get the same rich API that other developers use. Since this is JavaScript the UI toolkit of choice is HTML and CSS rather than XAML. The same rendering engine used by Internet Explorer 10 us used by Metro JavaScript applications, though they don’t actually run in a browser. A JavaScript application looks just like any other Metro application. Expression Blend 5 now supports editing HTML5, much like you use it for editing XAML.

User controls in JavaScript are nearly on par with those in C++ and .NET. Some controls are intrinsic to the HTML rendering engine, others are written in JavaScript. These JavaScript based ones are div based much like controls built using jQuery.

The IInspectable interface contains three methods: GetIids, which returns the interfaces implemented by the component; GetRuntimeClassName, which returns the fully-qualified name of the component; and GetTrustLevel, which returns the component’s trust level that can be used to control component activation.

IInspectable is used by the dynamic language bindings from JavaScript. Given a reference to a WinRT component, the JavaScript interpreter can call the IInspectable::GetRuntimeClassName method and obtain the fully-qualified class name of the WinRT component. Using the namespace name the interpreter can ask Windows to load the metadata file (.winmd) describing the component, and from the metadata determine how to use the interfaces implemented by the component.

WinRT Projections

What we call "bindings" Microsoft now calls "projections". Projections are the process of exposing APIs to three environments: Native (C and C++), HTML/JavaScript and .NET.  If you author a component in C++ or a .NET language, its API will be stored in a WinMD file and you will be able to consume it from all three environments (Native, JavaScript and .NET). Even in C++ you are not exposed to COM. The use of COM is hidden behind the C++ projection tools. You use what looks and feels like a C++ object oriented API. To support the various constructs of WinRT, the underlying platform defines a basic set of types and their mappings to various environment. In particular, collection objects in WinRT are mapped to constructs that are native to each environment.

Conclusion:

WinRT solves many of the problems of Win32, from an apps perspective. Apps created for WinRT are safe, secure, and sandboxed, can’t wreck other apps, can’t cause "Windows rot," and all install in just 2-3 seconds. They feature isolated storage, single folder installs (as per the Mac), and require user consent to access the general file system.

To summarize, WinRT does not replace .NET, nor does it compete with .NET – and the same applies to Win32. You can write server and client applications using .NET, including WPF and Silverlight. You can write server and client applications using C++, including Win32 and MFC. However, if you choose to believe in the Metro way, you can write Metro applications for Windows 8 using .NET languages or using C++ or using JavaScript, with a consistent set of APIs exposed through WinRT. At the same time the Win32 applications will continue to run just as before and you can still (and most certainly will) develop Win32 applications.

Finally, I am very impressed with the details of Windows 8! It’s fantastic. There are three ways to write WinRT applications. One is C++, in which case you write directly to the “projection” of WinRT into your language. The second is .NET, in which case your code goes via the CLR. The third is HTML and JavaScript, in which case your code goes via the “Chakra” JavaScript engine also used by Internet Explorer 9 and higher. There is no message loop in WinRT. There is no GDI in WinRT. All graphics are via DirectX. XNA, the .NET games framework, is not supported. The WinMD (Windows Metadata – which makes the whole Windows Metro API available to any language – hence the ability to use JavaScript, for example) is great. The new object-oriented API, with namespaces and interfaces etc., is great. The language projections are great. Oh and the native support in Microsoft C++!! for the Windows Runtime, and the fact that C++ is ideal for it (since it is, at the core, an extension of COM), is great. So much to learn!!

A great leader’s courage to fulfill his vision comes from passion, not position. – Paul John Maxwell

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.

Pros:

  • 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,

Cons:

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

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?

Pros:

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

Cons:

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

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.

Pros:

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

Cons:

  • 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.

image

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