Does Android Support Jdbc

Does Android Support JDBC

You cannot import a JAR implementing java.* classes easily. And, JDBC would need to be ported to Android, since it probably relies upon classes in JavaSE that Android lacks. And, you would need to write your own JDBC driver for SQLite anyway, wrapping the API Android already supplies, since I suspect the existing JDBC driver uses JNI. And, when all of that is done, you will have an application that adds a lot of bloat, making it less likely people will download and retain your application.

In short, I wouldn't go this route.

Android : Is JDBC supported in Android devices?

Yes. You must remember to put your JDBC connection code in an AsyncTask,
otherwise you will BURN BURN BURN!

JDBC vs Web Service for Android

You think it's simpler and faster to do it with JDBC because you aren't considering the real world operating environment of phones and portable devices. They often have flakey connectivity through buggy traffic rewriting proxies and insane firewalls. They're typically using a network transport layer that has high and variable packet loss rates and latencies that vary over many orders of magnitude in short spans of time. TCP really isn't great in this environment and particularly struggles with long lived connections.

The key benefit of a web service is that it:

• Has short-lived connections with minimal state, so it's easy to get back to where you were when the device switches WiFi networks, to/from cellular, loses connectivity briefly, etc; and

• Can pass through all but the most awful and draconian web proxies

You will routinely encounter problems with a direct JDBC connection. One challenge is reliably timing out dead connections, re-establishing sessions and releasing locks held by the old session (as the server may not decide it's dead at the same time the client does). Another is packet loss causing very slow operations, long-running database transactions, and consequent problems with lock durations and transactional cleanup tasks. You'll also meet every variety of insane and broken proxy and firewall under the sun - proxies that support CONNECT but then turn out to assume all traffic is HTTPs and mangle it if it isn't; firewalls with buggy stateful connection tracking that cause connections to fail or go to a half-open zombie state; every NAT problem you can imagine; carriers "helpfully" generating TCP ACKs to reduce latency, never mind the problems that causes with packet loss discovery and window sizing; wacky port blocking; etc.

Because everyone uses HTTP, you can expect that to work - at least, vastly more often than anything else does. This is particularly true now that common websites use REST+JSON communication style even in mobile web apps.

You can also write your web service calls to be idempotent using unique request tokens. That lets your app re-send modification requests without fear that it'll perform an action against the database twice. See idempotence and definining idempotence.

Seriously, JDBC from a mobile device might look like a good idea now - but the only way I'd even consider it would be if the mobile devices were all on a single high-reliably WiFi network under my direct control. Even then I'd avoid it for reasons of database performance management if I possibly could. You can use something like PgBouncer to pool connections among many devices at the server side so connection pooling isn't a big problem, but cleanup of lost and abandoned connections is, as is the tcp keepalive traffic required to make it work and the long stalled transactions from abandoned connections.

Is it safe and secure to use JDBC in android?

Hardcoding credentials into your app is pretty much a bad idea, because if someone who has some knowledge about this subject, actually will try cracking you app, and if your app manages some financial sensitive data, they actually will try triplify efforts.

As far as security goes, in this kind of architecture it seems that a Asymmetric encryption algorithm is what best fits this kind of transactions, as you can hardcode/download each time you need the public key for encrypting messages and they'll be only decrypted by the server side using the private key.

I'd recommend using a web-service with TLS encryption, it won't be 100% secure but at least it will harden things to crackers enough.

• How to securely share key between two remote devices?
• How dangerous might be publishing a public key?

---

Related Topics