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.
Related
first post.
I am building an android app and the backend (remote server) im using ktor with exposed and hitting a postgresql data base. I am just unsure upon getting my results back from queries how I should attempt to send those back to my user app on android. What would be the right way. To have the user app install exposed library and just send the query results ? format all the results to a json string and blast that? Just dont know what would be ideal.
I haven't really attempted anything yet because I was looking for a "best practices" idea.
Hi and welcome to Stackoverflow.
There is no one "best practice" way to send the data from the server to the client. Noramlly it depends on your use case. However, one common way that I would suggest you use is to create RESTful-API.
This means:
Requests and Responses to/from the server will be serialized to JSON.
Confirm to HTTP verbs semantics (use GET to read data, PUT to update, etc).
Use status code for error handling
Follow the REST API guidelines for best practices (API versioning, end point names, pagination, etc)
To read more about REST API guidelines, this page is useful.
For Ktor, this will mean having a serializer, and then defining your routes. This guide is useful for Ktor.
Although this is not the only way, but it will provide you with enough experience to explore others APIs (Custom API, RPC, SOAP, etc).
I'm developing an android app where I would like to fetch some data (mostly text) from the internet but not necesseraly from a website! I would like to have a server that allows clients to fetch some text data. What kind of server fits my goals the best? Http or maybe simply tcp? I don't know much about http so I don't know if it matches my goals and/or if it handles well a kind of text "database".
Edit:
A use case could be: people could write comments and send them to the server. Then clients could refresh their app by fetching new comments from the server. Therefore I'M asking what kind of server could best handle services and kind offre database if needed.
I like using NodeJS in combination with ExpressJS for such purposes. This combination allows you to easily work with HTTP/HTTTPS which is allowed by practically every firewall or proxy server. As of the latter reason I recommend you to use HTTP instead of an own protocol. Furhtermore, Java offers the HTTPURLConnection client which is very easy to use. Moreover, securing traffic with TLS (SSL) is very simple. In addition, NodeJS is resource efficient, runs on Windows, Linux and even on OS X.
For getting the text you can use HTTP GET request handled by the get() method of the Express instance.
This compact tutorial helped me to get familiar with Express on NodeJS.
Without knowing what your use-case is it's difficult to make a good recommendation.
With that said you may find something like https://parse.com/ suitable.
They provide an Android sdk and the 'getting started' tutorials will have you up and running in no time at all.
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.
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 trying to make an android app that requires a user to login against a MS SQL Database.
Having read around the most popular way seems to be to use JSON to do this however I'm not sure how secure this would be (especially if there is no SSL being used).
My question is what are the alternatives available and if JSON is the best/easiest way to achieve this how can I make it more secure? Is this also how big companies (such as dropbox etc) do this?
When I first started Android programming I was told that making a direct connection to the database is considered bad practice, and that an interface (JSP, PHP, .NET) should always be used. I don't know if this is a security thing or not but it would probably be the best for you.
If possible, create a .NET (or whatever server-side language you are comfortable with; .NET would probably be the easiest if you're working with a MS SQL server) page and talk to it over HTTPS (there's your security) and pass it the login info using POST. You could use JSON but name value parameters would accomplish the same thing. Have your page connect to the DB and test the information you pass it against whatever is in it. Then pass back a value that says whether it is correct or not in the response.
EDIT:
This looks like a decent guide to getting HTTPS set up on Android (just browsed through it quickly so I can't vouch for it 100%).
JSON is just the form you pass data in.
Noone stops you from using SSL for the connection. Or encrypting the JSON data in your own way.