Why is the paradigm of “direct database connection” not welcomed by the Android platform?

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 S

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.