Why you shouldn’t connect your mobile application to a database
Working at Embarcadero, I frequently hear from mobile developers attempting to connect their mobile application to a database server. By far the most common that I’m asked about is MySQL though the question is asked about other databases too. Doing so is probably a bad idea, and here’s why…
Why?
Well first of all, I should be a little more specific than I was in the title of this post. Providing access to data from your mobile application is not a bad thing at all, and neither is connecting your application to a locally hosted data store. What is a bad idea, and is often not even possible, is connecting your application to a remote database using a persistent session.
When I’m asked about connecting to a database servers, usually, the customer is a developer with some experience in connecting to their chosen database using a client driver library of some kind, and they expect to be able to do the same thing from their mobile application. Well, you can’t (see exceptions below). Your database vendor probably doesn’t even supply a driver for your mobile platform. For example, to the best of my knowledge there is no MySQL client library compiled for ARM processors to run on the Android OS.
There are at least two reasons why your database vendor has not yet provided a client driver:
- Most client libraries were written for desktop or server systems with persistent network connections, and so they create sessions which must persist. When a connection drops, these client libraries go into an error state, which you (the developer) are expected to handle gracefully by attempting to reconnect. All of these database client drivers are different of course, and some may not even have a safe way to handle a connection failure. Your database vendor would be irresponsible to provide drivers which behave this way on platforms with fragile network connectivity, which is typical for mobile platforms.
- Your mobile platform is (probably) not Intel based, but rather ARM based. Your database vendor would have to rebuild their client driver for this new architecture, and for the new operating system, and as I mentioned before, probably using a new architecture.
- There is a better way… (Keep reading).
Exceptions to the rule.
Some database vendors may have provided drivers to connect to remote databases, but as yet I’m not aware of any.
Other exceptions include ODBC connectivity. For example, I’ve heard of developers being able to (or at least trying to) connect to MySQL databases using JDBC when developing applications in Java. This is not actually quite the same as connecting directly using a binary driver, however, it comes close. Despite the fact that it’s possible, I still don’t feel this is a good idea. This kind of connectivity still falls out of the persistent network connection way of thinking.
So what can you do to get remote data to your mobile application?!
The answer here lies in asynchronous service API’s.
The most common solution is to use a RESTful service, usually encoded in JSON.
It is very likely that your mobile application does not need to work with vast amounts of data locally on the mobile device. You may well have Gigabytes or Terabytes of data to work with, but if you plan to perform any kind of logic processing on that data, you’d be making a grave error to do that processing on a device that fits in your pocket. So your mobile application will only ever need the small amount of data which is the result of some query against the more vast remote data store. For these use cases, JSON/REST is sufficient.
Now, you don’t have to use JSON over REST, you could use any other service API protocol. SOAP/XML services could work for example. However, JSON and REST have become something of a de-facto standard for this type of service because, JSON is a light weight encoding, and REST is a simple access protocol.
These services are usually provided though a HTTP server, and this is where we get to the real point of using them. When accessing a HTTP server, you make a request and receive a response. At this point, the connection may end (though it doesn’t have to). HTTP from the very first version was intended to be a request/response protocol, and one which is stateless. Your application doesn’t have to keep the connection open for any longer than is required to grab the piece of data that you want, and, your application need not maintain a session. REST continues this stateless, session-less strategy.
So in order to provide robust data access to your mobile application, you should be using a state-less, session-less strategy such as JSON/REST.
See Also : JSON with RAD Studio, Delphi and C++ Builder
Data aware mobile applications in RAD Studio (Delphi /C++ Builder)
Client Side:
Regardless of the edition you purchase of RAD Studio, Delphi, or C++ Builder these products have you covered for accessing JSON/REST services. Though if you purchase the professional edition of Delphi or C++ Builder, you’ll require the additional Mobile add-on pack to enable development for mobile applications.
The JSON and REST classes which ship with these products, will translate data from a JSON/REST packets into data compatible with FireDAC (a proprietary data abstraction framework), which provides flexible transformation and display of that data. FireDAC is an integral part of all editions of Rad Studio, Delphi, and C++ Builder, however, it is available in two flavors (read below..). For the client mobile application connecting to a JSON/REST service, you’ll only ever need the local database flavor of FireDAC which comes with all three products in any edition. (Because you’re not using FireDAC’s remote database connectivity features directly, but rather, you’re using REST/JSON for remote data access.)
So for the client side of the equation, you’re covered regardless of the edition you chose to purchase, you’ll be able to write applications which consume JSON/REST services, and so long as you have the Mobile Add-On pack (which comes with Enterprise editions or higher, or can be purchased separately for Professional editions), you can create mobile applications which consume JSON/REST services.
Server Side:
The server side becomes a little more complex, as there are several options for providing your JSON/REST services.
You could use a third party means of providing the JSON/REST API, such as a PHP or ASP script for example. This is the technique which requires the fewest purchases from Embarcadero, but also requires the largest amount of work in development. Anything of significant scale will be painful to develop using server-side scripting.
You could use a Professional edition of Rad Studio, Delphi or C++ Builder to create an ISAPI plug-in for Mircosoft’s IIS server, or to create an Apache module for the Apache server (windows only). These two projects get you into a HTTP server with the ability to connect to your database (using FireDAC) and to provide the JSON / REST data required by your mobile application. Doing things this way is still a lot of work however, and you’ll need more in-depth understanding of HTTP and how it works.
You could use DataSnap to provide the JSON/REST service API. DataSnap is a proprietary technology for transporting data over remote connections, and is available in Enterprise editions of Rad Studio, Delphi, and C++ Builder. This technology is far easier to use, allowing you to visually drag-and-drop simple data servers together in the IDE. DataSnap may be used to create plug-ins for existing HTTP servers such as Microsoft IIS, or it may be used to create a stand-alone service application which removes the need for HTTP server software.
For large scale, scalable service API’s, you should consider using Enterprise Mobility Services (EMS) from Embarcadero. EMS is a turnkey server solution for hosting API’s, which comes with user management and authentication, API level analytics, and even push notification capabilities right out of the box. This technology requires separate licensing from Rad Studio and is licensed on a per-user, per-annum basis.
Do I need the FireDAC add-on?
All Rad Studio, Delphi and C++ Builder editions ship with FireDAC, a suite of classes for abstracting data and connecting to databases. However, there are two flavors of FireDAC…
The standard flavor of FireDAC is included with all editions of Rad Studio, Delphi and C++ Builder, and has access to local databases. So, if you’re using ISAPI’s, Apache Modules, DataSnap or EMS to host your service, and that service is on the very same server as your database, you can use FireDAC without additional purchasing, regardless of the edition you’ve chosen, though if you’re using DataSnap or EMS you’ll already have purchased an Enterprise or higher edition of these products.
If however, your service is hosted on one server, and your database on another, you’ll need the “Remote database” flavor of FireDAC. This flavor comes with the Enterprise or higher editions of Rad Studio, Delphi, or C++ Builder, and is available as an additional purchase for Professional editions.
Another Option – BaaS
Before I leave you with a conclusion to this post, I’d like to make mention of one other option available to you. You don’t have to host your database yourself! BaaS providers such as Kinvey, Parse, Amazon and others have cloud storage options for you to take advantage of, for a fee. If you elect to use one of these services to host your data, you can relieve yourself of writing the server side API at all, because they provide JSON/REST API’s for accessing data already.
All editions of Rad Studio, Delphi, and C++ Builder come with classes for accessing BaaS services, and make adding data to your mobile applications trivial! There are of course pro’s and con’s to using a BaaS provider, but one of the nicest pro’s is that you no longer have to service hardware yourself, and can make fiscal savings by not having to hire I.T. staff for the purpose.
See Also: BaaS Kinvey with Rad Studio
Conclusion.
Simply connecting your application to a database server is a little less simple in the world of mobile applications. Embarcadero provide a strong suite of tools to help you solve this problem for your application. Talk to your Embarcadero customer representative for more information!
http://chapmanworld.com/2015/07/02/why-you-shouldnt-connect-your-mobile-application-to-a-database/
