I'm planning on developing an app for android that requires a back-end server to sync data with other users of the app. I'm planning on writing this server in standard java running on a unix server.
I once did this directly between two android devices, in that case I just serialized all the data needed to be sent on both ends.
However I suspect that the format that Dalvik serializes to and Java SE's format are not compatible. Is this the case? And if it is, what are my alternatives? One thing that popped into my mind was sending raw xml over a socket, but if there are better alternatives I'll be glad to hear them.
Thanks.
If you are doing a server then you should rely on something more standard like XML or JSON. I personally favor JSON. You shouldn't expect all your client to be Java friendly. Almost every mobile device support JSON. Look at Jackson library to generate your json. Then you can use Jackson again to deserialize your object.
The beauty of this solution is also stupid simple. You can look at the content by just just putting the request in your browser. Not so easy with binary data.
I have used data serialization successfully between Android devices and servers.
I did have to convert TimeZone class to String and back because the TimeZone class in particular is not fully compatible (it tried transferring something in the sun. package which got ClassNotFoundException on Android).
Other than that I have been able to transfer objects from java.util collections and maps and from java.sql data types and of course the java.lang types String, Integer, etc..
You can try protobuf for serialization. It is said to be more efficient, and you won't be concerned about compatibility.
You can also use some form of XML serialization (JAXB, XStream, XMLEncoder, etc)
The resolution of this question hints that it is compatible.
If your object graph is pretty simple and if you are comfortable with JSON at all, Android has JSON support included and it would be easy to get support in Java SE. I tend to think of JSON as a good alternative for when XML or Java serialization seems to "heavy".
Have a look at this benchmark. Kryo is the one I'm using. It supports creation of the custom binary serialization, which can be done in a way suitable for both Dalvik and JSE.
You may want to look at a related question, which provides additional discussion and links.
Protocol buffers would be a good format over the wire to consider.
I can't speak to the serialization of Dalvik.
Related
I need to pass data between c++ program and a Java GUI that is showing that data. I can put that data in a class but the c++ program could be running on linux(raspberry pie) and java may or may not be on windows. What options do i have?
Kindly help me for same machine processes and also if they are on different machines.
P.S.
On different machines internet connection is available.
You may want to implement some serialization.
I suggest using a simple textual serialization format like JSON (but you might consider also YAML or even XML). There are many JSON libraries available, like jansson (in C), JsonCpp (in C++) and several for Java.
Of course, you need some form of Inter-Process Communication. This can be sockets or pipes. Read e.g. Advanced Linux Programming or some other tutorial. Maybe have some Event Loop (e.g. libev, libevent) or even use JSON-RPC (or perhaps some HTTP server library)
You could use binary serialization like XDR or using libs11n but it is usually not worth the trouble.
I have a client-server system implemented in C#, and the client and server exchange .Net objects via serialization / deserialization and communicating via TCP/IP. This runs on a local network, it is not web-based or Internet-based.
Now I want to include Android clients connected by wifi. Again, this is local network only, not via the Internet and not web-based. The Android programming will be in Java. (I am aware of Mono for Android, but prefer not to get into that now.)
Is there some fairly simple way to implement object to object interchange between Java and .Net objects, provided, of course, that they are compatible?
I've looked a bit at JSON (Jackson on the Java end and Json.Net on the .Net end), and I'm guessing it can probably be done, but only with major efforts on remapping things at each end as soon as the objects become fairly complicated.
Any other suggestions? JSON-based or otherwise?
PS. My question is somewhat related to this one Mapping tool for converting Java's JSON to/from C#, but it never got a suitable answer, perhaps due to insufficient info in the question. Also, I don't care whether I end up using a JSON-based transport or XML or something else.
I would suggest either JSON or XML (which is based on a .xsd file) because these are independent of their respective implementations (instead of something like an ObjectOutputStream in java).
The problem of having this format between the two components (client and server) is that they need to be at the same version. My best practice is to have one underlying definition of the format (i use xml with an xsd file which specifies how the xml has to look like), then use jaxb to generated java classes. That way you can (un)marshal from/to xml in the java part.
I am very sure a similar thing exists in the world of .NET.
JSON is smaller than xml in size, i find xml to be more readable.
SO user "default locale" should get the honor for this, but he/she has only answered via a comment. So just to make it very clear what my choice was I'll answer my own question.
I've decided to go with Google Protocol Buffers, which in my opinion has much better support for moving objects back and forth between Java and .Net than JSON. Because I have a lot of experience with C#, and a lot of existing C#-defined classes, I've selected Marc Gravell's protobuf-net program for the .Net end, and Google's own support for the Android end (no - see edit). This implies that I'm defining the objects in C#, not in .proto files - protobuf-net generates the .proto files from which I then generate the Java code.
Incidentally, as the transport mechanism I'm using a little-known program called naga on the Android end. http://code.google.com/p/naga/ Naga seems to work fine, and is well-documented and has sample programs, and should be better known in my opinion.
EDIT:
OK, I've got it working now to my satisfaction. Here's what I'm using:
Google Protocol buffers as the interchange format: https://developers.google.com/protocol-buffers/
Marc Gravell's protobuf-net at the C# end: http://code.google.com/p/protobuf-net/
A program called called protostuff at the Java end: http://code.google.com/p/protostuff/
(I prefer protostuff to the official Google Java implementation of protocol buffers due to Google's implementation being based on the Java objects being immutable.)
Actually, I'm not using pure protocol buffers as the interchange format - I prefix the data with the name of the (outermost) class being transmitted. This makes the data self-identifying for deserializing at the other end.
You can also try wox (https://github.com/codelion/wox), it is a cross platform serialization library for Java and C# based on XML.
My universities peer to peer communication course uses an in house client/server program for demonstration and (i think) extending it is part of the assessment. The program we use is written in java and uses serialisation for the network communication.
To get a better grip I want to try reimplementing the protocol used in objective c, but googling around I cant find any information on using serialised data between languages. I would like to keep this as simple as possible, ideally be able to drop my replacement server/client onto a network and have it behave.
Edit Didnt actually ask a question there.
Is it possible to communicate between the two serialised formats, How can I make this work without reverse engineering the format java uses.
I would recommend avoiding writing (de)serialization support of java's native serialization in another language.
If you can change the existing Java server and clients, use a more language agnostic serialization format.
Assuming that you are not allowed to make that sort of change, I would define the new protocol, and implement a bridge in Java. The bridge (process) would establish a connection on behalf of each client that connects to it, and translate messages between the Java serialized and language agnostic form. This will provide a good migration strategy.
Java serialization protocol (if it's built-in default Java serialization) is documented, so you won't have to reverse engineer it - check this article and this link. However, if you can, use JSON, XML or XML-RPC; it will be much simpler than creating Java serializer/deserializer in another language.
I'm working on a web service that will be accessed from an Android app. After doing some research on what's the best technology, I'm left somewhat confused and dazed by the options.
Obviously on the Android end I want it to be as lightweight as possible. I also would prefer to share the common code since both are java, although that's less important. My primary concern is having it be efficient, and after that, simple and elegant code.
I've tried gson on the Android end, and it works nicely. But then I read about protocol buffers, and that seems even more efficient, I'm not sure if it's a significant difference. Also I'm not sure whether to go for RPC or REST.
On the efficiency front, Protocol Buffers will probably be more efficient than any JSON implementation, thought not necessarily by as much as you think. GSON is not particularly fast, but the Jackson library can almost compete with most binary serializers (Jackson is 2-4x faster than GSON in most situations and 10-20x faster on UTF-8 because it has special code for UTF-8).
But I'd still take Protocol Buffers over any JSON library because of the programming model. With most JSON libraries, your have to check the structure of a message manually. With Protocol Buffers, you specify message structures declaratively and the library will take care of the structural validation for you (though there will still be things that you need to validate manually).
Other libraries like Protocol Buffers: Apache Avro, Apache Thrift.
The Protostuff library uses the Protocol Buffers data model (so you get structural validation for free) but support serializing to JSON and YAML in addition to other formats. This can be useful if you want your service to be consumed by Javascript code, where JSON is often the easiest thing to deal with.
I am pretty far into my first Android application, and I have the sneaking suspicion that I'm "Doing It Wrong". My app talks to a Ruby on Rails server and serializes objects back and forth via XML. Before I knew what was happening, I found myself knee deep in writing my own crappy ORM, a problem which is compounded by the fact that I haven't written any Java since high school.
My conflict here is that I want my client-side (android) app to be capable of serializing via a variety of methods, such as HTTP/XML, to a local database, or out to the local filesystem. I started out with the Strategy pattern, but I feel like my solution is badly lacking.
For one, should I re-implement all of Rails model validation on the client side, because I don't know if I'm always going to be working with Rails on the other side? The even bigger issue is that right now I can only represent flat objects as key-values, as my code can't handle nested objects like a true ORM.
I'm sure Android devs deal with this all the time, so I'm interested to hear what other people do to cope with these issues.
I wouldn't approach your Android application as an extension of a Ruby app - rather a consumer of an API. If you can try to expose your server application as JSON (or other format, but JSON is the most lightweight) and consume these APIs from your Android application you would most likely have less problems as JSON is already in K/V format.
I have not yet written Android objects to SQLite yet, but I have written them as both Parcelable objects and to the SharedPreferences. Both of these strategies are sufficient for small to mid-range apps. For data intensive apps, obviously you will have to take it a step further to SQLite.
There are some great articles for these approaches: Managing State.
It boils down to designing your objects in a way that can be serialized easily. That means no circular references or extremely complex objects. This shouldn't be a very large problem, especially if your data is in JSON format already. You simply need to extend some classes and add functions that return a Parcelable object representation or a string representation so your objects can be saved thus.
I would avoid cloning your server-side objects and validation in Android as it then requires modifying both sources if you make small changes. The server should handle all data and validation and you should simply be requesting, caching, and sending data from Android.
I'd be interested to hear if there any challenges to writing objects to SQLite, but I imagine it's not that much more of step from the details I've outlined above. Hope this helps in some capacity!
Hessian is great for RPC. You don't have to do any serialization yourself. It doesn't use XML, so it's more efficient and more appropriate for a mobile platform.
I haven't done much of persistence storage on Android but I think you need to use SQLiteDatabase and make your own Cusor that De/Serializes your object so that it can be added to the database. A possible solution would be to extend a SQLiteCursor or an AbstractCursor.
Otherwise I don't think there is other solution apart from, possibly, "hardcore" Serializabled (Which I suspect it may be too much for a phone, I may be wrong)
I think you might be going too heavy for a smart phone application. I would look at using RESTful style web services with JSON content.
Looking to your question I got the feeling that maybe you just over-complicating your requirements? Why can't you just use JSON format to represent your objects data in portable way? Then you will be able just to store it either on file system or in database in simple text field. You can leverage android-active-record library for transparent DB persistence (http://code.google.com/p/android-active-record)