Mobile applications have become an integral part of our business lives and our personal lives. As such, they are used by many organizations in nearly all sectors to extend their reach and engage their customers, partners, and employees on the go. The rapid adoption of mobile, fueled by the growing market share of smartphone devices, is expected by many to continue increasing in proportion and become one of the main channels that users will use to perform routine daily tasks, access information, and conduct business transactions.
Because there are elements of mobile application development that differ significantly from traditional enterprise application development, organizations embarking on a comprehensive mobile strategy need to plan ahead and make sure all necessary stakeholders understand the high level process required for developing mobile applications. To offer some guidance, this article presents an overview of the eight major steps involved in developing, deploying, and publishing applications for mobile platforms, such as iOS and Android, using the IBM® Worklight™ mobile development platform.
Step one begins with understanding your mobile business requirements and defining your enterprise mobile strategy. The discovery phase plays an important role in the overall mobile application development lifecycle. It sets the mobile visions and strategy by analyzing your mobile challenges, goals, and constraints.
For example, you need to identify the types of mobile applications you need to develop, which could be mobile web, native, hybrid, or a combination of these. You also have to decide which mobile platforms to support; for example, iOS, Android, Blackberry, Windows® Phone, and so on. Figure 1 highlights the areas you need to consider when defining a mobile strategy.
Figure 1. Mobile strategy considerations
The other outcome of the discovery phase is to identify the key mobile presence and application enablement use cases for the business. These use cases or application ideas should be conceptualized into prototypes, wireframes, and mobile application storyboards.
In order to be able to deploy or publish your application via the various mobile app stores (such as Apple’s App Store or Google Play), all mobile platforms require an organization or individual to be a registered developer. Only registered developers can submit applications to a platform’s associated app store. Therefore, you need to register to these platform programs in the early stage of your development lifecycle.
- iOS: To test an application on a real iOS device or to prepare your app for app store release, you need to enroll in Apple's iOS Developer Program as either an individual developer or as a company. There is a fee associated with this registration.
- Android: Before you can publish an Android application to Google Play, you or your organization needs to set up a Google Play account. This is a three-step process, which includes creating a developer profile, agreeing to the Developer Distribution Agreement, and paying a registration fee using Google Checkout.
- Blackberry: To publish a Blackberry application to Blackberry App World, you first need to have a vendor account. Developers without a vendor account are not be able to submit applications for publication to BlackBerry App World.
- Windows Phone: Similarly, you must be a registered Windows Phone developer to submit your applications to the Windows Phone Marketplace. Registration can be completed at the Microsoft App Hub.
Proper setup of your Worklight development environment is a vital step in the develoing and testing of mobile applications. In a nutshell, you will install Eclipse and IBM Worklight Studio as your development IDE for Worklight mobile applications. Supported mobile platform SDKs will have to be installed as well. Optionally, you might also wish to set up a team development environment for source control management.
Worklight Studio is an Eclipse-based IDE; you need to install Eclipse on your workstation first before installing Worklight Studio. Worklight Studio is supported on Windows, Mac OS, and Linux® operating systems. If you plan to develop Worklight applications for iOS environments, you can do so on any of these operating systems. However, due to restrictions set by Apple, you can only compile an iOS project on a Mac OS machine.
- Installing Eclipse
The current version of Worklight Studio requires Eclipse Indigo (3.7.2). You can download Eclipse IDE at no cost.
- Installing IBM Worklight Studio
You can install IBM Worklight Studio after Eclipse has been installed. There are three editions of Worklight Studio available: Developer (which is available for download at no cost to get you started), Consumer, and Enterprise. Worklight Studio can be installed from Eclipse Marketplace, or using IBM Installation Manager, or as an Eclipse plugin. For installation details, see the IBM Worklight product library.
- Installing mobile SDKs
If you plan to develop hybrid or native mobile applications with Worklight, you need to install and configure the SDKs (and development IDEs) for the associated supported mobile platforms. The procedures might vary, depending on the platform, but here are steps you are likely to encounter with some of the popular mobile platforms.
- iOS: You must download Xcode, which is an Apple IDE for developing iOS and Mac applications. You can use Xcode to manage your testing devices, use an iPhone or iPad simulator, and install applications on an iPhone or iPad device.
- Android: You must install the Android SDK and Android Development Tools (ADT) plug-in for Eclipse. The Android SDK provides the tools and APIs that are required to develop applications on the Android platform by using the Java™ programming language. The ADT plug-in for Eclipse is an integrated environment in which you can build rich Android applications.
- BlackBerry: WebWorks application development requires that you download and install Blackberry Ripple Emulator, Blackberry WebWorks SDK, and Blackberry Simulator.
- Windows Phone: You must download and install Microsoft Visual Studio 2010/2012 and the Windows Phone SDK. You must also download and install Zune software in your development environment to run your applications on a Windows Phone handset.
- Prepare team development environment
Preparing the team development environment using, for example, IBM Rational® Team Concert, is an excellent idea for managing highly dynamic mobile application development. Keep in mind, however, that when managing Worklight applications with a source control system, some files generated by Worklight projects should not be added to the source control system. (See Resources)
Now for the fun part. Designers and developers work together to build mobile applications using the Worklight mobile platform and native mobile development tools.
Worklight does not limit the development process to coding in web technologies only. It generates the native application project for the targeted mobile platform in order to compile the native package for distribution through app stores. Device-specific native code can be added to these generated native application projects and combined with code written using web technologies.
Plan on unit testing mobile applications early and frequently during development. This is simply because mobile testing is challenging, given the wide range of possible devices and platforms for even a single application. Below are some testing methods and tools you can use for your Worklight applications in the development environment. IBM Worklight Studio comes with an embedded test server that simplifies unit testing.
- Mobile browser simulator and app preview
IBM Worklight Server provides an app preview service that enables you to simulate mobile web artifacts in a desktop web browser. App preview also enables the simulation of Worklight client APIs. App preview is available from the Worklight Studio test server console.
In the Worklight Studio development environment, you can preview and test your mobile application using the mobile browser simulator. The simulator contains a frame that emulates a target device. You can switch the frame to emulate different screen resolutions, form factors, and orientations for Android, iPad, iPhone, Blackberry, and other mobile devices. This preview is available only when the com.ibm.imp.worklight.simulation.ui plug-in is enabled. The Apache Cordova API simulation user interface is packaged with the mobile browser simulator. Through the Cordova API, many device-specific features (such as geolocation, compass, battery, and so on) can be simulated.
Unit testing your application with the mobile browser simulator provides the convenience of not requiring the installation of the native SDK from the device vendor. It also has fast application refreshing performance, which makes the repetitive testing more efficient. But the UI simulation does not always exactly match the actual UI appearance on the physical device being emulated, especially with regard to the spacing of text and other elements. Therefore, this type of unit testing is most suitable for early stage UI testing of the overall frame and widget positions. It is also an efficient tool for testing logic flowing in the mobile application.
- Mobile SDK simulator
This type of unit testing involves a native mobile SDK simulator. When a Worklight-generated native project for a mobile platform is started (either through Worklight Studio or the vendor development tool), a native OS window will pop up which runs the simulator with the latest mobile application code. In contrast to the mobile browser simulator, which tries to simulate the characteristics of many devices, a mobile SDK simulator provides a simulated UI that is nearly identical to that of the actual device. However, the application performance, such as the response time to touch, will be slightly different from the real device. This is due to the different computing power between the real device and the development workstation. For the most realistic user experience test, you must test your applications on actual mobile devices.
- Actual device
The ultimate test for mobile applications, this type of test must be performed on the targeted devices to make sure the application UI and performance are consistent across all targeted devices. You must make sure the real device stays on the same wireless network as the development workstation so it can access the embedded Worklight test server within Worklight Studio.
- When an Android device is connected to the computer
via a USB
cable, the Eclipse ADT plug-in automatically recognizes it and attempts to deploy applications onto it.
For an Android device whose driver is not listed (such as Kindle Fire), the .apk file built into the Worklight-generated native Android project can be dropped to the device through the USB connection. You can use the device’s installation utility to install the apk file on the device.
- To deploy an iOS application onto a real iOS device, you must have a provisioning profile, which you receive when you enroll in the Apple iOS Developer Program. Normally, you start with a development provisioning profile that enables Xcode to recognize the connected iOS device through a USB cable and install the application onto it. In a later phase (such as integration test phase or production), you will transition to a distribution provisioning profile that permits you to build, archive, and package the application into an .ipa file with proper signature, which can be deployed to the device through iTunes or the application center.
- When an Android device is connected to the computer via a USB cable, the Eclipse ADT plug-in automatically recognizes it and attempts to deploy applications onto it.
See Resources for more information on the application center included with Worklight.
To test your mobile application with full back end enterprise system integration, the application needs to be installed in an integration or QA environment that is readily available for any authorized testers.
- Prepare the integration environment
Integration and QA testing are typically performed in a remote Worklight server environment. IBM Worklight Server uses a database for storing push notification information, statistics for reporting and analytics, and storing metadata required by the server at run time. Therefore, the preparation of the environment requires both a Worklight server setup and a database setup.
IBM Worklight Server installation is performed through the IBM Installation Manager. (If you are connected to the Internet during the installation, IBM Installation Manager can download any latest fixpacks for you.) The server installation wizard automatically configures an application server and a database, resulting in a fully functional IBM Worklight Server. You must choose which database and application server to use. Database options include:
- IBM DB2 V9.7 or later
- MySQL v5.1 or later
- Oracle v11g or later
- Apache Derby (included in the installation image, for testing purpose only)
Application server options include:
- WebSphere Application Server Liberty Profile V8.5 or later (included in the installation image)
- WebSphere Application Server V7.0 or later
- Apache Tomcat v7 or later
See Worklight Administration Guide for detailed installation instructions.
- Prepare Worklight project for deployment
There are usually some configuration differences between the local development environment and the integration environment. Before building the project for the integration environment, these configurations need to be adjusted to reflect the remote environment settings. Typical settings that need to be adjusted include:
- worklightServerRootURL, which should reflect protocol, host, port, and context setting on the remote Worklight Server.
- Database type, JDBC URL, username and password.
- Any other additional properties which might be different, such as security features.
- Deploy Worklight application and adapter to the integration environment
The generated WAR file can be deployed to the remote integration server by following the standard enterprise application installation procedure on the selected application server. After the WAR file has been deployed, you can open Worklight console in a browser by navigating to http://your-remote-server:server-port/<context-root-name>/console. Within the console, you can upload and deploy the generated .wlapp and .adapter files directly from your Worklight project directory. Your mobile application is now ready to be tested in the integration environment.
- Test in the integration/QA environment
You can use the three types of testing methods and tools described in step 5 to test your mobile application deployed to the integration environment. However, because the mobile browser simulator is not available on the remote Worklight Server, there is no device-specific display when previewing the different environments of the mobile application on the Worklight console; all environments are previewed as a mobile web application. Therefore, this type of testing is not often used in the integration test.
Whether using mobile SDK simulators or actual mobile devices, the authorized testers will need the native packaging file (.apk or .ipa file) to initially install the mobile application. These native packaging files can be distributed manually or through the application center included with the Worklight product.
In the later iterations of testing, if the mobile application does not have native code updates, there is no need to install new .apk or .ipa files on the device. Through the direct update feature of Worklight Server, the new version of the application will be automatically downloaded to the device when the application is resumed or started again on the device.
If there is a need to point to different remote servers, the server root URL can be updated right on the device or simulator:
- Android: the settings can be accessed by pressing the Menu key while the app is running.
- iOS: the settings can be accessed in iOS general settings under the application entry.
For the Worklight server side component, deployment to the production environment will be very similar to the deployment to the integration environment. The manual build process can be replaced by an Ant script for a more streamlined build process. (See Worklight Administration Guide.)
Figure 2 shows a typical topology of a Worklight instance in the production environment.
Figure 2. Worklight instance in production
Notice that several Worklight Servers are set up in a cluster environment, sharing the same database. When a .wlapp or .adapter file is deployed on one of the servers in a cluster, it is automatically synchronized to other servers. This is also true when deleting the application or adapter from a server in the cluster. The .war file, however, is a part of the application server customization; it must, therefore, be deployed manually to each server in the cluster.
While the Worklight mobile application is being deployed to the production environment, the native application package should be assembled and published for distributing to the public. For iOS devices, the publishing process will usually take a longer time because of Apple’s review and approval process for its App Store. Therefore, be sure to start the native package submission with enough lead time.
For Android devices, there is no review and approval process, so publishing is pretty quick.
See Resources for platform publishing guidelines.
The following link provides the guideline for the Apple’s publishing process: https://developer.apple.com/appstore/guidelines.html The following link provides the guideline for the publishing process: http://developer.android.com/distribute/googleplay/publish/preparing.html
Worklight mobile application management consists of two parts:
- The native package managed through the platform app store.
- The application web resources, which are packaged and deployed through the Worklight console.
For the native package update management, each app store has its own guidelines (see Resources). For the Worklight application web resources management, there are quite a few nice Worklight features that enable you to control application versions with users.
- Direct update: Pushing app updates to mobile devices
Using direct update, organizations can update the web content of their deployed HTML5 and hybrid applications directly from the Worklight Server upon application startup. When the application connects to the Worklight Server, it detects the new update automatically and starts downloading the newly deployed resources after receiving confirmation from the user. This option is available for iPhone, iPad, and Android apps.
- Locking an app: Preventing redeployment of web resources for an app
If you want to prevent developers or administrators from mistakenly updating an application, you can lock it in the Worklight console. This option is available for iPhone, iPad, and Android apps.
- Denying access to older app versions
It is sometimes useful to deny a user access to a specific application version due to phase-out policy or security issues present in the older version. On the console, you can deny access to a specific version of the application on a specific mobile operating system and provide a custom message to the user. Along with the message, you can also specify a URL for the new version of the app (usually in the applicable app store). The user receives the message and is forced to close the app, or upgrade to the latest version.
- Displaying a notification message on app startup
Similarly, you can set a notification message that is displayed for the user when the application starts, but does not cause the application to exit. This type of message is useful when you want to notify application users with temporary messages, such as a planned system down time.
- Controlling authenticity testing for an app
When an application first connects to the Worklight Server, the server tests the authenticity of the application. This test helps to protect applications against some malware and repackaging attacks. This option is available for iPhone, iPad, and Android apps. You needs to configure the application to enable authenticity testing.
This article described the fundamental steps involved in developing cross-platform mobile applications using the IBM mobile application development platform. It also described many of the specific challenges that face mobile application developers in general, and introduced various features of the IBM Worklight product that specifically address these challenges. Hopefully, this snapshot of the mobile application development process will not only help you properly plan your mobile strategy, but accelerate it as well.
Worklight product information
Administrative Guide (PDF)
Developer Reference Guide (PDF)
iOS Developer Program
Play Developer Console
Portal for BlackBerry App World
Windows Phone Dev Center
Publishing Checklist for Google Play
IBM developerWorks WebSphere
Get products and technologies
Worklight Developer Edition
Eclipse Indigo Sr2 Packages
Windows Phone SDK 7.1 and 7.1.1 Update
Google USB Driver
Gang Chen is the IBM Software Services for WebSphere World Wide Tech Practice Lead for Mobile and WebSphere Programming Model. Gang has deep and broad experience with architecture, design, development, deployment in the distributed system, SOA, messaging, Cloud Computing, Web 2.0 and Mobile technology. Gang is an IBM Senior Certified IT Specialist. He has been focused on several emerging technologies recently, such as Cloud computing and Mobile application development.
Fang Wang is a Consulting I/T Specialist and Senior Software Engineer in IBM Software Services for WebSphere (ISSW). Fang is an expert in helping enterprise customers with their consumer facing applications and systems, especially those with call center, such as self help Interactive Voice Response (IVR) applications, call routing and Computer Telephony Integration (CTI). Fang is an IBM Certified IT Specialist. She has been focused on emerging technologies recently such as Mobile application development.