App Ubiquity Drives Engagement and Loyalty

Ubiquitous App Experiences

Although mobile use is outpacing the growth of both desktop and tablet a large segment of app audiences, in addition to using their mobile devices, will continue to use desktop PCs and/or tablets at some point in their day such as at work, in the home office, on the couch, etc. For most of us this means that we want 24/7 access to both our work and personal files and apps regardless of where we are and which device we happen to be on at the moment. We also want these files and apps to be in sync so that the changes we make on one device automatically propagate to all of our other devices so we are free to switch devices at will with complete continuity of any work or play in progress. Keeping files in the cloud can handle syncing your personal and work files across devices but can’t do much for the apps and utilities you use or for driving a common experience across devices and operating systems.

Meeting the second expectation, consistency of app experience, is not as easy as meeting the first expectation of file synchronization. App developers will increasingly need to deliver a consistent user experience regardless of device type or OS whether the user is browsing to a web page, accessing a mobile website, launching a mobile app, running a desktop application, connected to the internet, or in an isolated non-connected state. After all, who wants to learn and remember several different ways to do the same things in the same app?

To accomplish this, businesses will need to build versions of their apps for several operating systems such as iOS, Android, Windows, and also for several device types: desktop, tablet, phone, browsers, and watches. Steps need to be taken to allow full functionality whether the device is in a connected or disconnected state and that requires local data stores and some sort of caching and synchronizing strategy. Not only will data need to be stored locally when the device is in a disconnected state, the app will need to sense when it has become connected again and synchronize the data in order to ensure the next session on a different device can be a continuation of the most recent session on the current device.

Building unique versions for each individual operating system and device type causes staff requirements to multiply exponentially. Engineering, QA, product management, and release teams each would need to support multiple operating systems and devices or in the more likely case these teams can only support a single operating system and possibly one or more devices. Because of this there would need to be multiple cross functional teams to deliver to multiple operating systems which leads to higher costs, disjointed user experiences, and siloed & out of sync product roadmaps. Worse yet, the user’s experience is likely to suffer with less cohesiveness among the various platforms and screen sizes, and features available in some versions may not be present in others. All of which reduces user satisfaction and loyalty. One a more consistent user experience comes to market your users are likely to jump ship.

Delivering a common or similar user experience across different device types within the same operating system family is becoming increasingly possible and simpler due to the trend of the major OS developers (Microsoft, Apple, and Google) to consolidate the number of operating systems that run on the various devices and in some cases run the exact same OS on multiple platforms. This furthers businesses ability to deliver seamless cross-device user experience since in some cases the exact same code can run on multiple device types. Microsoft leads the pack in this regard with Windows 10, which runs on desktop, tablet, and phone. Apple is close behind with iOS9 which provides a common OS for tablet, phone, iPod, and watch, but not desktop. Android supports tablet, phone, and watch but the Chrome OS used for notebook computers would need to further converge with Android to include the desktop experience. It appears hopeful that in the near future we will see common operating systems across all device types from all three of the major publishers.

But what about supporting multiple operating systems, I.E. Android, iOS, MAC, Windows? Don’t we still need different dev teams with different skill sets? Fortunately, no. Cross platform development and management tools such as Xamarin, Kony, and Kinvey allow developers to build applications using common coding languages such as C# or Java that run on all three major mobile platforms and their desktop counterparts. By using shared code bases and including ready-built components app development is accelerated and overall quality is improved. Because a single code base can be used across operating systems it is easier and more economical to support several operating systems and multiple device types.

As all of these factors and capabilities evolve and converge we are becoming closer to app omnipresence being an affordable and sustainable reality for mobile, tablet, browser, desktop, and watch across multiple operating systems.

Dirk Garner is a Principal Consultant at Garner Consulting providing data & app strategy consulting and full stack development. Dirk can be contacted via email: or through LinkedIn:

Screen Size for iOS, Android and Windows Phone from C# with Xamarin in Shared Code.

To get the screen size from either iOS, Android, or Windows Phone you could use the following examples:

int intHeight = (int)Resources.DisplayMetrics.HeightPixels / Resources.DisplayMetrics.Density;
int intWidth = (int)Resources.DisplayMetrics.WidthPixels / Resources.DisplayMetrics.Density;
int intHeight = UIScreen.MainScreen.Bounds.Height; 
int intWidth = UIScreen.MainScreen.Bounds.Width;
int intHeight = Window.Current.Bounds.Height; 
int intWidth = Window.Current.Bounds.Width;

To get screen size from any one of the platforms in a shared code base you could include conditional compile directives as follows:

int intHeight = 0;
int intWidth = 0;
#if __ANDROID__
	intHeight = (int)Resources.DisplayMetrics.HeightPixels / Resources.DisplayMetrics.Density;
	intWidth = (int)Resources.DisplayMetrics.WidthPixels / Resources.DisplayMetrics.Density;
#end if 
#if __IOS___
	intHeight = UIScreen.MainScreen.Bounds.Height; 
	intWidth = UIScreen.MainScreen.Bounds.Width;
	intHeight = Window.Current.Bounds.Height; 
	intWidth = Window.Current.Bounds.Width;

Making a cURL call to from C#

I had the need to make cURL calls from C# to a call several classifiers I built for an AI proof of concept project.  I struggled a bit getting the headers and syntax correct so I thought I’d share the result in hopes that it may help someone else with a similar need.  I found a few cURL wrappers for C# but found those to be heavy, complicated and unnecessary after much experimentation.

Although this example is specific to Metamind, I think the same general idea would work for any cURL call.

Here is the method that calls the service:

public async Task<string[]> CallCurlService(string strClassifierID, string strImagePath)
    string[] strRetval;
    var client = new HttpClient();
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", mstrCredentials);
    StringContent stringContent = new StringContent("{\"classifier_id\":" + strClassifierID + ",\"image_url\":\"" + strImagePath + "\"}");
    HttpResponseMessage response = await client.PostAsync(mstrMetamindUrl, stringContent);
    HttpContent responseContent = response.Content;// Get the response content.
    using (var reader = new StreamReader(await responseContent.ReadAsStreamAsync()))// Get the stream of the content.
        JObject jsonResult = JObject.Parse(await reader.ReadToEndAsync());
        string strResult = jsonResult.ToString();
        string strCategory = jsonResult["predictions"].First["class_name"].ToString();
        string strProbability = Math.Round(((double)jsonResult["predictions"].First["prob"] * 100), 2).ToString() + "%";
        strRetval = new string[] { strCategory, strProbability };
    return strRetval;