Why is the paradigm of “direct database connection

Question

When I say "direct database connection", I meant to use a JDBC-alike driver to call and run a remote database query within the context of an activity, just like using an SQLite database to store the local parameters.

Until I realized that I could barely find any tutorials or documents on the Internet regarding this way of database connection, I thought, regardless of the unstable Wi-Fi/3G network bore by most if not all Android devices, to connect to a database should be done like so.

Even in Android SDK, only local database access (a.k.a android.database.sqlite) is supported intrinsically. And it's stated in the description of java.sql API that you must provide your own JDBC driver in order to use this API.

Then I started to realize if my intention of directly connecting a database is incorrectly in the first place in the realm of Android.

I have read many books, wikis, and forums, including numerous answers provided on Stack Overflow. It appears to me that many people are concentrating on getting something done, and discussions used to start with "How can I design a RESTful web service for my Android device?". However, I need a thorough understanding! And I also need authoritative citations from the original Android developers.

Answer 1

I thought, regardless of the unstable Wi-Fi/3G network bore by most if not all android devices, to connect to a database should be done like so.

You are welcome to your opinion. I vehemently disagree with you. JDBC and similar protocols are designed for reliable, low-latency LANs, not unreliable, high-latency mobile networks. Moreover, you would need your database to be visible on the public Internet, meaning that it will be subject to hackers.

Answer 2

A few reasons (but not nearly all reasons):

1. Not existing: there are no (supported) JDBC drivers on Android.

2. Authentication: you want users on a public network to be authenticated:

   A. Each user must have their own credentials (in some form) when talking to your servers. Having one username/pass baked into your app is asking for trouble.

   B. You don't want your database to provide authentication. For this you need a separate authentication layer.

3. Standard protocol: if you want to make sure your app runs on all networks (especially on locked-down corporate networks) you need to use HTTP/HTTPS. It's the only protocol that works (almost) everywhere.

4. Business-logic separation: If you support different device platforms (Android, iPhone, etc..) then it's wise to have all business logic on the server. Instead of calling JDBC and then performing business logic on device, you should do this on the server. That way you will conform to DRY (don't repeat yourself), and also it'll be easier to unit test.