Remote data access on mobile devices presents developers and users with a number of unique challenges not found in server or desktop environments. Unreliable network connections, battery life optimization, and security implications are the major factors that need to be considered by developers and end users. This post gives a brief overview of these issues and offers some best practices.
The ODBC and JDBC data-access standards were designed to work on stable network connections with high bandwidth. The same levels of stability and bandwidth cannot be offered consistently on mobile devices. Mobile devices can have multiple network interfaces (Wi-Fi, GPRS, UMTS, etc.), but all can be prone to intermittent disconnection due to poor reception in the area or even weather conditions. Your network may also switch between these interfaces at any time. For example when you’re getting far away from a Wi-Fi router, your phone may switch to a general packet radio service such as 2G or 3G. These scenarios may break your ODBC or JDBC connection (and even trigger data charges from your service provider).
If your application uses a lot of network resources, make sure to give the user control over how those resources are used. For example, your user may want to limit network transactions to Wi-Fi, or disable data usage while roaming. Wi-Fi is generally faster and better than packet-radio data services for heavier transactions. Mobile data is limited for most users and can be quite expensive, especially if the user incurs overage charges.
It’s generally good practice to check your network connection before attempting to execute network transactions. Checking network connections first lets your application respond to failures more gracefully. You will also want to detect connection changes, especially when using an open database connectivity API. On Android this can be done using a ConnectivityManager and BroadcastReceiver, on iOS by using Reachability API and Notifications, and on Windows Phone by checking a NetworkInterfaceList and registering for NetworkAvailabilityChanged events. By detecting network changes, you can deal with the interruption on your database connection accordingly by saving your state, reopening the connection when an interface becomes connected again, and re-executing any incomplete transactions.
You also have to take battery life into account when executing network transactions on mobile devices. You don’t normally have to worry about it with desktop applications, but with mobile devices, it’s essential that you choose the right radio to better manage device battery life. The order of battery usages, from highest to lowest is: LTE -> 3G -> 2G -> Wi-Fi. The order of bandwidth from highest to lowest is generally Wi-Fi -> LTE -> 3G -> 2G. As you can see, if Wi-Fi is available, you should always opt to use it, since it’s typically more stable and faster-performing. Out of all the radios, it uses the least amount of battery by far and generally offers higher bandwidth. If Wi-Fi is not available, it doesn’t mean that you necessarily have to use 2G just because it uses less battery. Even though it does use less battery, LTE offers higher bandwidth which means your transactions will be over more quickly. Testing for your particular data access patterns will help you select appropriate interface which balances users experience and batter usage.
Security is paramount if you want to use an open database connectivity API in your mobile application. Your database security could be compromised because your credentials will have to be stored on the client. Proper user of encryption and data protection features offered by the mobile device OS will make it harder for an attacker to access credentials stored on devices, but under certain conditions they still could be exposed. Creating restricted database logins and/or requiring end-user authentication on every connection could also be used to mitigate the risk.
Web Services and REST API
If you want to access a remote database, the best practice for mobile devices is to create a webservice with REST API to your database. REST is a stateless protocol which doesn’t suffer from connection loss in the same way ODBC and JDBC do. Web service behind REST interface could also be used to offload some business logic from the client which turn will improve battery life, security and portability.
The diagram below shows a simple example of how you can use a web service to maintain several ODBC or JDBC connections open while providing stateless access using REST API.
When using REST API, client treats SQL queries as the Unique Resource Identifiers (URIs) and applies one of the HTTP actions to them (POST, UPDATE, DELETE, GET). If you want to execute transactions, you can send all queries in a single HTTP request to the web server. The web server will then execute those queries against an ODBC or JDBC connection and can return data if necessary as a JSON string or any other method of serialization specified by client in “Accept” header.
Simplify Your Mobile Data Driver Development
If you are developing or porting an ODBC or JDBC driver for mobile platforms, take advantage of SimbaEngine SDK to significantly reduce development cost and take care of the issues discussed above. Upcoming version of SimbaEngine SDK will support mobile driver development and provide sample drivers.
SimbaEngine SDK features support for ODBC 3.8 and JDBC 4.1. It also delivers JDBC 4.0, ADO.NET, native Unicode capability, and the industry’s widest support for 32-bit and 64-bit platforms. SimbaEngine has been proven by delivering a large number of ODBC and JDBC drivers both by Simba Technologies and a number of SDK customers.
Try a version of SimbaEngine SDK. If you have any questions during the installation or evaluation process, please contact us for free Engineer level support at firstname.lastname@example.org.