You would not typically want to connect directly to a database over
the web on your mobile device, bad idea (for a host of reasons).
Instead you might look at creating an interface for whatever data it
is you want to access and exposing it as a service (SOAP, REST,
anything else). Then you can use a variety of plain Java APIs to get/
put/update/delete/whatever your data.
What you want is more like the Google Data APIs, for your own stuff,
rather than trying to include all sorts of JDBC overhead on a phone
(keep all of that on the server, and use it like you normally would).
On Feb 22, 1:48 pm, dr123 <hserver...@gmail.com> wrote:
Basically I want a central db over the net so as to send and retrieve
data from all the participant's mobile phones every 5 mins or so.
Is this viable? Will the mobiles phones be connected constantly to the
net?
Why would you recommend not using Mysql and say soap is better? Isn't
it the same thing?
Please help cause this is a very big decision for my app and I intend
to submit it for the challenge.
I am not saying don't use MySQL. I am saying don't do JDBC directly
from the phone, regardless of what you use to persist data.
Expose your model layer (your data and logic) as a set of services, on
a server, over HTTP, and connect to THAT from the phone using the
phones HTTP support - no need to have a JDBC driver, or any other such
overhead (or be that tightly coupled to the DB), actually ON the
phone.
You certainly can do a central DB (or other data store) that a group
of phones all running the same app have access to, many Android apps
do this, but they don't connect directly to the DB. Use the Android
DB on the phone for SQLLite to store data local to the phone, if you
already have a server anyway, for your central (not local) DB, then
make a service layer there.
(REST is easier than SOAP, and you can use something altogether
different also, I was just trying to illustrate that concept of using
a service layer.)
On Feb 22, 2:54 pm, dr123 <hserver...@gmail.com> wrote:
> Basically I want a central db over the net so as to send and retrieve
> data from all the participant's mobile phones every 5 mins or so.
> Is this viable? Will the mobiles phones be connected constantly to the
> net?
> Why would you recommend not using Mysql and say soap is better? Isn't
> it the same thing?
> Please help cause this is a very big decision for my app and I intend
> to submit it for the challenge.
> I am not saying don't use MySQL. I am saying don't do JDBC directly
> from the phone, regardless of what you use to persist data.
> Expose your model layer (your data and logic) as a set of services, on
> a server, over HTTP, and connect to THAT from the phone using the
> phones HTTP support - no need to have a JDBC driver, or any other such
> overhead (or be that tightly coupled to the DB), actually ON the
> phone.
> You certainly can do a central DB (or other data store) that a group
> of phones all running the same app have access to, many Android apps
> do this, but they don't connect directly to the DB. Use the Android
> DB on the phone for SQLLite to store data local to the phone, if you
> already have a server anyway, for your central (not local) DB, then
> make a service layer there.
> (REST is easier than SOAP, and you can use something altogether
> different also, I was just trying to illustrate that concept of using
> a service layer.)
> On Feb 22, 2:54 pm, dr123 <hserver...@gmail.com> wrote:
> > Basically I want a central db over the net so as to send and retrieve
> > data from all the participant's mobile phones every 5 mins or so.
> > Is this viable? Will the mobiles phones be connected constantly to the
> > net?
> > Why would you recommend not using Mysql and say soap is better? Isn't
> > it the same thing?
> > Please help cause this is a very big decision for my app and I intend
> > to submit it for the challenge.
