i was trying to build an app which takes the data from server database and use it in android app ( in may case for reading the gprs coordinates available on database).
after a lot of search, i came across RESTfull services for implementing this. but there is a simpler way also, that is accessing the server database directly from android app by using a driver (jtds) and running mysql on server side.
i am actually confused which one to use. Why restful service which is highly platform independent and have a wide range or directly accessing the mysql database from server. which is most extensively used and why? giving below examples of both scenarios.
through restful service - http://avilyne.com/?p=105 and directly by accessing sql server database- http://amitku.wordpress.com/2011/08/03/how-to-connect-and-access-sql-database-server-from-android-app/
please let me know which is better and mostly used and why?
I would strongly encourage using the REST approach, and although there are many reasons, two or three come immediately to mind:
1.) Security. By using a REST approach, any data on the server side can only be accessed by server-side code, which can provide a protective layer between the data and the outside world.
2.) Scalability. A direct connection, such as the example at your link, hooks into a particular instance of a database. If that database already has a large number of connections, there will be performance issues or worse.
3.) Server side flexibility. If the underlying database structure or technology needs to change, a REST approach will allow for that. All the client side cares about is posting or requesting to a server that will respond via REST protocol.
I would think that a REST approach is much more widely used than a direct client-server approach.
Related
I am developing an android application. I want to update the local SQLite database with MySQL database on server. I am not able to figure out that what is the most appropriate and standardized way to do so?
Create a webservice (REST is probably best) and serialize your SQLite/MySQL data and PUT/POST/GET it to/from your web service. This will give you a nice layer of abstraction in case you decide to switch from MySQL to something else server side.
You may want to take a look at fyrecloud.com/amsler This is source code for a demonstration Android application that implements MySQL replication between a MySQL server and the SQLite db on an Android device.
Amsler rests on two pillars:
It communicates with the MySQL server using the MySQL Client/Server protocol in order to connect to the server for authentication and for receiving replication events as they occur.
It uses the Antlr lex and parse software in order to lex and parse incoming replication events and then to translate the MySQL commands into equivalent SQLite commands.
This is great for one-way replication. You can simulate two-way replication by modifying the MySQL server indirectly via RESTful type methods and then watching while MySQL sends a new replication event back.
Accessing a server via REST is easy enough. However, modifying an existing MySQL installation in order to support serialization presents too many headaches to enumerate here. Amsler takes advantage of pre-existing replication services. REST also depends upon some polling strategy in order to keep the local device reasonably up-to-date. Again, many problems with this approach. Amsler maintains a TCP/IP connection to the server which enables server-push notification of updates.
The most difficult part of Amsler is in figuring out the lexing/parsing. The Syntax between MySQL, SQLite, and the various versions of the same have many subtle differences. So many differences that it's impractical to provide a shrink-wrap translator and instead you must resort to modifying the grammar yourself.
Nevertheless, good, bad, or ugly, here it is. Take a look and maybe the glove fits.
This is probably going to be helpful: sync databases Mysql SQLite
The real answer is that there is no standard or built in magic way to just copy a MySQL database that lives on a server somewhere to a device. You will have to implement either a webservice or somehow convert the MySQL db on the server to the android sqlite implementation and download that file into your app's data directory (not a route I'd recommend taking).
Late to the party, but http://www.symmetricds.org/ is a good solution.
Java, runs on Android too.
LGPL.
Can handle 10,000's of clients.
There is no standard way. Depending on your needs you can e.g. use webservices in REST or SOAP protocols or more binary data exchange.
I have read countless posts regarding the use of JDBC with Android. Everybody suggests to take the path of using PHP scripts and using HTTP clients within the Android code.
It would be great to just get a clear indication as to why the JDBC is not advised.
JDBC access directly from a web client, be it browser or web phone, implies that the database port is exposed on the public internet. That's not a safe place for any data to be.
I think a better approach is to put one or more servlets between clients and the database. Let the servlet(s) handle security, validation, binding, deciding which services to invoke to fulfill the use case, marshaling the response, and routing to the next page depending on the outcome.
This design lets you put the intermediate layer on the internet and keep your data safe behind a firewall.
It's called Model-2 MVC. It's been the standard idiom for Java web development for more than ten years.
You'll get a lot more use out of your code if you have a clean separation of the presentation of data from how it's produced. UIs come and go, but services and data linger. Think in terms of services first and you'll do better.
I would ask a semi-theorical question about web services and client-server architecture.
I have a server with a database with about 50 tables. This server holds even one table which contains information about users associated with the clients.
Each client has associations with a subset of all data in db.
The defined architecture implies that each client (running on Android app) calling ,with a predefined frequency, a certain number of Web Services, fill the local database, creating a copy of all the tables residing on server sb, containing the only information related to the requesting client.
Furthermore, the data in db server side can change, so frequent synchronization is required.
Considering that the client application can be imaginated as a shop online application, so should be possible browsing through providers, articles, make a order,remove orders etc.
So, when I talk about fill the local database I mean store providers, articles, ...that is, all information realated to the requesting client.
Can make sense fill the local database with this information?
I think that is more reasonable call a web service only exactly when the information is required, and not store information in local db.
So, synchronization is no more required.
Tall me what you think about ? thank you.
I know NOTHING about Android development, but have tons of experience with using web services and SOA.
In my experience, especially when the client device has limited storage and processing power, all the business logic and data logic should be in the web services, and the client app used only for display and calling those services. How you implement that is something that we can't answer for you. It's different on every project.
The only exception is when you absolutely have to have the app running while not connected. In that case, be sure you know your specific requirements, and be very dilligent to only persist at the client the data that you absoutely need, and only provide the business logic that you absolutely need while disconnected.
(This helps to keep security simpler as well - lost or stolen devices are one of the highest sources of data breaches, so the less potentially sensitive data on the device the better.)
I don't know if that's helpful, but I throught I'd throw it out there.
If your application is going to work only online, then YES. You don't need to worry to store the data into the database and retrieve it later. If your requirement that needs to support both online and offline, then you have to go withe the database.
You can run a service or Async task or Handlers to invoke the Webservice from the Android Application, that way your UI thread won't be blocked.
If your response is too big, then probably you have to think about middle tier, that way you can convert the SOAP response to JSON that would be easier for the device to process the response and network transmission is faster.
I believe based on your requirements, its good enough to support only online mode... Because the data might vary if the user is not using the app for two days and logs in back and show offline data that might be irrelevant
The current solution that I have to adopt uses JDBC and stores the user/password of the database inside the android app. That's as far as I'm concerned not a good solution. I would like to implement a mapping layer on the webserver in the middle.
Is there any best practice or recommended strategy for this? Should I use SOAP or JSON or something completely different (because they're well implemented and/or easy to use in Java)?
Are there any mapping tools for postgresql <-> SOAP/JSON/whatever in PHP or will I need to write these scripts by myself?
Any pointers will be greatly appreciated.
Quick version:
Use a web service midlayer running on a public host you control (possibly but not necessarily the database host). Expose public web service methods to do the limited work you want to permit and nothing else.
Related questions:
Driver JDBC PostgreSQL with Android
How to connect to a PostgreSQL server via JDBC in Android?
Implementation options
Personally I'd use a Java application server like Apache Tomcat or JBoss AS 7 and I'd write my web service methods using JAX-RS to produce a nice REST-style API for my app to use. That's what I'm familiar with and it works well, but you have lots of options including implementations of:
REST-like APIs (Java's JAX-RS impls Jersey and RESTEasy, various other langs tools) that use HTTP requests and produce JSON or XML replies.
SOAP with WSDL, the classic "web service" layer. In Java done with JAX-WS among other options. Most languages have tools for SOAP+WSDL but it's kind of crappy to work with especially on intermittently connected devices like mobiles.
XML-RPC if you like pain
There are some JAX-RS quickstarts on the JBoss AS 7 quickstarts list; just search for "JAX-RS". The "kitchen sink" quickstart is useful, though perhaps not ideal if you're not familiar with the basics of JBoss AS 7 and Jave EE 6. Fort the JAX-RS specifics you're better off with a Jersey or RESTEasy tutorial like this or this.
Important considerations
Use HTTPs if possible, and if access isn't to be public use a suitable HTTP authentication scheme like HTTP Basic auth over HTTPs. Any decent web services implementation will offer authentication options or support those of the platform on which it runs. Avoid the temptation to implement your own authentication and user management at the web services layer, you will screw it up; use the auth at the HTTP layer that's already written and tested. This may require the use of something like Apache's mod_auth_pgsql, JBoss AS 7's JDBC security realms, etc. The only case I'd consider not doing proper per-user HTTP auth is where I don't need to separate my users for security reasons, I only care that it's my app accessing the server, ie if my security requirements are quite weak. In this case I'd use a fixed username/password for the whole app and possibly an X.509 client certificate if Android supports them.
Remember that no matter how you secure things, all credentials are either known to the user or can be extracted trivially from a .apk so you still have to assume anybody could access your web service methods, not just your app. Write them accordingly.
Do not just send SQL from your app over a web service call to the server and return the results as JSON. This is horrifyingly insecure, as well as ugly and clunky. Write a web service method for each individual task you want the app to be able to perform and keep the SQL in the server. Remember to use parameterised queries and be careful of other SQL injection risks. These web service methods may use one or more queries to produce a single reply - for example, you might collect a "Customer" record and all associated "Address" and "Contact" records then return the result in a nice JSON object the Android device can consume, saving numerous slow and unreliable network round trips.
No matter what you use, make sure to do your web service calls in a background worker thread and not to block the user interface. Be prepared for timeouts and errors, and for the need for retries. Test your app by simulating intermittent connection loss, high latency, and high rates of packet loss and make sure it remains usable.
Is there a best practise:
It depends on the person. All have their strength and weakness.
I prefer, and I think many but not all will agree on JSON cause it is really easy to use in Android. It's also lightweight and very easy to use in php. Php has methods to convert an array/object to json and back.
It is indeed not recommended to save your postgres data on an android device.
My strategy is usually:
PHP server side with a POSTGRESQL database, using PDO to communicate between my models and the database.
If you are not familiar with PDO(php data objects), I recommend you make yourself familiar with it.
php.net PDO
Android as client, using JSON as method of transfering data from and to.
There are many examples that can help you.
Android has standard libraries to handle json parsing.
See this answer for an example:
example
I am supervising a project done by two students that involves retrieving information from a server and displaying it on an android phone. The students have never learnt networking, sql or java before (although they do know how to program) and are only now learning how to setup socketed connections between the phone and a sample server app that i gave them.
They will need to setup a simple sql database on the server on the campus network and be able to communicate with it and only pull information from the database and display it on the phone.
My current plan is that they will receive xml objects generated on the server side sent as a stream through the socket connection. They will then be able to generate a DOM using javax.xml classes and display it as they see fit on the phone itself.
Is this a valid method? What kind of problems can they expect to experience by following this technique? Is there another/better/correct way to do this (without using php or webservices)? The system will be for multiple users so will there be any significant performance issue with the proposed method?
Note 1: The phone never sends any request other than a single multicharacter identifier. The server interprets this identifier and returns information from preprogrammed queries and places it into an xml format.
Webservices sound like the correct approach for this, since you would not want to directly allow communication to the database over the internet.
The book "Unlocking Android" from Manning Publications, ISBN 978-1-933988-67-2 has a Chapter (6) dedicated to "Networking and web services".
Ah and then there is the one and only very nice video from a presentation regarding Android and RESTful webservices from the Google IO.
Couchbase, although from the NoSQL movement have a nice summary as well.
You could use JSON instead of XML, could be easier to parse and work with (feels more lightweight to me at least).
Sorry, forgot the answer for your search of problems:
Activity freezing upon freezing requests: Use additional threads for your requests
How to generally handle high latency
Handle offline behaviour