WHITE PAPER

Best Practices When Developing a Mobile Application for Resale

www.sybase.com/sqlanywhere TABLE OF CONTENTS 1 Introduction 1 Ten Best Practices 1 Provide Current and Required Functionality 3 Add Value to Your Customer 5 Provide Robust End-To-End Encryption 5 Provide Access to Data at all Times 6 Integrate With Existing Systems 6 Support Multiple Mobile Devices 7 Keep Development Costs Low 8 Keep Maintenance Costs Low 8 Provide Quick and Easy Deployment 9 Plan for the Future 9 Conclusion INTRODUCTION Nowadays, it’s not uncommon to see users wherever you go. These mobile devices, such as the RIM® BlackBerry® and Apple® iPhone®, enable customers to do much more than just making phone calls. Catching up on email and browsing Internet sites are two ordinary tasks associated with . Additional applications are made available through popular third-party digital marketplaces and they provide users with richer and more sophisticated applications that they can access while on the go. Application developers who are looking to move into the mobile space are therefore presented with a unique opportunity to tap into this market.

Whether you are an established independent software vendor (ISV) or a new player looking to resell mobile applications, there are guidelines that you must adhere to ensure the success of your solution. This article describes ten best practices that developers can follow when implementing a mobile database application for resale as part of an existing software package, or for online distribution.

To illustrate the concepts presented in this article, we use Sybase’s SQL Anywhere® UltraLite® database because of its extensive feature set and ability to target multiple smartphone platforms, including Windows Mobile, RIM BlackBerry, Apple iPhone, and Android. However, you may choose a different mobile database solution if it supports your platform of choice.

TEN BEST PRACTICES The following ten best practices are discussed in this article:

1. Provide current and required functionality 2. Add value to your customer 3. Provide robust end-to-end encryption 4. Provide access to data at all times 5. Integrate with existing systems 6. Support multiple devices 7. Keep development costs low 8. Keep maintenance costs low 9. Provide quick and easy deployment 10. Plan for the future

Provide Current and Required Functionality It is extremely important to understand the functionality that made a particular solution successful in the first place because it’s that same functionality that you must include in your mobile solution. Existing ISVs already enjoy success with their current desktop applications and so should be familiar with what they would need in a mobile version of their application. ISVs developing new applications can identify specific needs of mobile users and build application requirements based on those needs. Some examples of database applications that can be extended to smartphones include customer relationship management (CRM) and sales force automation (SFA).

1 Consider the simple sales force automation application in Figure 1. It allows the sales representative “Alan Able” to see his orders and a list of his top-selling products and his top customers. This application runs on his desktop computer.

What is most important about this application is the ability to see the customer orders so that the sales representative can approve them. That is the functionality that must be made available in the mobile application. The list of top products and customers, while useful, are not mission-critical components of the solution and so should be optional in the mobile application. Assuming that all sales representatives are equipped with a BlackBerry device, the mobile version of this solution should allow them to see their orders, as shown in Figure 2.

Figure 2: BlackBerry version showing customer orders.

2 In this example, the desktop application is written in C# and uses SQL Anywhere as the backend or corporate database that we will synchronize information to. The BlackBerry application is written in Java and uses UltraLite technology (database designed for smartphones included with SQL Anywhere) to store all information right on the device. Since both applications are alike, their implementation is straight-forward and use similar SQL statements to display the data, as shown in Code Listings 1 and 2.

SAConnection conn; conn = new SAConnection(“dsn=SA12 CustDB;uid=dba;pwd=sql”); conn.Open();

string sql = @”SELECT o.order_id, c.cust_name, p.prod_name, o.quant FROM ULOrder o, ULCustomer c, ULProduct p, ULEmployee e WHERE o.cust_id = c.cust_id AND o.prod_id = p.prod_id AND o.emp_id = e.emp_id AND e.emp_name = ‘Alan Able’ ORDER BY order_id”; DataSet ds = new DataSet(); SADataAdapter da = new SADataAdapter(sql, conn); da.Fill(ds, “Results”); dataGridView1.DataSource = ds.Tables[“Results”];

Code Listing 1: C# code for Windows desktop SFA application to display customer orders.

Connection _conn; ConfigPersistent _config; PreparedStatement _ps_order; ResultSet _rs_order;

_config = createConfig(“custdb.ulj”); DatabaseManager.connect( _config ); _ps_order = _conn.prepareStatement ( “SELECT o.order_id, c.cust_name, p.prod_name, o.quant, p.price, “ + “o.disc, o.status, o.notes “ + “FROM ULOrder o “ + “ JOIN ULProduct p ON o.prod_id = p.prod_id “ + “ JOIN ULCustomer c ON o.cust_id = c.cust_id “ + “ORDER BY o.order_id” ); _rs_order = _ps_order.executeQuery(); boolean valid = _rs_order.next();

Code Listing 2: Java code for BlackBerry SFA application to display customer orders.

Add Value to Your Customer Now that you’ve defined the required functionally for your mobile application, you need to determine how your solution is adding value to your customers. A solution that only displays information is not very useful, but one that allows the mobile worker to execute business processes is much more powerful and appealing. Mobile allow you to take full advantage of features such as indexes, transaction processing, referential integrity, multi-table joins, row-level locking, SQL functions, BLOB support, and location-based data.

3 Continuing with our SFA mobile solution, in addition to displaying customer’s orders, it allows approving or denying of orders, as well as adding and deleting orders (see Figure 3). The sales representative no longer needs to carry a laptop computer to manage his or her accounts, but can do so using his or her smartphone.

Figure 3: Account management operations from BlackBerry SFA application.

Just like retrieving the list of orders, the Java code required to add or delete orders comprises of simple JDBC calls, as shown in Code Listing 3.

String sql_stmt = “INSERT INTO ULOrder( order_id, cust_id, prod_id, emp_id,” + “ disc, quant, notes, status )” + “ VALUES( ?, ?, ?, ?, ?, ?, ‘’, ‘’ )” PreparedStatement ps = _conn.prepareStatement( sql_stmt ); ps.setInt(1, order_id); ps.setInt(2, cust_id); ps.setint(3, prod_id); ps.setInt(4, emp_id); ps.setInt(5, discount); ps.setInt(6, quantity); try { ps.execute(); if( do_commit ) { _conn.commit(); } } finally { ps.close(); }

Code Listing 3: Java code for BlackBerry SFA application to insert new customer orders.

4 Provide Robust End-To-End Encryption Security is of paramount importance in any enterprise solution, particularly when it comes to mobile database applications. As a software vendor, you must ensure that your customer’s data is safeguarded at all times against device theft or lost, and against data interception that may occur when the application is communicating using the Internet. The best method to protect your customer’s information is to provide them with end-to-end encryption, meaning that your solution encrypts the data at the point of origin (mobile device) and only decrypts it at the final destination (headquarters).

Make sure to encrypt the database residing in the smartphone. The encryption method can range from simple obfuscation to strong 128 or 256-bit encryption. Ensure that you use the correct algorithm depending on who your end customer is. The Advanced Encryption Standard (AES) algorithm is appropriate for mobile business applications, while the Federal Information Processing Standard (FIPS) Publication 140-2 is suitable for government mobile solutions. An encrypted database will give your users piece of mind in case their mobile device is lost or stolen.

It is also essential to encrypt the communication stream between the mobile database and the customer’s corporate network. Since the data transmission is likely to occur over the Internet, there’s a risk that your customer’s information may be intercepted along the way. To mitigate this risk, employ transport-layer security in your mobile database application. Transport-layer security employs digital certificates to establish and maintain a secure connection to your corporate server, and strongly encrypts the communication protocol using public-key cryptography. Just like database encryption, ensure that you are using the proper algorithm depending on who your ultimate customer is.

Provide Access to Data at all Times Mobile applications allow customers to be productive when they are away from the office. A true mobile solution must be able to function properly whether or not the device is connected to the network. That is the main reason behind developing a mobile application that includes a database capable of running on smartphones. It enables your mobile customers to continue working without having to worry about network connectivity issues. Once the mobile worker is finished using the application, he or she can synchronize the information stored in the smartphone database with the database residing at corporate headquarters. Figure 4 illustrates this architecture.

Figure 4: Mobile database application architecture

As you can see on the left side, the enterprise database is inside the corporate network. This information is synchronized with databases residing in each of the mobile devices on the right side. By having access to a local data store, the mobile workers will maintain their productivity in both online and offline environments.

5 Integrate With Existing Systems Your mobile solution needs to integrate with your customer’s existing systems. It’s impractical and unnecessary to except clients to change their infrastructure to accommodate your application. In fact, advertising your product as one that can be incorporated with current corporate architectures will garner value in the eyes of your prospects and customers.

When it comes to backend integration, your mobile database application must enable data synchronization to the leading relational database products in the market, including Oracle, SQL Server, DB2, and Sybase. Carefully design your mobile application to support these different backends, keeping in mind that each vendor typically uses proprietary SQL to interface with their databases. For instance, Oracle uses PL-SQL, while SQL Server uses T-SQL. Make certain that your mobile database solution supports these languages.

Companies typically have existing network infrastructures that can comprise of intranets, firewalls, customer/ partner portals, etc. Your mobile solutions must be able to function properly over the various network configurations already in place. Communication through TCP/IP, HTTP, HTTPS, VPN, and firewalls are basic requirements that must always be included in a mobile database application. To ensure wide adoption of your mobile solution, it must support systems already in place so that integration is as painless as possible.

Support Multiple Mobile Devices This guideline is related to the previous one, in that your mobile database application must operate in existing device deployments, as well as planned installations for the future. A few years ago, Symbian OS, Microsoft Windows Mobile and RIM BlackBerry were the smartphones or choice among business users. Recently, Apple iPhone and Google Android have surged in prevalence. With all these different mobile platforms available, customers have a lot of choices when it comes to choosing a mobile device. As a mobile database application provider, your solution needs to run in the most popular mobile devices, otherwise you risk losing business to other vendors who recognize that customer need.

Supporting multiple mobile devices is challenging because you need to maintain separate code lines for the different platforms. Fortunately, by implementing your solution so that the database and presentation layers are separated, you can re-use the data access layer for each different mobile device. You can then concentrate on adding functionality specific to the target device according to its development capabilities. The end result will be a complete mobile solution capable of running on different smartphones. Figure 5 shows our mobile SFA application running on different devices. The data access code is very similar in each device, while the presentation code is very different due to the various development environments for each platform. All the applications use the UltraLite mobile database included with SQL Anywhere.

Figure 5: BlackBerry, Windows Mobile, and iPhone versions of the mobile SFA application.

6 Keep Development Costs Low As a software vendor, you want to keep your development costs low to increase profits. For that reason, it’s imperative that your programmers take full advantage of industry standard development environments, such as Microsoft Visual Studio (.NET), Eclipse (Java), and Xcode (Objective-C). In addition, you also want to leverage your team’s knowledge and experience in those environment and programming languages. A programmer already familiar with Eclipse and Java is well-positioned to start developing a BlackBerry or Android application. The same applies for .NET (Windows Mobile) and Objective-C (iPhone/iPad).

Since the database access layer consists of SQL commands, you can re-use most of that code in your mobile applications, significantly reducing your development efforts. In Code Listings 1 and 2, we saw how similar the code was to retrieve information from the database, despite using different programming languages. In Code Listings 4 and 5, we continue to see the similarities in the data access code, even though one application is written for the iPhone and the other for Windows Mobile.

static const TCHAR * const GetOrderSQL = TEXT(“ SELECT order_id, disc, quant, notes, status,”) TEXT(“ c.cust_id, cust_name, p.prod_id, prod_name, price”) TEXT(“ FROM ULOrder o, ULCustomer c, ULProduct p”) TEXT(“ WHERE o.cust_id = c.cust_id AND o.prod_id = p.prod_id”) TEXT(“ ORDER BY order_id”);

// Connect to the database. m_Conn = ULDatabaseManager::OpenConnection( connectionParms ); if( m_Conn == NULL ) { // unable to start/connect to database ULDatabaseManager::Fini(); return( false ); }

ULPreparedStatement * prepStmt; prepStmt = m_Conn->PrepareStatement( GetOrderSQL ); if( prepStmt != NULL ) { m_GetOrder = prepStmt->ExecuteQuery(); } if( m_GetOrder == NULL ) { // unable to open cursor ULDatabaseManager::Fini(); return( false ); }

Code Listing 4: Objective-C code for iPhone SFA application to display customer orders.

7 openParms = New ULConnectionParms openParms.ConnectionName = “custdb” openParms.DatabaseOnDevice = ceLocation + “custdb.udb”

_conn = New ULConnection(openParms.ToString()) _conn.Open()

‘ Open GetOrder result set cmd = New ULCommand( _ “SELECT order_id, disc, quant, notes, status, c.cust_id, “ + _ “ cust_name, p.prod_id, prod_name, price “ + _ “ FROM ULOrder o, ULCustomer c, ULProduct p “ + _ “ WHERE o.cust_id = c.cust_id AND o.prod_id = p.prod_id “ + _ “ ORDER BY order_id”, _conn) _cursor = cmd.ExecuteReader()

Code Listing 5: Visual Basic .NET code for Windows Mobile SFA application to display customer orders.

Keep Maintenance Costs Low All software products require maintenance, from installation to ongoing support. As a mobile solution provider, your maintenance costs should only encompass the features that you’ve implemented in your application. Other components, such as the mobile database, must be self-managing so that your efforts are focused on troubleshooting issues specifically in your code. Your customers should not be burdened with performing administrative tasks to the mobile database; in fact, they should successfully operate your application whether or not they are aware that it uses a database.

When selecting a mobile database for your application, ensure that you can take advantage of fundamental self- management functionality, such as automatic file growth, automatic recovery from failures, event scheduling and handling, and built-in data synchronization including conflict detection and resolution. By choosing a self-managing mobile database, you will be minimizing your maintenance costs as there is no need to handle any database administration operations after your solution is deployed.

Provide Quick and Easy Deployment Your customers are always looking to lower their total cost of ownership once they roll out your mobile application. Installation costs are part of the overall expenditure of the solution and so you must provide a software package that can be deployed quickly and effortlessly. For that reason, any modules included in your application, such as the mobile database, must offer deployment capabilities that allow you to install those parts without the need of utilizing complex setup procedures. Software applications that are difficult to install often lack adoption by potential and existing customers. It would be unfortunate to develop a sleek mobile application that is not adopted due to a complicated installation process.

Look for a mobile database that can be installed alongside your application so that your customers only see one setup program. An ideal solution is a database that can run in the same address space as your application (i.e. in-process), thus potentially reducing the number of files in your solution to just one: the mobile application itself. Since memory capacity on mobile devices is limited, make sure to embed a mobile database that can run in low memory devices, yet can still deliver the rich feature set required by your solution. A smaller installation packages is also beneficial in case you wish to distribute your mobile application through the web or via online marketplaces, such as the Apple App Store or RIM’s App World.

8 Plan for the Future Most software applications require some level of customization, depending on who the ultimate customer is. It’s very likely that one of your customers will require the same solution as another, but with a few tweaks here and there. It’s crucial to design your mobile solution with flexibility and extensibility in mind. All components in your application, whether they are yours or from a 3rd party, need to be configurable so that you are not spending a lot of effort trying to make your solution work for another client.

Customer requirements change during the lifecycle of your product, particularly for mobile application deployments due to the frequency of newer devices that become available every few months. Try to address the future needs of your customers by (1) providing them with a solution that can work with their current hardware, and (2) planning a mobile application that can be easily extended to run on newer devices. In order to accomplish this, your mobile database must have a successful track record of supporting state of the art technology. Not only will this increase your customer’s satisfaction level, but it will also enhance your credibility as a mobile solution provider.

CONCLUSION We’ve reviewed a list of ten best practices you can follow when implementing a mobile database application. These guidelines should be useful whether you are a seasoned ISV looking to extend your offering to smartphones, or someone new to the mobile application market. Choosing the right database technology is vital to the success of your mobile solution because it can significantly reduce your development and maintenance costs. You can greatly improve adoption by prospective and current customers by creating a mobile database that is valuable, feature-rich, secure, and easy to deploy and maintain.

9 Sybase, Inc. Worldwide Headquarters Copyright © 2010 Sybase, an SAP Company. All rights reserved. Unpublished rights reserved under U.S. copyright laws. One Sybase Drive Sybase, the Sybase logo, SQL Anywhere and UltraLite are trademarks of Sybase, Inc. or its subsidiaries. ® indicates Dublin, CA 94568-7902 registration in the United States of America. SAP and the SAP logo are the trademarks or registered trademarks of SAP U.S.A AG in Germany and in several other countries. All other trademarks are the property of their respective owners. 11/10 1 800 8 sybase Apple and iPhone are registered trademarks of Apple Inc.

BlackBerry®, RIM®, Research In Motion®, SureType®, SurePress®, BBM® and related trademarks, names and logos are the property of Research In Motion Limited and are registered and/or used in the U.S. and countries around the world. Used www.sybase.com/sqlanywhere under license from Research In Motion Limited.