I am writing an Android app that talks to a Google App Engine server. The server holds persistent data, which it stores and fetches using PersistenceManager. The way I have this set up now is as follows:
A #PersistenceCapable class on the server called StoredThingToRemember has the information to remember, as well as some GAE object persistence jazz.
When the Android client wants to fetch a ThingToRemember, it sends an HTTP request to the server, which fetches a StoredThingToRemember from a PersistenceManager, converts it to a ThingToRemember implements Serializable, serializes it as a byte[], then sends it in an HTTP response.
The client unserializes the ThingToRemember and uses it.
This works, but it seems wonky. Ideally, I would like to serialize and send the StoredThingToRemember itself. Unfortunately, that seems to require putting all the GAE object persistence classes in the Android app, which seems silly and wasteful.
What is the correct way to grab an object from GAE persistence and then use that object in an Android app?
Using serialization formats for transmitting data is generally fairly risky - they're usually not designed with transmission across trust domains in mind. Further, by doing so you're locking yourself in - both your client and your server will always have to be written in Java. Any further clients will either have to be written in Java, or will require a whole new interface.
Instead, you should serialize to a language-independent format, such as XML or JSON.
Related
I need to retrieve huge amounts of data from a database through a web service from an Android app. I have two different ways to do this, and I wanted some advice on it:
1. The first option is to create a .php file on the server side that managed any POST coming from the client (Android app). The server would then create a JSON response. Finally we would parse this response using a JSON parser in Android. This is also known as the REST scheme.
2. The second option is to create a SERVLET, execute it from the client (Android), have the servlet send the request to the database for us, and finally parse that data from Android. Obviously the servlet would be written so that it could easily interact with the database.
Points to note (so as to decide which option is better):
1. I won't be storing anything in the database from the client. That is, my Android app is read-only.
2. I will be reading from a huge database, so it is a priority here the performance of the Client-Server interaction, with a special mention for data parsing and for servlet vs php performance.
Any help would be greatly appreciated.
Android has built-in support for parsing JSON data with the use of JSONObjects and JSONArrays, so it would be a lot easier to handle data in that form, rather than handling servlets. Its even possible to directly receive the web service response as a JSONObject or JSONArray.
In general, web services in Android should be of the RESTful type. That's how Google seems to prefer it. That's why there's built-in support for JSON, but not for SOA or Servlets.
References:
1. Reasons for not directly write Servlets for creating a REST API.
2. Servlet vs REST.
I was wondering if there are some commonly used techniques for synchronizing an app with a server? I have looked at the socket-framework and maybe some http? I am thinking for instance when making a game or a grocery list, any developers out there who want to share?
I would say that the most common method is to send client data via HTTP POST using SSL/TLS encryption. The data can be sent in any format, but generally it is structured as a JSON or XML message.
The hardest part is that you need some form of authentication in order to identify the user and update/sync the correct information on the server database in a secure manner. Have a look at this article for some basic concepts.
In android, you can use the excellent Google Gson library to convert Java object to/from JSON objects.
Http communication can be performed via the Android API methods.
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 plan on consuming the REST services provided by ServiceStack outside of .NET. I plan to writing clients for java and obj-c. This should be easy since it is a REST service, however in the documentation it seems to suggest otherwise:
But ServiceStack includes two clients which are optimized for ServiceStack in aspects like exception handling etc.
How would I go about implementing a ServiceStack client with Android? Just follow normal REST consumption procedures? Should I worry about any exception handling issues?
Also, would authentication be an issue (I'll be using BasicAuthentication)?
ServiceStack web services provide pure HTTP/REST APIs which are essentially just serialized POCO DTOs over the wire. You control the entire HTTP output as ServiceStack doesn't add any additional cruft around your serialized payloads.
Expects Pure Serialized DTOs
The opinionated nature comes from the ServiceClients assuming that the services are just returning pure serialized DTOs (i.e. without additional cruft) which it simply deserializes as-is into the specified response type. The ServiceClients are unique in that they give you a strong-typed end-to-end API without any code-gen since you're able to re-use the POCO DTOs you defined your web services with.
Fallback to pre-defined routes
The APIs that don't speicfy a relativeOrAbsoluteUri in the API like the Send<TResponse>(dto) will by default use the pre-defined routes automatically provided by ServiceStack allowing you to call web services without needing to specify any Custom routes for them. You can of-course opt to use your custom routes instead by sticking to the IRestClient and IRestClientAsync APIs which allow you to specify the url to use.
Automatic Error Handling
The C# ServiceStack ServiceClients are optimized in that by convention ServiceStack web services will serialize structured error responses in a ResponseStatus property on your Response DTO (only if it has one). All the service clients do is just de-serialize the error response into a typed C# WebServiceException which gives your C# clients strong-typed access to structured errors as explained in detail in the Validation wikipage.
Basically the ResponseStatus property is just a convention (not some anti-REST magic) and you still control what HttpStatus Code and Description gets returned. It's simply another pure DTO property that all REST clients have equal access to - here's a simple JavaScript ss-validation.js routine that extracts the responseStatus metadata and injects the errors onto a Twitter Bootstrap HTML Form.
I'm looking for some best practice concepts as far as transferring data between a mobile device (Android right now, but concepts apply pretty much to the rest as well). I currently have a WCF service set up with a working JSON endpoint. I'm starting to modify the existing service methods with the appropriate WebGet/Invokes, etc to make it RESTful. The service implements the request/response pattern so that all communication between a client and the service are wrapped in a complex MessageRequest and MessageResponse object.
What is the best way to have a mobile application successfully utilize this pattern? There are only two solutions I can come up with, each with their own pros and cons:
Create all the data transfer objects in the client project, and then create a JSON/DTO mapper (GSON might work well here). Use the client-side objects to handle all client data management until a server request is necessary, go DTO-to-JSON, and send the request to the server. The upside here strikes me is that it makes client-side data management easier because it parallels the service domain. The downside is that these have this has the potential to breakdown the more complex an object becomes.
Ignore the DTOs client side and just do everything straight from the JSON. The upside here is that it removes the overhead associated with the larger objects and the required mapping. The downside here is that this strikes me as being very brittle - any changes to the returning object need to be handled deep in the code, rather than just making the change to the client side DTO and mapper.
Is there a better way to accomplish this data exchange? Or are these the only real ways to handle it? How do you manage data transfer in your mobile applications?
I have a very similar WCF setup as you do, and I ended up creating very lightweight data objects client side. These manage pulling apart a JSONObject representing themselves and create any sub-objects they need, but aside from that are simple classes mostly used to group data together and contain no business logic. We haven't yet needed to do any client side caching, but these objects would be a great place to put in SQLite code to persist themselves out.
It has worked great so far, and we were even able to port the client-side Android code to another project running regular Java just by including org.json.