44,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
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
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 522
Veröffentlichungsjahr: 2016
Ähnliche
IEEE Press Editorial BoardTariq Samad, Editor in Chief
George W. Arnold
Xiaoou Li
Ray Perez
Giancarlo Fortino
Vladimir Lumelsky
Linda Shafer
Dmitry Goldgof
Pui-In Mak
Zidong Wang
Ekram Hossain
Jeffrey Nanzer
MengChu Zhou
Kenneth Moore, Director of IEEE Book and Information Services (BIS)
About IEEE Computer Society
IEEE Computer Society is the world's leading computing membership organization and the trusted information and career-development source for a global workforce of technology leaders including: professors, researchers, software engineers, IT professionals, employers, and students. The unmatched source for\break technology information, inspiration, and collaboration, the IEEE Computer Society is the source that computing professionals trust to provide high-quality, state-of-the-art information on an on-demand basis. The Computer Society provides a wide range of forums for top minds to come together, including technical conferences, publications, and a comprehensive digital library, unique training webinars, professional training, and the TechLeader Training Partner Program to help organizations increase their staff's technical knowledge and expertise, as well as the personalized information tool myComputer. To find out more about the community for technology leaders, visit http://www.computer.org.
IEEE/Wiley Partnership
The IEEE Computer Society and Wiley partnership allows the CS Press authored book program to produce a number of exciting new titles in areas of computer science, computing, and networking with a special focus on software engineering. IEEE Computer Society members continue to receive a 15\% discount on these titles when purchased through Wiley or at wiley.com/ieeecs.
To submit questions about the program or send proposals, please contact Mary Hatcher, Editor, Wiley-IEEE Press: Email: [email protected], Telephone: 201-748-6903, John Wiley \& Sons, Inc., 111 River Street, MS 8-01, Hoboken, NJ 07030-5774.
DESIGNING PLATFORM INDEPENDENT MOBILE APPS AND SERVICES
ROCKY HECKMAN
Cover image © gettyimages.com
Copyright © 2016 by the IEEE Computer Society, Inc. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey. Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Names: Heckman, Rocky, author. Title: Designing platform independent mobile apps and services / Rocky Heckman. Description: Hoboken, New Jersey : John Wiley & Sons, Inc., [2016] | Includes index. Identifiers: LCCN 2016009419| ISBN 9781119060147 (cloth) | ISBN 9781119060185 (epub) | ISBN 9781119060154 (Adobe PDF) Subjects: LCSH: Mobile computing. | Cell phones--Programming. | Mobile apps. Classification: LCC QA76.59 .H43 2016 | DDC 005.25--dc23 LC record available at https://lccn.loc.gov/2016009419
Thank you to all my friends who finally convinced me to write a book. Most of all, thank you to my wife Stefanie, and my two beautiful girls Elyssia and Keiralli for not only pushing me to finish, but putting up with all the time I spent doing it. I love you all very much. Look Dad, I did it!
CONTENTS
PREFACE
ACKNOWLEDGMENTS
CHAPTER 1
THE MOBILE LANDSCAPE
1.1 INTRODUCTION
1.2 PREVIOUS ATTEMPTS AT CROSS-PLATFORM
1.3 BREADTH VERSUS DEPTH
1.4 THE MULTI-PLATFORM TARGETS
CHAPTER 2
PLATFORM-INDEPENDENT DEVELOPMENT TECHNOLOGIES
2.1 VENDOR LOCK-IN
2.2 RECOMMENDED STANDARDS AND GUIDELINES
2.3 WRAPPING UP
CHAPTER 3
PLATFORM-INDEPENDENT DEVELOPMENT STRATEGY
3.1 HIGH-LEVEL APP DEVELOPMENT FLOW
3.2 FIVE-LAYER ARCHITECTURE
3.3 FIVE-LAYER ARCHITECTURE DETAIL
CHAPTER 4
THE USER INTERFACE LAYER
4.1 PORTING VERSUS WRAPPING
4.2 MULTI-CLIENT DEVELOPMENT TOOLS
4.3 CROSS-PLATFORM LANGUAGES
4.4 AVOID WRITING FOR THE LEAST COMMON DENOMINATOR
4.5 WRAPPING UP
CHAPTER 5
THE SERVICE INTERFACE LAYER
5.1 MESSAGE PROCESSING
5.2 MESSAGE PROCESSING PATTERNS
5.3 HIGH-VOLUME MESSAGING PATTERNS
5.4 HIGH-VOLUME PUSH NOTIFICATIONS
5.5 MESSAGE TRANSLATION AND ROUTING
5.6 WRAPPING UP
CHAPTER 6
THE SERVICE LAYER
6.1 THINKING IN NODES
6.2 PLANNING FOR HORIZONTAL SCALING
6.3 DESIGNING SERVICE LAYERS FOR MOBILE COMPUTING
6.4 IMPLEMENTATION ABSTRACTION
6.5 USING CQRS/ES FOR SERVICE IMPLEMENTATION
6.6 SIDE BY SIDE MULTI-VERSIONING
6.7 SERVICE AGILITY
6.8 CONSUMER, BUSINESS, AND PARTNER SERVICES
6.9 PORTABLE AND MODULAR SERVICE ARCHITECTURES
6.10 WRAPPING UP
CHAPTER 7
THE DATA ABSTRACTION LAYER
7.1 OBJECTS TO DATA
7.2 USING THE DAL WITH EXTERNAL SERVICES
7.3 COMPONENTS OF A DAL
7.4 WRAPPING UP
CHAPTER 8
THE DATA LAYER
8.1 OVERVIEW
8.2 BUSINESS RULES IN THE DATA LAYER
8.3 RELATIONAL DATABASES
8.4 NOSQL DATABASES
8.5 FILE STORAGE
8.6 BLENDED APPROACH
8.7 WRAPPING UP
CHAPTER 9
STRATEGIES FOR ONGOING IMPROVEMENT
9.1 FEATURE EXPANSION
9.2 DATA COLLECTION MATTERS
9.3 MULTI-VERSIONING
9.4 VERSION RETIREMENT
9.5 CLIENT UPGRADES
9.6 WRAPPING UP
CHAPTER 10
CONCLUSION
REFERENCES
INDEX
EULA
List of Tables
Chapter 2
Table 2.1
Chapter 5
Table 5.1
Table 5.2
Table 5.3
Chapter 6
Table 6.1
Chapter 7
Table 7.1
Table 7.2
Chapter 8
Table 8.1
Table 8.2
Table 8.3
Table 8.4
Table 8.5
Table 8.6
Table 8.7
Table 8.8
Table 8.9
Table 8.10
Table 8.11
Table 8.12
Table 8.13
Table 8.14
Table 8.15
Table 8.16
Table 8.17
Chapter 9
Table 9.1
List of Illustrations
Chapter 1
Figure 1.1
Duke
Figure 1.2
Breadth versus Depth
Figure 1.3
Excel Online https://office.live.com/start/excel.aspx
Chapter 2
Figure 2.1
SOAP Message Format
Figure 2.2
User Satisfaction versus Response Time
Figure 2.3
System Unreachable
Figure 2.4
Hash-Based Dupe Message Detection
Chapter 3
Figure 3.1
High Level App Flow
Figure 3.2
Five Layer Architecture
Figure 3.3
Service Interface Layer Routing
Chapter 5
Figure 5.1
Many to One Pull Message Queue
Figure 5.2
Point to Point Channel
Figure 5.3
One to Many Publish/Subscribe Message Queue
Figure 5.4
One to Many Push Message Queue
Figure 5.5
Event Hub Offsets
Figure 5.6
Multiple Proprietary Push Notification Services
Figure 5.7
Using a SaaS PNS
Figure 5.8
SaaS PNS Routed Through TFS
Figure 5.9
Message Translation Chaining
Figure 5.10
Content Enricher Pattern
Figure 5.11
Content Filter Pattern
Figure 5.12
Claim Check Pattern
Figure 5.13
Service Bus Relay with Outbound Service Connections
Figure 5.14
Split Service Layer for Internal and External Hosting
Figure 5.15
Cloud Hosted SIL as a DMZ
Figure 5.16
Data at Rest on Premises
Figure 5.17
Components of the SIL
Chapter 6
Figure 6.1
Compute Nodes
Figure 6.2
Cost Per User Comparison
Figure 6.3
Node Efficiency with User Growth
Figure 6.4
Monolithic Service Deployment
Figure 6.5
Componentized Service Deployment
Figure 6.6
Message Routing
Figure 6.7
Incorrect Service Deployment
Figure 6.8
Clients Grouped in UI Layer, Services Behind the SIL
Figure 6.9
CQRS
Figure 6.10
Tradeoff Triangle
Figure 6.11
CQRS Write Side
Figure 6.12
Related Independent Services
Figure 6.13
Round Robin Load Balancing
Figure 6.14
Message Router Normal Configuration
Figure 6.15
Instance One Out of Rotation and Updated
Figure 6.16
Instance Two Out of Rotation and Updated.
Figure 6.17
All Instances Updated
Chapter 7
Figure 7.1
Typical Logical Interaction Flow
Figure 7.2
Physical Interaction Flow
Figure 7.3
Customer Class
Figure 7.4
QM Data Aggregation
Figure 7.5
Repository Over a Polyglot Data Layer
Figure 7.6
Polyglot Serialized Data
Figure 7.7
DAL Components
Chapter 8
Figure 8.1
Basic Data Storage Mechanisms
Figure 8.2
CQRS/ES with a Single Relational Database
Figure 8.3
NameInfo and AddressInfo Families
Figure 8.4
Graph Database Sample
Figure 8.5
Data Layer Components
Figure 8.6
Polyglot Data Storage
Chapter 9
Figure 9.1
Type One Cluster Distribution
Figure 9.2
Type Two Cluster Distribution
Figure 9.3
Type Three Cluster Distribution
Chapter 10
Figure 10.1
The Five-Layer Mobile App Architecture
Guide
Cover
Table of Contents
Preface
Pages
ii
xv
xvi
xvii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
107
108
111
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
218
219
220
221
222
223
224
225
226
227
228
229
230
PREFACE
I WAS WONDERING how to start this preface, and it occurred to me that writing one is backwards. After all, this is the text before the book, but you write it after the book is finished. I suppose that is analogous to how we have written software for a long time. We figure out what it is we are trying to do usually though creating systems that do what we think we want them to do; then we go back and write the documentation about what the system actually does.
This book, in large part, is aimed at helping to make that a more harmonious effort. Technology is moving so fast now that often we find ourselves trying to create mobile apps and services in a very reactionary manner. We tend to be on the back foot and playing catch up most of the time. If we could just take the time to sharpen the proverbial axe, we'd be able to get more accomplished, faster, with a lot less hair pulling.
I suppose over the past couple decades of doing this, I've seen that pattern time and time again. But there are also some good habits and patterns that I've seen along the way that in some respect were ahead of their time. Service-oriented architecture, for example, was a great idea for connecting the myriad of systems we've had inside organizations with simple, easy-to-use interfaces. In fact, this tried-and-true pattern, or collection of patterns if you will, is more relevant today in our commodity cloud computing, mobile app world than ever before.
This book is designed to provide some high level architectural guidance on how to design modern mobile apps and services so that they can adapt as technology inevitably changes. Of course, we start off with a brief history of our mobile computing explosion, and take a look at attempts to create cross platform apps and technology stacks.
Then I want to introduce what hopefully has become an obvious application stack. While we have been fairly fixated on a N-tier stack, where N usually equaled three, to truly futureproof our architectures, we really need two more clearly defined layers to provide us an abstraction boundary which insulates our code from changes in external client technology, as well as the rapidly changing data storage technologies we use today.
Once we have our layers sorted out, we'll have a look at various patterns of application development and how they apply to this layering system to create performant and resilient services for making powerful mobile applications.
I hope that you find this guidance useful. Perhaps it will make you think of things in ways you hadn't before, or validate thinking you've already implemented. In any case, I hope it prevents you from having to operate in a reactionary manner to the rapid changes of our modern computing world and lets you get on the front foot so you can focus on creating great apps and services instead of retooling everything because a new phone hit the market.
Target Audience
This book is for anyone who is responsible for the design, architecture, and development of modern mobile apps and the services that support them. I've written this book with futureproofing in mind. Ideally, the architectures and patterns in this book will provide you with an approach that will futureproof your designs.
By following this guidance, you should be able to create mobile app services that you can adapt, modify, update, change, or integrate without disrupting your mobile apps, or your teams. You should be able to deploy new services, change existing services, and add new client apps all without disturbing any of the running systems.
Most of all, you should be able to adapt services and apps based on this guidance to any new mobile platform that comes along. This will greatly increase your code reuse, make your teams much more efficient, and make your organization adaptable to the ever-changing mobile app landscape.
ACKNOWLEDGMENTS
These kinds of things don't happen without a lot of people in the background pushing, pulling, helping, and sometimes simply nodding and smiling. I would like to thank Chris Bright for encouraging me and allowing me the time to put this together. I'd also like to thank Andrew Coates and Dave Glover for letting me harass them with ideas, and “what if” questions all the time.
Most important of all, I need to thank my wife Stefanie Heckman, and my two girls Elyssia and Keiralli. They not only encouraged me to finish, but were patient with me, and gave me the time to keep typing away. I think, in the end, their love and enthusiasm are what really got this book over the line. So if you like it, don't forget to thank them too.
CHAPTER 1THE 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 and you can use web apps. Well, that's the idea anyway. In reality this proved much more difficult than anyone hoped. Prior to HTML 5 you naturally had HTML 4. HTML 4 was still largely just a markup language designed to handle content formatting. Web pages displayed in the browsers were largely static text and images. Then early browsers such as Netscape and Internet Explorer 3 incorporated a JVM to interpret the Java code in the web pages. Web server software such as Apache and Internet Information Services could also run server-side Java code and send the product of the code back to the browser as an HTML page.
This worked pretty well, up until Sun sued Microsoft and they stopped including the Microsoft JVM with Internet Explorer. Since at the time it had become the world's most popular browser, that was a problem for Java-based web apps. It forced users to manually install a JVM from Sun which was an extra step most people weren't overly fond of.
This resulted in some interesting changes. Netscape produced its own web programming language called LiveScript in 1995, which it then changed the name to JavaScript when it introduced Java support in Netscape 2 in 1996. Meanwhile in the same year Microsoft produced Active Server Pages (ASP) and in an attempt to get around the Java JVM problem, it also included VBScript for the coding portion in ASP. JavaScript pretty much won the client-side scripting battle when Microsoft included support for it in Internet Explorer 3 but had to call its version JScript. JavaScript became adopted as a standard known as ECMAScript which is in its fifth edition (5.1) released in June 2011.
In order to do interesting things with web apps, we needed to do things that HTML 4 simply couldn't do on its own. So one of the first things that was built into web browsers was a JavaScript interpreter. Now you could run scripts in web pages that could do things like display today's date, manipulate text in text boxes, and rotate pictures. This was nice, but in the days of Mosaic/Mozilla, Netscape, and Internet Explorer 3, it was really pushing the envelope.
To get a bit more out of the web apps, people started developing plugins for web browsers for things like audio and video. Macromedia introduced Flash in 1996 and it opened up all kinds of new opportunities to do very advanced graphics in a web browser through the Adobe Flash Player. By 2000, Flash was everywhere and even used to produce some animated TV commercials and 2D programs [6]. Around the same time in 2007, Microsoft introduced Silverlight which was a competing technology to Flash and offered audio, video, and graphics for web apps.
At the time, HTML had been reduced down to something like the following:
<HTML> <HEAD></HEAD> <BODY> … </BODY> </HTML>
Everything between the <BODY>…</BODY> tags were references to JavaScript and plugins of some sort that offered extended capabilities that were not part of the HTML4 specification. This included embedded audio, video, and pluggable content.
The core of the problem was that while HTML was an open standard that everyone understood and agreed on, things like Silverlight and Flash were not. This lead to controversy about its use and widespread adoption due to the dependency on proprietary technologies. In fact David Meyer quoted Tristan Nitot of Mozilla as saying:
“You're producing content for your users and there's someone in the middle deciding whether users should see your content,” [7]
This sentiment essentially created a mistrust of proprietary technologies that started developers looking for standards bodies to create web standards that could fill the voids that things like Silverlight and Flash handled.
Although these technologies are still prevalent today, they met with some resistance in the mobile computing era. Some of it was due to Apple initially not allowing Flash to operate on its iOS platform. While this was fixed by allowing Adobe AIR apps to run on an iPhone which wrapped Flash content, it was enough for Adobe to re-evaluate its position on Flash and to withdraw support for Flash on mobile devices in 2011 unless it is embedded in Adobe AIR applications. Instead, they plan to “aggressively contribute to HTML5.” [8]
Android having become the most popular platform by 2014 allows users to develop their apps in Java. This has brought a resurgence of development into the Java camps and solidified the once flagging language as a pre-eminent language in the mobile app development space. Eclipse tends to be the Java development environment of choice for Android apps as well.
This was an excellent move on Google's part because there were a lot of Java developers out there already. They could bring their existing skill set to developing for Android. This made the transition easy and afforded Google a huge advantage in catching up and surpassing Apple in the numbers of apps available in the Google Play store. You can also write apps for Android in C and C++ if you chose. This freedom has led to Android being the first platform people tend to release apps for.
Microsoft tried to keep Silverlight alive by allowing developers to create Windows Phone 7 apps in Silverlight. But their preference was for HTML5-based apps for Windows Phone and in versions of Windows Phone after Windows phone 8, Silverlight is no longer the platform of choice. You might say Silverlight is not a forward looking option for Microsoft. Microsoft also has a strong support for HTML5 app development in its platforms and has recently adopted the Apache Cordova framework for developing cross-platform apps in its Visual Studio product.
This myriad of technologies, plugins, mixed standards, and a very high dependence on browser version caused the web apps explosion to become muddled and difficult to develop for. Many lines of web app code are dedicated to just figuring out which browser and what version you are running in so you can do things slightly differently. You would have to check to see if a particular plugin was installed like Flash or Silverlight. You had to check to which browser version to know what kinds of scripting the browser supported and then run the version of the script for that particular browser version. To put it mildly, it was a nightmare. Having to write several different versions of the same code in the same web page to accommodate all the possible browsers their versions and plugins drove most web developers to liver failure due to excessive drinking. There were simply too many competing technologies amidst the browser wars.
1.2.3 Multiple Codebases
When it came down to it, developers knew they needed to support multiple platforms one way or another. They had executives wanting the apps on the latest buzzword compliant device. They had IT staff wanting their monitoring apps on the myriad of different devices they used and then they had their customers wanting the apps on every PC, smartphone, and tablet ever made in the 1990's. They had to come up with something so they ordered pizza and got down to duplicating their apps on every platform that 90% of their users used. Typically this meant Windows for desktops and laptops, iPhones and iPads running iOS, and Android-based tablets and phones. At a minimum, it was three separate development exercises. Windows apps were written with the usual Visual Studio and .NET combination. iOS apps required Xcode running on Apple hardware to write Objective-C apps. Android's Java-based apps were normally written in Eclipse on Windows- or Linux-based machines.
If you want to cover these three platforms you need at least two development machines: an Apple Mac and a Windows- or Linux-based machine. This was a real problem because not only did you pay more for extra hardware, but you needed more desk space. Early on, you couldn't write apps in Visual Studio for an iPhone or Android. You couldn't write Windows apps with Xcode. So you were forced to duplicate your equipment, effort, time, and skillset to cover the cross-platform world. But when you were done, you had apps on all the platforms that worked really well on the platform. Of course, if you wanted to add or change any features, you had to do it three times.
This also meant that you had to keep track of three sets of source code, and more importantly track three separate lists of bugs. If a severe bug showed up on one platform and not on the other two, you had to update and release just that one app. This could become a real problem. For example, if your Android app was full of security holes and issues that were present on some versions of Android and not others, it was very difficult to keep up with it all and keep the Android app patched without getting too far out of sync with the Windows and iOS versions.
Then of course there is the problem of the three different environments having very different capabilities. For example, you can create complex large databases for your app on Windows running on a laptop, but you can't do that in an iOS or Android app because they don't run on devices with large hard drives and lots of memory. So the Windows version tended to get ahead of the iOS and Android versions when it came to features. This often lead to developers creating their main apps on Windows, and having companion apps on iOS and Android that provided a subset of the features of the Windows version, or that complemented it extending the app to mobile devices.
As time went on and mobile computing became the norm rather than the exception, the iOS/Mac combinations were developed first, and web apps developed for internal usage or other platforms. In most cases, line of business apps is being developed for iPads, as much as for desktop computers. Server-side services are almost exclusively in WS* or RESTful web services. This has put web technology development in the lead, followed closely by native Android and iOS apps.
This is a very expensive way to do app development. It's not just the cost of the extra hardware. You duplicate your source code storage, management requirements, and man hours and worst of all; it requires some very different skill sets, which means you essentially maintain three development teams for one product. Then inevitably when the next big thing comes along, and the PC or device lead changes hands again, you have to scramble to re-skill for the new platform and create yet another set of source code or development systems.
This tends to cripple most small shops and they are forced to focus on one platform. Large development shops and large organizations with their own IT departments and development staff tend to choke on budgetary issues and time to market issues due to the complexity of launching on multiple platforms. Up until now this has made it near impossible for all but the largest companies to do multi-codebase development.
That is what this book is all about. I will cover the improvements to cross-platform standards, improvements in cross-platform development tools, and most importantly strategies you can implement to achieve cross-platform app development with minimal overlap, duplication, reskilling, and cost.
1.3 BREADTH VERSUS DEPTH
One of the things that every app developer wants is for millions of people to use and love their apps. This means they need to be able to reach as many potential users as possible. This also applies to enterprise line of business (LOB) app developers that have to develop corporate apps that will work on any device employees have in the ‘bring your own device’ world. The catch is that for their app to have a rich engaging experience, it has to work on whatever device the user has at the time. Unfortunately this means that if you want a rich experience on iPhone, for example, you have to develop the app strictly to run on an iPhone. This app won't be able to run on a Windows Phone or Android-based phone. If you want to reach Android users you have the same problem. You can create an amazing app on Android, but it won't run on iPhone or Windows Phone. This is the breadth versus depth problem that app developers face when deciding which platform to target as illustrated in Figure 1.2.
Figure 1.2 Breadth versus Depth
In the past, developers have had to decide on the trade-off between reaching as many users as possible and the rich feature set which requires very device specific code. This has led to them picking the platform that has the most local market share that day. There are effectively three relevant platforms in the mobile space at this time: Android, iOS, and Windows. In this book, I will consider these three major platforms as our baseline.
This leaves us with a problem. If you are developing apps for mobile devices, which one do you choose? Choosing one means that in a few months or years you could be cut out of 60% or more of the addressable market. Putting all of that work into something that will be usable by less than half of the market is not very attractive.
There are some alternatives. You could make a responsive website that works on all mobile devices and adapts to different screen sizes. This gives you the broad reach across the user base but web apps tend to be very restricted to the features you can use. With technologies such as Phone Gap using HTML5, CSS3, and JavaScript as their primary programming stack, you effectively develop web apps, wrap them in a native app frame, and upload them to the app store. It's just HTML though, is that feature set rich enough? HTML5 has tried to fix that.
HTML5 has given developers the ability to create fairly rich web apps that can do most basic things native apps can do. HTML5 apps can access the location information on the device, local isolated storage, stream audio and video, and even replace Flash with the canvas elements that are available. With HTML5 it is possible to create very functional business applications such as Excel Online shown in Figure 1.3.
Figure 1.3 Excel Online https://office.live.com/start/excel.aspx
This is a very functional version of the Microsoft Excel that includes formatting, cell formulas, graphs, and data imports.
You can also create rich non-Flash games such as The World's Biggest Pac-Man. The World's Biggest Pac-Man (http://worldsbiggestpacman.com/) even allows users to create and upload mazes of their own for other players to play, all built with HTML5.
With HTML5 comes instant reach. Every major platform has an HTML5 capable browser that makes these web apps available to the users of those platforms. As good as this is, these web apps still lack important features like browser-independent off-line capability, access to other local documents and apps, integration with local contacts, e-mail, and calendars, etc. You still have to trade some features for reach. On individual platforms, native apps will be more attractive than web-based app in some circumstances.
1.4 THE MULTI-PLATFORM TARGETS
1.4.1 Traditional
By traditional platforms I am mainly referring to websites and clients in a client-server configuration. These can certainly be called multi-platform as different web browsers have different capabilities. Additionally clients in client-server systems can be created on any platform providing that platform will allow communications with Internet-based services. This book really isn't concerned with thick clients as they tend to be self-contained and not normally mobile. That being said, you can certainly use the information in this book to create thick client apps that talk to a service back-end for whatever business, consumer, or game purposes you want.
This segment isn't really the one that developers think of when they think of new apps. However, it shouldn't be overlooked. The three major operating systems in play at the time of this writing, where apps are concerned, are Android, iOS, and Windows. iOS runs on iPhones and iPads, but not on MacBook or Mac desktops. Android and Windows however run on many more form factors. Android runs on phones, phablets, tablets, and notebooks. As of Windows 10, Windows runs on every form factor in common use today from embedded Internet of Things devices to phones, tablets, laptops, desktops, and large screen displays plus Xbox and HoloLens (www.hololens.com).
This is also why you need to make sure you don't walk into app development, thinking you are going to create an “iPhone” app or an “Android” app. If you do, you will certainly cut yourself out of a huge share of the potential market. If you don't consider the more traditional form factors such as laptops and desktops, you will miss the majority of the addressable market. There are still, at the time of this writing, more desktop PCs and laptops in use than there are iOS devices and Android devices combined. Go into this thinking cross-platform and cross form factor from the beginning. Don't cut yourself out of the majority of the market.
1.4.2 Mobile
This is a broad category but probably the one you are interested in developing for the most. After all, this is a book about mobile apps and services. It includes pretty much everything that is computerized, that is portable, but not that you wear. Phones, tablets, phablets, laptops, and other devices like these. Any device that a user can carry likely has device location capabilities, gyroscopic sensors, and cameras which open up a lot of new scenarios and potential for your mobile apps and services. This does apply to wearable and embedded devices as well but we'll cover those in a bit.
This is also the category that most people think of when they think of mobile apps. There are a lot of new developers coming on board, probably some of you reading this right now. This is the fastest growing segment of app developers. With millions of mobile apps in various app marketplaces, and some people making billions of dollars on them, it's not very surprising that this is such a hot topic. For your app to be successful, it has to offer a compelling user experience and features. It doesn't matter if it's a game, a family management app, or a business application; it will need to stand out amongst the crowd for you to be successful.
The app explosion, and accessibility of the tools, means that anyone with a good idea and some motivation can create good apps from the comfort of their home. This segment is making millionaires by the week with apps deployed to millions of people that only cost one dollar. Why not reach as many of those potential users as you can?
To reach this kind of success, an app that is integrated with a user's lifestyle, that connects them to the world, and that offers powerful features is required. You need to add value to their device, regardless of form factor, CPU power, RAM, or battery life. This means being able to extend beyond the device for connection to the world, and connection to more computing power than is available in the users' hands. Solid back-end services will get you there. These services will provide your app an edge over the myriad of other similar apps in the marketplace that are limited to the shell of the device.
1.4.3 Wearables
This is an emerging category in the mainstream. Even though the idea of a network-connected smart watch has been around since 2003 [9] and maybe before, they are starting to get a lot of public attention and most major manufacturers are coming out with watches or some other form of Internet-connected wearable computing device. If you are a Star Trek Next Generation fan, think of the communicators built in the Insignia on the uniforms. It provided not only communications, but also vital signs reporting, location reporting, and other network-connected services. From a more mundane perspective, think of smart watches, fitness bands, and glasses.
Now we even have fully self-contained holographic displays like Microsoft's HoloLens, an entire wearable PC that is less than the size of a bicycle helmet. HoloLens enables full persistent 3D holograms projected into your world. It comes complete with everything you'd expect in a mobile device such as location, cameras, and sensors, but includes the storage and CPU power of a desktop PC without the wires and goes where the user goes. This kind of thing introduces new gesture-based computing features and possibilities that we have only just begun to imagine.
Everyone will have some kind of wearable in the near future. In some cases they may not even know it. The ubiquitous nature of wearables such as new watches that have some kind of minimal GPS capability and health monitoring in them opens up very personal computing experiences for mobile app developers.
Many wearables are touting health and medical benefits. They can track everything from duration and route of walking, bicycling, and swimming to heart rates and even ultraviolet ray exposure and potentially glucose levels [10]. These kinds of lifestyle aspects make wearables attractive to certain segments of the population. In industry, think of patients, athletes, and military personnel. The military is already using wearable computing technology to track the heath of soldiers in addition to location, and transmitting live audio and video through satellite networks to command and control centers. Professional sports are using it to track things such as how far a player runs during a soccer match, to impacts they take in NFL games which may indicate they should undergo concussion screening.
For wearables to be useful, they have to be lightweight, with extended battery life. They tend to focus on data collection and upload. More advanced ones such as the Apple Watch, Android Wear, and Microsoft Band offer limited computing capability, but tend to integrate with the user's mobile phone. This means offloading processing power is critical. Being battery friendly is just as critical. A watch that you have to charge twice a day isn't very useful. A fitness band that doesn't last a marathon is equally as useless. Glasses that make you gyrate your head and stare off into space will disrupt the normal in-public interactions. Wearables need to blend into our lifestyle and enhance it, not disrupt it. The services that power them can be powerful, and add a great deal to a user's lifestyle making them very attractive if they are built right.
1.4.4 Embedded
This category comprises all of the devices that contain an Internet-connected System on a Chip (SoC) or small computer such as Arduino, Raspberry PI or other proprietary systems. This devices are colloquially called the Internet of Things. The category isn't new, and we've had computers and applications buried in various things around the industry for many years. Cars have had embedded systems that mechanics would use to monitor and tune the car with. Racing has used this approach quite heavily for several years. Now that it is becoming easier to do with more SoC processors and operating systems, we even have drink vending machines with advanced processing capability in them [11]. These vending machines can look at you with built in cameras, and fairly accurately guess your sex, age, and height. They then feed this demographic data, along with your drink choice, up to cloud-based processing systems to aid in their marketing and machine placement choices. Not to mention the boring aspects of how much of which drink is left so the delivery person knows exactly how much of which drink to restock the machine with.
Gaining access to data that help with demographics and large-scale trend analysis is perhaps one of the largest areas of interest in the Internet of Things movement. Consider areas of home appliances. If you were a large grocery store chain owner, what could you do with a Smart Refrigerator? A fridge that knew what was in it, what the expiry dates of the various things were, and what kinds of things this particular family like to eat? With that kind of data you could automatically e-mail the family specials on items they need, recipes for food that they can make with things in the fridge that are about to expire, or allow them to integrate their food habits with their family doctor's records so he can make sure they aren't on the road to diabetes. The possibilities are boundless. It's a great time to be a mobile app service developer.
This is also the area that requires the most high performance data injection systems. When you start to consider all of the potential devices that will have Internet-connected computers in them, the numbers start to get very impressive. Consider smart utility meters. Every home will have one. How many devices are there, just in your city? How about New York, Hong Kong, or New Delhi? There are over 8.4 million people in New York City alone. If these meters and devices are all reporting daily, you will have to be able to scale to handle that traffic during reporting times, and scale back during non-reporting times or in the cases of personal devices, handle that kind of traffic on pretty much a 24/7 schedule.
So as you can see, we are in a situation in the industry where we need to think proactively about how we are going to future proof our designs. For a very long time we've been working on the back foot trying to create cross-platform technologies that haven't quite hit the mark. This is in large part due to the fact that one specific technology may never be all things to all people because by the time it's done, there will be a new platform to contend with. With proper planning and a solid architectural approach, you can minimize the impact of cross-platform development for your apps and service. In this book, I will present some of the architectural patterns and features you can use to create and deploy rich cross-platform app services that will be comparatively easy to maintain across current and new mobile platforms.
CHAPTER 2PLATFORM-INDEPENDENT DEVELOPMENT TECHNOLOGIES
THIS BOOK IS about designing platform-independent app services. This means I'm going to keep things fairly “architectural” and component level. I'm going to try to avoid getting into too many implementation specifics such as code examples. Except for a couple of cases I'm going to try not to delve too deep into particular vendor implementations either. While this sounds disappointing to some, there's a good reason for it.
In today's mobile app services world, you can use pretty much whatever technology you want to as long as it gets the job done efficiently. There are a few technologies that are rising to the top as the broader choice in the industry, but use what works for you as long as you can build the patterns discussed in this book. If I go into too much C# and you are a Java programmer, you'll spend more time translating the code to Java in your head than understanding the bigger picture. Besides, there are thousands of books out there already on how to program in C#, Java, JavaScript, Python, Ruby, PHP, etc. They will cover the specifics a lot better than I can do in one book here. Which brings me to my Golden Rule (well for this book anyway).
The Golden Rule
I've been around a while and seen a lot of apps. I've been supporting, developing, designing, troubleshooting, securing, and consulting on software and apps for about 17 years. So I have some experience and observations from both the ivory towers and the trenches. There are a lot of books and articles out there on what's best and what you should do, but I have a golden rule. This golden rule is something you should commit to memory, don't worry it's a pretty simple rule. Throughout this book, there will be lots of advice, architectural patterns, and design guidelines that should help you create better, more efficient, and highly scalable mobile apps and services. However, you should always apply the golden rule. There are a lot of Rules of Thumb in this book, put those on a poster near your desk, with the golden rule at the top. The golden rule is:
Always do what makes the most sense for your situation.
I may give an example of a game that requires high-speed message transfers to hundreds of clients. Don't just say “yeah but I am writing a live trading app” and dismiss things. The principals will apply and you should adapt them for your situation. Keep your big picture in mind.
2.1 VENDOR LOCK-IN
Inevitably when I am discussing a level of platform-independent delivery or a particular cloud technology with an ISV, large multi-national, or 4 man software development shop, someone will say, “Our policy is that we do not do anything that locks us into a particular vendor.” That's wonderful. Good luck with that. Now let's get to the reality of computers.
Something I want to point out, There is no way with current technology to create a truly and utterly vendor agnostic and technology-independent system. At some point, you are going to have to commit to using some technology. Be that Windows or Linux, Java or C#, Amazon Web Services, Microsoft Azure, or Google Cloud Services or this database or that NoSQL Store. Once you decide, there will be things that you do that conform to that technologies' manner of interacting with your developers and the greater world. Unfortunately, each technology vendor does things in a slightly different way, which means that either syntactically or architecturally you will be constrained to some degree. You just have to live with this because it's how the world works.
It's not a bad thing in some cases because some technologies are inherently better than others for particular use cases. So when you use that technology, and you use it the way the vendor intended you will get the most value out of it. If you try to avoid any and every vendor-specific nuance of the technology, you will not get the most value out of it. I get so frustrated when people say “We don't want to use X or Y technology because we want to be completely vendor agnostic.” If you truly want to achieve that, then you will need to design your own silicon, servers, operating systems, programming languages, network protocols, applications, and even devices to view them on. I think you can see that this is not practical. So in the real world you have to accept that there is some level of vendor-specific interactions you are going to have to use.
