This isn't a good answer. It's not just a matter of security, but also performance and robustness and flexibility and overly-tight coupling of client and database schema. Such an architecture will lead to a host of problems. For example -- if you make a change, you have to simultaneously update both the database, and all clients that access that database. This is particularly difficult in the case of mobile devices.
There are good reasons that's why that's not where client/server architecture has evolved over the past 15 years or so. However, there is good reason to want JDBC for the situation the original poster (Dan) raised -- access to your local SQLite database. The reason is -- if you have an application with local data persistence, why should you need two different versions, one for Android, and one for everywhere else? SQLite is not a standard. SQL and JDBC are. There are tons of libraries built atop of SQL and JDBC, that you cannot use on Android. You can't use those, either. I don't know how common this is -- but I think it's a legitimate answer to Mark's "Why?". -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
