Objectives of this chapter:

• The evolution of mobile application development
• Different ecosystems: Apple, Google, Microsoft
• Problems with ecosystem-based applications
• Hybrid mobile applications
• Front-end and back-end development
• Testing of mobile applications

Today mobile device users prefer to use applications installed on their smartphones. They use installed applications (apps) for carrying out routine activities like booking cabs, buying movie tickets, and watching videos on YouTube.

This trend is confirmed by Gartner, which has this to say: “Enterprises are finding that they need to support multiple platforms, especially as the BYOD [bring your own device] trend gains momentum.” (See www.gartner.com/newsroom/id/2324917.)

In addition, the app-only trend, set by e-commerce companies like Flipkart and Myntra indirectly supports this BYOD trend. App-only means that an application, which used to be available through a desktop web browser as well as a mobile device, stops operation of the web application, forcing the customer to access the application through a mobile app only.

The market share of mobile devices is divided mainly into Android, iOS, and Windows Phone. Because of the differences in platforms/operating systems, creating an installable mobile application that targets multiple device platforms requires too much of effort and expertise. For example, you have to write code in Java for Android, in Objective C for iOS, and in .NET for the Windows Phone. Shortcomings of this development approach are as follows:

• More development time
• Different expertise required per platform
• Considerably high cost of development

This can be overcome by using hybrid mobile applications, a solution based on HTML 5, JQuery, and CSS 3. These hybrid applications are created once, but after packaging can be deployed on multiple mobile devices such as Android, iOS, and Windows Phone.

This kind of application development has an edge over “native” application development. A Gartner survey has predicted that by 2016, more than 50 percent of mobile apps deployed will be hybrid.

Key benefits of this development approach are as follows:

• Less development effort
• Lower cost
• Common set of technical expertise required

Development of mobile-based applications depends on many factors, including the features available on the mobile device itself. One of the key parameters to consider in development is the OS platform and available screen sizes on devices.

History of Mobile Application Development

How did mobile application development (ecosystems) evolve? Let’s briefly review the timeline. Figure 1-1 shows how a mobile application development process evolved over time.

In 1983 came the Motorola DynaTAC 8000X cell phone—the first commercial cell phone. People called it a brick because of its 2.5 pound weight! It was sold at the price of $3,995! This phone could do little more than calling.

The first innovations came from Nokia and other manufacturers who took this technology to another level by adding more functionality, including games such as Snake and Ping Pong. In the 1980s and ’90s, mobile users had few offerings to choose from device vendors. Mobile applications were limited to those preinstalled by vendors. However, some vendors did offer applications using the Wireless Application Protocol (WAP). These applications were available from the phone manufacturers.

In November 1993, IBM launched Simon It had preinstalled applications such as a calendar, a clock, a calculator, a notepad, and email. It also had a stylus!

In 2002, Research In Motion Limited (RIM), now BlackBerry Limited, released its first device with integrated phone functionality. The product line eventually evolved into the first mass-market smartphone optimized for wireless e-mail. Mobile device users still had to wait until 2007 for a revolutionary change!

In 2007, Apple released the first iPhone, followed by the App Store launch. Users now had lot of choices for installing applications easily. A few months later, this was followed by the launch of the Android Market by Google, and the first Android-based smartphone from HTC called HTC Dream.

Apple offered its first iPad in 2010, giving users the option to use apps from their App Store. In the same year, Samsung launched a tablet named Galaxy based on the Android OS.

Understanding Ecosystems

Before proceeding, let’s try to understand the ecosystems of mobile application development. To make things simple, this section introduces the three giant vendors/manufacturers in this space: Apple, Google, and Microsoft.

When a client targets a particular audience for a mobile application, how do you decide which vendor or platform to go with? This depends on multiple factors, ranging from region, location, language, domain, features required, delivery time, development team, and many more.

The Apple Ecosystem

Imagine that a client chooses a range of Apple devices for deploying an application. The Apple platform is a big ecosystem. As you may know, the iPhone, iPad, and MacBook all fall under the Apple ecosystem. These devices benefit from being in the same ecosystem, as a single store distributes iOS-based applications. Apple verifies applications and grants permission for sale based on its guidelines for acceptance.

Apple also promotes development of applications targeting the Apple ecosystem, by offering many common APIs and a common approval process. Development is made easy by Objective C and the Xcode IDE, along with many APIs to natively access (meaning at the device level) features in the app such as a camera and location.

If the application is a paid one, the revenue-sharing equation is commonly at a 30:70 ratio; Apple takes 30% of the revenue, and the application owner takes 70%. Even if the application cost includes charges paid to a service vendor such as SMS gateways, Apple still charges 30% of the total. But in any case, the Apple platform is one way for application developers to earn good revenue.

The Google Ecosystem

Let’s say the same client needs to target the Google ecosystem. Do we need changes in the application? Can we port the application as it is? Are certification guidelines for Google the same as for Apple? Is the revenue-sharing equation the same?

The short answer is no. The key thing to understand is that the Google ecosystem is different. You will have to consider Android-based devices. The Android OS is an open platform to manufacturers, so the market has many device manufactures compared to Apple. Because Android is allowed to customize, this only boosts the variety of available Android devices.

Because of the multiple device manufacturers, ultimately many devices vary in size, resolution, and available features, so this ecosystem has many challenges compared to Apple. For example, if you develop an application for a Samsung Galaxy Android-based phone, changes may be required if the application is ported to a Google Nexus device, because of resolution differences.

The good point in favor of Android is that unlike Apple, application development for Android- based devices is mostly in Java. This is one of the popular and older languages, so it is easy to find programmers in Java for Android, compared to Objective C or Xcode for Apple.

The Microsoft Ecosystem

The Microsoft ecosystem is similar to that of Apple. While working in the Microsoft ecosystem, you have to consider a range of devices, including the Windows desktop, Windows Phone, and Surface. Development platforms are the .NET Framework and XNA. Microsoft has the Windows App Store for distributing applications. The preferred IDE is Microsoft Visual Studio. Mainly C# and VB.NET are the languages used for development. The process and ratio of sharing benefits remains the same as that of Apple (70:30, in favor of the application owner).

Ecosystems Are Growing

These ecosystems don’t stop at phone or tablet devices. Many additions are occurring daily. Although this book focuses on mobile application development, today’s ecosystems also have new additions with devices such as TVs, wearable computers like Apple watches, and more. For those who are targeting these ecoystems, development is more complex Can’t we put all these devices under one giant umbrella or common ecosystem? That way, an application developed for iPhone could be easily ported to Android and also to a Windows phone.

As we discussed, developing applications around an ecosystem has benefits, such as native API availability and easy portability on devices within the ecosystem. That common ecosystem concept will need to be compromised when developing cross-ecosystem applications.

Web Sites and Web Views for Mobile Devices

Browsing web sites on mobile-based browsers is common nowadays. Web-site development has made a few terms popular, including front-end and back-end development.

For web developers, front-end development means designing the user interface (UI) for web sites. Back-end development means coding behind the UI, and authoring code on the server side by using ASP/JSP/PHP pages.

When you develop these pages for normal desktop-based browsers, you have the liberty of using huge real estate in terms of screen size. When the same pages are viewed or browsed with mobile-based browsers, limitations related to the smaller screen size become the first obstacle.

How many people really browse web pages on mobile devices? According to Internet.org, “As of October 2014, 55% of cell phone users browse the Web on their devices.” This is a huge segment that needs to be catered to.

How do you tackle the question of screen real estate? Responsive design of web pages, which resizes the UI based on the real estate (the screen size), becomes the solution. Today, CSS frameworks such as Bootstrap and Foundation provide CSS classes to design and develop responsive web sites. Web-site pages are rendered as the UI in a mobile browser. This web view can be common to many devices.

Adding JavaScript to the Mix

The browser, apart from HTML, can also understand one scripting language: JavaScript! What if a browser-based web view can be given knowledge about how to deal with native APIs and access device features through JavaScript? The web view, along with some code, can then compete with company-specific ecosystems such as Apple, Google, or Microsoft.

Can HTML-, JavaScript-, and CSS-based installable applications packaged for a particular device or manufacturer replace individual ecosystems? Can we package HTML, JavaScript, and CSS?

Partially, yes! This type of development is called hybrid application development.

Hybrid application development can be that larger common ecosystem that we talked about earlier in this chapter. Is it going to be limited to mobile devices only? No. This can be further extended to work with devices like TVs and watches. However, this book focuses on mobile applications only.

Will we get support from ecosystem vendors such as Apple, Google, and Microsoft? Because it’s a web view packaged as an application, there is no problem. The only challenge will be extending JavaScript APIs to talk to devices.

Hybrid Application Frameworks

As you know, JavaScript executes in the context of the browser, so how can JavaScript talk to devices?

Hybrid application frameworks such as Icenium, Ionic, and Angular UI can make JavaScript capable of communicating with common devices, in a common way through one common engine or library called Apache Cordova. Hybrid and non-native application development in this common ecosystem may have to compromise in terms of the number of APIs available.

When you decide to define a hybrid application for multiple devices (including Apple, Android, and Microsoft), to get the application certified, you still have to follow norms conveyed by each vendor/manufacturer!

However, the Icenium, Ionic, and Angular frameworks do provide APIs that enable you to create common components with a common UI.

Challenges by Mobile Application Layers

Let’s discuss challenges and solutions by application layers.

Front-End Development

When considering the front end in web technologies, one term promptly comes to mind: UI design. However, the front end is much more than only the UI. You have two separate and confusing terms to understand:

• User experience (UX)
• User interface (UI)

UX is not UI. Let’s take a simple example from web technologies. Your client wants to have a logo—an image—at the top of the home page. Where will you put it? If you are from Asia, based on your experience, you may place it at the top left. But it depends. Who can best solve this problem is a UX -er, also known as the client’s advocate.

UX experts are always confused with UI designers. UX-ers are not UI designers! For example, while defining native ecosystem-specific mobile applications, UX-ers are better at identifying the following:

• What customers really want in the interface
• How to provide a better experience on the small screen
• Based on the ecosystem, how the application can achieve certification
• Where to put which component
• Aesthetic structure and color scheme

A UI designer might design the interface based on the UX-er’s inputs. When considering ecosystem-specific mobile applications, such as Apple and Android, the design principles differ, as shown in Table 1-1.

UX - UI Problem

Because these guidelines are checked when the application receives a certificate from the ecosystem vendor, using the same user interface for many ecosystems is not possible in native application development. Note that native application in this context means one specific to a particular ecosystem.

Solution

Can you use a UI designed for one ecosystem as it is in another ecosystem? The short answer is no, due to the guidelines. However, for web browsers on mobile devices, the same guideline is used across ecosystems. You don’t want to develop a web site or web application, but an installable mobile application.

Then why not package the web site/UI along with the code as an installable application—that is, as a hybrid application? Cross-browser issues may arise, because of the browser hosting the application or because the application is running in the browser’s context. However, these issues are standard and may require less time to solve compared to redesigning the entire application for another ecosystem!

So, hybrid mobile application can be a solution here.

Back-End Development

Back-end development is again a complex term. On the Web, the back end refers to the code that may communicate with a server. In a mobile application development scenario, this term can have multiple meanings. Code that you write in a mobile application may do any of the following:

• Bind data with the UI(manipulate UI components)
• Get data from the UI
• Send and receive data to and from server
• Communicate with APIs offered by the ecosystems to access sensors
• Execute only business logic without a UI (for example, a service without a UI)

This functionality can be achieved by a mix of middleware components as well as including mobile app servers via Mobile Backend as a Service (MBaaS).

Sharing Back-End Code

Can you share the back-end code across ecosystems? If you are going to create a native application for an ecosystem, the language used for coding differs from that used in other ecosystems. So most of the code needs to be rewritten per ecosystem.

However, if the main business logic can be ported with service-oriented architecture (SOA), such as web services or WCF services, the logic can be reused for cross-platform and cross-ecosystem communication.

In an SOA approach as well, the logic to consume services may differ. So, the problem continues.

Solution

In hybrid mobile applications, most of the preceding code functionalities can be achieved by writing code in a single language, such as JavaScript.

In hybrid applications as well, a common business can be created as a SOA, the same as for native apps. Calling SOA inside the JavaScript code can be easy through AJAX calls, whereby you can have a choice of using the data format as XML/JSON.

Multiple JavaScript-based frameworks and libraries are available for achieving most of the code functionalities listed. One of the popular libraries based on JavaScript is JQuery. Hybrid application frameworks help JavaScript to communicate with native APIs, as shown in Figure 1-2.

System Software

Many components are required to develop an ecosystem-based mobile application, including an IDE, debuggers, emulators, and packaging tools. This section provides details about the tools required for ecosystem-based applications. Table 1-2 shows Android ecosystem tools, Table 1-3 shows Apple ecosystem tools, and Table 1-4 shows Microsoft ecosystem tools.

These tools are for building ecosystem-specific (native) applications. For hybrid mobile application development, you have many options and frameworks, such as these:

• Ionic
• PhoneGap
• Icenium
• Kendo UI
• Angular UI
• Sencha Touch
• Intel XDK

From this list, a few frameworks are freely available. Recently, Microsoft also launched a universal and mobile application project template, along with Android and iOS project templates, in Visual Studio 2015 to support hybrid applications using .NET (see Figure 1-3).

A company called Xamarin also did the same: the application needs to be created using .NET. Xamarin plug-in support is also added for Visual Studio (see Figure 1-4).

At the Worldwide Developers Conference (WWDC) 2015, Apple announced that Swift will be made available for hybrid application development.

Mobile Application Testing

Testing is an important phase of mobile application development. Mobile applications are initially tested with emulators. However, emulators have certain drawbacks—for example, you cannot test gestures such as a pinch. Because the emulator is a program used to test the application, code for accessing sensors cannot be tested in the same manner. You can use emulators to check mainly how the user interface will look on a particular device, whether the user interface remains within a boundary when the device rotates, how the UI behaves when a different screen size is used, and so on. If you need to test the gestures and sensors, testing on the actual device is required. In this case, we are talking about testing the features of the devices and not the application code testing.

Android Testing

To test an app for Android devices, you can copy the program’s output files (APK) directly onto the Android device and install it. To create a profile and upload applications to Google Play, you need to get a developer license at a cost of about $25 from Google.

Apple Testing

To test a program for Apple devices, you can create a developer profile first at the Apple app store for $99 a year. With the same profile, you can install and test applications on an iPhone. Registering 100 devices per product family is a cut-off limit for single developer profile.

Microsoft Testing

To test a program for a Windows Phone, you can create a developer profile first at the Windows marketplace, which costs $19 for an individual, and $99 for a company. With the same profile, you can install and test an application on a Windows phone.

Hybrid Testing

For hybrid mobile application testing, you can run the application as a web view inside the browser. To test the application’s look and feel on different screen sizes, you can use sites such as www.responsinator.com. After testing the UI look and feel, you can test the program against sensors or on specific features by installing the application on the device itself. But even installing this application on the device requires a license in the Apple and Microsoft ecosystems. Deploying these applications on the stores requires having a profile on the stores.

Summary

A mobile application development ecosystem is a virtual environment that supports development, deployment, and testing of mobile applications.

Application development can be categorized into front end and back end. Each category has its own challenges based on the specific guidelines of the vendor or ecosystem. Ecosystem vendors such as Apple, Google, and Microsoft help developers by providing various APIs for building applications, app stores for promotions, and a platform for consistency within the ecosystem. This type of development requires you to learn a specific language and tool.

Hybrid mobile application development can target a larger ecosystem, which can consist of devices from many vendor-specific ecosystems. This type of development requires you to learn a common language and tool. Each mobile application development approach has advantages and limitations.

You will explore more in the next chapter.