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
A few reasons (but not nearly all reasons):
Not existing: there are no (supported) JDBC drivers on Android.
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.
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.
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.