Designing Platform Independent Mobile Apps and Services

Rocky Heckman

• Publisher: Wiley-IEEE Computer Society Pr
• Year: 2016
• Print ISBN: 9781119060147
• eBook ISBN: 9781119060185
• Edition: 1
• Topic: Technology & Engineering
• Subtopic: Mobile & Wireless Communications
• Index: Technology & Engineering

Presents strategies to designing platform agnostic mobile apps connected to cloud based services that can handle heavy loads of modern computing

• Provides development patterns for platform agnostic app development and technologies
• Includes recommended standards and structures for easy adoption
• Covers portable and modular back-end architectures to support service agility and rapid development

CHAPTER 1
THE MOBILE LANDSCAPE

1.1 INTRODUCTION

When the idea of reaching people first struck home in the dark ages, we wanted to find ways for people to use and pay for our services. We had to find a way to let people know these services existed. In early days there were town criers, then during the industrial revolution when we could reproduce and distribute text to a largely literate audience, we had broadsheets. Then came the catalogue where mercantile companies would list their wares for sale. Once we heard the first radio waves, one of the first things they did was to sell advertising on the radio. This graduated to television advertising. Then along came the Internet. Everyone had to get themselves a website and would put their website address in their print, radio, and TV ads. Along came Facebook and everyone created a Facebook page for their companies.

Now, everyone wants to have an app for their customers to download. These apps go with customers wherever they are and provide instant interaction between consumer and supplier. We can push advertising into them, take orders through them, keep in touch with friends and relatives, and of course play games, listen to music and watch videos all in the palms of our hands. These experiences require devices, operating systems, and apps, all of which require software companies, architects, and developers to produce them. Unfortunately, these devices and operating systems often change.

In today's computing world, there is one thing you can be sure of; the leading operating system (OS) platform will change. As recently as 7 years ago, Microsoft Windows Mobile was the leading smartphone platform and tablet computers, while mobile, were large and clunky and ran full versions of the Windows XP and Windows 7 OS. Then came Blackberry which took a lot of market share from Windows Mobile. But that only lasted until the iPhone came along in 2007 and we went from a feature phone dominated world to a smartphone dominated one. This set a new benchmark and became the leading mobile computing platform. In the same year, the Open Handset Alliance re-released Linux-based Android-powered smartphones. Then in 2010, Google launched its Android-based Nexus series of devices. By 2011, Android-powered smartphones made up the majority of mobile OS-powered smartphones shooting past the iPhone.

While phones were taking off, in 2010 Apple released the iPad. Tablet computing was not new and in fact Microsoft and its Original Equipment Manufacturers OEM partners had been trying to sell tablet computers since 2003. However, the iPad's sleek design brought tablet computing to the masses despite the clumsy and restrictive iOS operating system. This opened up the tablet computing market which Android was well suited for. After the iPad's initial success, by 2013 Google's Android-powered tablets had overtaken iPads as the tablet of choice. Additionally, although lagging considerably behind, Microsoft has re-created itself to make a run in the mobile and tablet computer markets as well. With Microsoft's massive install base, and very large developer ecosystem, they are likely to challenge Apple and Google in the mobile and tablet space eventually. With Windows 10 released as a free upgrade for over 1.5 billion eligible devices [1], it is likely to be the most common cross platform OS. That is, over half of Gartner's predicted 2,419,864,000 devices shipped into the market in 2014 [2]. Overnight the app ecosystem market leader could change again.

What this means for software developers, independent software vendors (ISVs), hobbyist app developers, and online service providers is that every few years they will have to retarget their efforts for a new platform, new development languages, new development tools, new skills, and new ways of thinking. This is not an attractive proposition for anyone. However, due to the success of the iPhone and iPad, software developers were willing to re-skill and even purchase proprietary hardware just to be able to develop applications for the new platforms. Then when Android devices surpassed the Apple devices, these same developers painfully went through the whole process again. Developers were forced to maintain three or more separate and complete codebases. This is the problem that Platform-Independent Delivery of Mobile Apps and Services solves.

If you are not planning a platform-independent strategy, you will likely be an ex-company in 3–5 years. Due to the rapid change of the consumer and enterprise mobile computing landscape, software developers must be able to adapt to new platforms, devices, and services before their competition. While cross-platform goes a long way toward this goal, it is still cumbersome and tends to lag behind a more platform-independent strategy. While it is not practical to get completely away from device-specific app code, the more you can move off of the device and put into a reusable back-end service, the less code you have to write and maintain when a new OS version or a new platform comes along. In this book we will examine strategies to do this, and provide future proof foundations to support changes in the computing landscape down the road.

Disclaimer: This book was written in late 2014. Everything in it was accurate at that time. If you are reading this in 2025, expect that a few things have changed. Just keep this in mind as we go through this so I don't have to keep writing “At the time of this writing….”

1.2 PREVIOUS ATTEMPTS AT CROSS-PLATFORM

1.2.1 Java

“Write once, run everywhere” was a slogan developed by Sun Microsystems which promised cross-platform capability for Java applications supported by Duke, Java's Mascot shown in Figure 1.1. This gained significant traction in the mid to late 1990s. In the beginning of this era, the promise seemed legitimate. You could write the Java code once, package up your Java byte code in .jar files and run them on any system that had the Java Virtual Machine (JVM) interpreter. It worked so well that there are even C to Java compilers so your C applications can run with the same cross-platform reach that Java had.

Figure 1.1 Duke

The promise was that you could write code like this:

---

class CrossPlatformApp { public static void main(String[] args) { System.out.println("I am omnipresent!"); // Display the string. } }

---

And it would run on every computer and device that ran Java without compiling multiple versions for each target device. All you had to do was make sure that the target device had the correct version of the JVM installed on it.

This worked fine until various vendors started creating their own versions of the JVM to run on their platforms. By 2014, more than 70 different JVMs [3] had been created that could run Java applications, for the most part. The catch was that they were each slightly different.

If we take the Sun JVM to be the standard, some of these other JVMs were better, and most were worse, at interpreting Java byte code. Some of them such as the IBM J9 (http://en.wikipedia.org/wiki/IBM_J9), the Azul Zing JVM (http://en.wikipedia.org/wiki/Azul_Systems), and the Microsoft JVM (http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine) were better and faster than the original Sun JVM. They even went so far as to add extra features and some constructs that were more familiar to traditional C/C++ programmers in order to make the transition easier for them.

While this seemed fantastic at the time, because it meant every platform vendor had a JVM to run Java, they weren't all the same. So what may work on the Sun JVM may not work on the Microsoft or IBM implementation. Even though some of these implementations such as the 1998–1999 Microsoft JVM outperformed the Sun version, they weren't entirely compatible with the Java 1.1 standard. This lead to Sun suing Microsoft and other JVM vendors in an attempt to try to defragment the Java playing field. The result was these other vendors stopped supporting their proprietary versions of the JVM and true high-performance, cross-platform capability for Java applications started to deteriorate.

This is a trade-off that you see repeatedly in cross-platform development. There has always been a compromise between running on many different devices, and getting as close to the hardware as possible for fast execution. It's the nature of computers. Each device may have slightly different hardware running the code. This means that the operating system and CPU may understand different instructions on each device. Java tried to solve this with the JVM. Different JVMs are written for the different environments, and they provide an abstraction layer between your Java code, and the nuances of the underlying hardware. The problems arise when one JVM interpreted the incoming Java code slightly differently than the next one and the Java dream becomes fragmented.

While Java is still widely used for applications, there are many versions of it depending on what kind of applications you are writing. There are four primary versions of Java that are supported by Sun.

• Java Card for smartcards.
• Java Platform, Micro Edition (Java ME) for low powered devices
• Java Platform, Standard Edition (Java SE) for standard desktop environments
• Java Platform, Enterprise Edition (Java EE) for large-scale distributed internal enterprise applications

All of them require a very standards adherent JVM to be installed on the target machine for them to run. Often the JVM can be packaged up with the application deployment, but the dependence on the JVM and specific versions of the JVM have made cross-platform Java apps troublesome. This is largely because you can never be sure of the JVM on the target device.

This is a common issue with most interpreted languages such as Java, Python, Ruby, .NET and any other language that is Just-In-Time compiled and run in a virtual environment or through a code interpreter. These kinds of things also reduce the speed of the applications because everything is interpreted on the fly and then translated for the CPU rather than being compiled down into Assembly or CPU level instructions which are executed by the CPU natively. This is why C and C++ and similar languages are referred to as native languages.

So while Java was a very good attempt at write once run anywhere, it fell short due to its dependency on the JVM. It still has a large install base and works very well in many web app scenarios. It is also the primary app development language for Android-based devices which at the time of this writing was the world's leading mobile device operating system. Java can also be used to create apps for Apple's iOS-based devices through systems such as the Oracle ADF Mobile Solution [4, 5]. However, the vast majority of iOS targeted apps are written in Objective-C using Apple's Xcode environment. Due to the difficulty of developing with Objective-C, Apple introduced a new language called Swift for the iOS platform to help combat the hard translation form Java or C# for iOS developers and to improve the performance over Objective-C apps. At the time of this writing, Java did not work on the Windows Modern apps or Windows Phone platforms. Java does still work in the Windows Pro full x86 environment.

Java is perhaps the closest the industry has come to write once run anywhere. But it has been plagued by spotty JVM support, and a push toward more proprietary development for iOS and Windows to get the speed and integration to a more seamless state.

1.2.2 Early Web Apps

On August 6, 1991 the first website was created by Tim Berners-Lee at CERN (http://info.cern.ch/hypertext/WWW/TheProject.html). Ever since then, we've been pushing web browsers beyond their intended limits. From their humble beginnings as static pages of information to the preeminent source of all information and social interaction, websites and web apps have become ubiquitous in our connected world. It was inevitable that web access from every computer would lead to web apps being seen as the next great cross-platform play.

Web apps have been a popular attempt to run anywhere. All you need is a web browser on whatever device you have an...

Table of contents

• Cover
• IEEE Press
• Title page
• Copyright
• Dedication
• PREFACE
• ACKNOWLEDGMENTS
• CHAPTER 1 THE MOBILE LANDSCAPE
• CHAPTER 2 PLATFORM-INDEPENDENT DEVELOPMENT TECHNOLOGIES
• CHAPTER 3 PLATFORM-INDEPENDENT DEVELOPMENT STRATEGY
• CHAPTER 4 THE USER INTERFACE LAYER
• CHAPTER 5 THE SERVICE INTERFACE LAYER
• CHAPTER 6 THE SERVICE LAYER
• CHAPTER 7 THE DATA ABSTRACTION LAYER
• CHAPTER 8 THE DATA LAYER
• CHAPTER 9 STRATEGIES FOR ONGOING IMPROVEMENT
• CHAPTER 10 CONCLUSION
• REFERENCES
• INDEX
• EULA