I want to send complex data from my android to a remote server via TCP-sockets. I know that I need to serialize the Objects. In Android this is done via parcelable. But this is an android specific interface and the server only knows the serializable interface. Also vice-versa android doesn't know a serializable interface.
Both the android and the server must "know" the object but they are implemented in two different ways (server--> serializable, android --> parcelable)
How do I use these interfaces properly, so that I can send Objects via TCP to the server successfully?
Why not use Simple XML serialization, works with both Android and Java 1.5+. Its located at the following site.
http://simple.sourceforge.net
Also, the framework is fairly small and suitable for mobile platform (approx 270K with no dependencies). And it much more performant than most XML serialization or binding frameworks.
We had the same issue here at work and we switched to JSON. Maybe you should consider doing the same?!
Edit: Android does know the Serializable interface. How could I forgot...
According to http://developer.android.com/reference/android/os/Parcel.html it is not appropriate to use a parcel for persistant (or network) serialization:
Parcel is not a general-purpose serialization mechanism. This class
(and the corresponding Parcelable API for placing arbitrary objects
into a Parcel) is designed as a high-performance IPC transport. As
such, it is not appropriate to place any Parcel data in to persistent
storage: changes in the underlying implementation of any of the data
in the Parcel can render older data unreadable.
Related
I'm currently using JSON (org.json) to serialize one of my data classes. When I pass it in a Bundle or with an Intent, I just call .toString() on the sender side and then recreate the class on the receiving side. From everything I've read so far, I should not implement Java's Serializable due to performance concerns. I'm in the process of rewriting certain portions of the app and I was considering making my data classes implement Parcelable and transfer them that way. What would the advantages be if I did it that way? Would it be preferable if I used the Jackson JSON library instead? Most of the JSON work is based on the API; server responds only with JSON. I also store some of the JSON for caching on the app side.
I think JSON is by far the most convenient mechanism for typical POJOs; and it seems unlikely that performance should be significantly worse that with Parcelable. Parcelable implementation could be more compact; but if that is problematic, you could even compress cached JSON payloads. So I would probably try out JSON first and see how it works.
I need to store an object content in Sqlite.
I was wondering which was the best way to do it with a serialization of the object or with Parcelable.
Is it possible to store it as Parcelable? How can I do it?
You are welcome to convert your object into some sort of persistable data structure (XML, JSON, Serializable) and stuff it in some database column. Bear in mind that you will still need to deal with compatibility issues (e.g., Version 2 of your app changes a class, which now needs to deal with both Version 1 and Version 2 structures). Also bear in mind that, going this route, you lose a lot of database capabilities (e.g., querying on something in the object).
You are also welcome to experiment with object databases, or CouchDb, or storing your persistable data structure to a file, if SQLite is not a requirement.
What most certainly will not work reliably is to pour the Parcelable into a Parcel and try storing the Parcel. A Parcel is meant for IPC use only and is not designed to be persisted. This is one of the reasons why Parcelable is faster than Serializable.
If you need to persist data, use Serializable. Parcelable is meant for IPC use. It is a binary format and not recommended for persistence.
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.
I'm looking for the best way to implement data transfer to and from an Android application.
Here's the solution I'm currently considering:
Data are transferred using JSON, beans are serialized/deserialized using GSON
Each object that can be transferred provides a "toBean" method and a constructor that takes a bean (enforced with a "Transferable" interface)
Before serialization I add additional info to the bean such as the response status, time etc.
Does this look like a reasonable solution? is there another pattern I could/should be using?
What you are doing sounds reasonable, I would personally use SOAP/REST web service since it is Java to Java, but that is just a personal choice, the best choice would probably be determined by the details of your interactions with the server as well.
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.