Best way to implement Client <-> Server <-> Database architecture in an Android application?

Question

I am making an Android application. Since it is so simple, I first thought I could simply eliminate the need for Java application on the server which acts as a middleware. I

Answer 1

I know this might be a little late but as I ran into the same problem with a project at school I wanted to share my solution with you as you might profit out of my experiences.

Android is bad for Database-Operations so creating a normal Database-Controller wasn't a thing. Instead I created a Server in Java which handles all Database-related stuff and can also be extended (in my case I used a Feedback-function, too).

The Github-REPO is: https://github.com/Cedced-Bro/Public-Server You can check it out and this is open-source so you can use and contribute to it if you have more ideas to it.

To answer your question more properly: I would strongly suggest to NOT grant all users direct access to your DB as you can run into security issues with malicious users. This was the reason why I created this controller in the first place instead of just a PHP "forwarding"-server.

Answer 2

I tried directly connecting to the database using the JDBC driver for MySQL but my program is crashing so I'm not sure if Android "supports" the JDBC driver for MySQL.

Never never never use a database driver across an Internet connection, for any database, for any platform, for any client, anywhere. That goes double for mobile. Database drivers are designed for LAN operations and are not designed for flaky/intermittent connections or high latency.

Do I connect to a Java server program using sockets (or some other method of communication)?

It doesn't have to be Java. It just has to be something designed for use over the Internet. As Mr. King's comment suggests, Web services have been used for this for much of the past decade. For Android, REST Web services are probably the easiest to consume, since there is no built-in support for SOAP or XML-RPC. But whether the Web service is implemented in Java, or PHP, or Perl, or SNOBOL, is up to you.

Well, OK, perhaps SNOBOL won't be a viable option. :-)