So I'm building a mobile app which will be using a RESTful web service (which I am also writing myself)
After lots of research I have a few questions regarding mobile apps and the HATEOAS constraint.
I usually use the Gson library for parsing objects without the HATEOAS constraint and it has been proven to be really efficent. For HATEOAS however, I am thinking of using Gson for the deserialization and Json-HAL for the response format.
How do I parse all of the _links and _embedded resources in my application without making the deserialization process tiresome? Some objects could have "embedded" resources and some don't. How should I create my data model objects to support all of these new tags? I am pretty lost on this part so I would appreciate an example.
Does anyone have any tips implementing this constraint on mobile apps?
If you think HAL or Json is not the right choice for mobile, please let me know.
Implementing this constraint for mobile seems like overkill to me.
Please enlighten me, Thanks!
Bit late to the party, but I feel that the best way to solve this is, summed up:
Yea HAL is a good format.
Treat things in _links and things in _embedded both as links. They are really the same 'thing'.
The difference with _embedded compared to _links though, is that _embedded really should pre-populate your cache. So whatever you receive their should be added to some kind of cache which should make future GET requests unneeded for those resources.
The benefit of this approach is that it now becomes possible for the server to 'promote' links from _links to _embedded and have your client automatically adapt to this and make less HTTP calls.
References: (disclaimer, I wrote both)
The problems with embedding in REST today and how HTTP/2 might solve it.
Restl, a hypermedia client for javascript
Related
Ok so, I know the question is pretty much google-able and I did google it and found out a few answers ,so I am not asking this question knowing completly nothing.
So, I have an application (Cannot specify much about what it does or is or so...) and I need to get some data from a database.
As far as I know, the Volley is the best way to go ,but I am still looking for more details.
Could anyone tell me which is the best way to go?
NOTE: I am NOT looking for code,I am looking for methods.A name would sufice ,as I can do the digging myself.Eventually links to documentations would be awesome, but again, I can find documentations.I just need to know which is the fastest way and the most optimized.
Based on your comment, it looks like there are two different aspects to your application:
Sending out the HTTP requests from your client- i.e. your android app
Processing and sending the response to these requests on the server side, by setting up a web service
Looks like you have part 1 figured out. Note that, volley is a library, similar to android HTTP library, but optimized for faster networking.
For part 2, unless you're planning to use embedded database like sqlite, you'd need to learn about writing web services to provide database access.
Spring Data JPA is one of the many ways to do it.
I hear Parse is great too, but not free.
I need to synchonize some data accross different phones. For example I want to enable "friends" to (automatically) share notes...
I'm now wondering what would be the best approch to reach this.
At the moment i think I'll have to write my own webservise to reach this goal.
As I started to think about a SOAP webservice I found lots of people saying that they would prpose a REST approach.
What would be the "better" solution in my case or are there any other approches for synchonizing data on different Android phones?
Maybe I should start by mentioning that REST is not a protocol and as such hard to compare to SOAP which is.
The main disadvantages with using SOAP for mobile applications are that it normally uses XML and thereby more data than most other protocols and that it's fairly complex both to set up and to maintain. On the other hand, if one party writes the server and one the client, SOAP gives you good ways to see to that changes are communicated clearly (ie WSDL). SOAP is generally not very well supported in mobile phones and may require third party libraries to make it work.
REST is often (mis)used as a name for HTTP based communication using JSON, which is a pretty easy way to communicate with mobile devices and has low overhead. If you have control over both server and client, it's not the wrong way to go (but not the only one either) JSON is generally very easy to get to work on all mobile platforms, and HTTP is well supported by the phones themselves.
It's better to use REST than SOAP because SOAP is very verbose and will increase the network data size.
Besides, if you use SOAP, you have to include external librairies (like kSOAP) to consume the response. With REST, a standard HTTP client is OK.
About data format: think about JSON that is less verbose than XML.
Concerning synchronization, I don't know if Android SDK provides classes to perform this work.
The most common way to consume SOAP based services on Android seems to be via kSOAP2 since it's recommended here on stackoverflow very often. I'm a fan of SOAP since I've been working with JAX-WS for a while.
But even the people behind kSOAP2 do not recommend it for mobile devices. I know that SOAP produces a lot of overhead you don't want to have on your mobile device. Do you have any experience with SOAP based services consumed by Android, is it really an issue? What is the main bottleneck, bandwidth or memory/cpu?
I need to transmit text and binary data, is REST the best alternative here?
Thanks
edit: If possible I want to avoid to build a parser by myself, should work without own parser. Maybe GSON?
I need to transmit text and binary data, is REST the best alternative
here?
yes. you can send binary data via HTTP POST, and sending text is trivial with REST. I suggest you to use JSON format as it is light weight and highly accepted through developers so you can find a lot of examples.
see http://www.springsource.org/spring-android for library for Android to automates JSON to object and vice versa generations.
JSON or XML over Http for text data. Http POST for binary data. Whether it should be REST or not is really up to you.
I'm working on an Android application which is fetching data from internet among other things. Actually, the project was started by someone else which is not here anymore,
and now that I have to turn it into a light client application and implement the server side (in Java), I'm wondering what would be the best tools/patterns to use to fit my needs.
Let's say I have to deal with several models (class representing a category) of objects which all inherits from one class : they have common attributes (such as name, attache thumbnail...) but specific properties too.
Because of this,you can understand that I can't afford to manage one specific table to map each single class.
However, I still want to be able to cache my objects somewhere in the Android device to populate the views of the application when working in offline mode.
Currently, the solution used by the previous developer was to store data directly into a TEXT field in the SQLIite database, as serialized objets.
This should be ok on the server side but I've read that the usual Java serializaton was very slow on the Android platform, although it is not really noticeable now because I work with around ~50 objects, I was looking for more performant alternatives for the future.
I've came across the JSON solution which can easily handle complex structures and Jackson library seems very interesting with its simplified data binding to POJO objects and its well-known performance.
But then, how should I store my Json objects ?
Is it possible to keep a json string in a TEXT field of a SQlite table ?
Or should I rather store them as .json file for each object ?
Which one is the more efficient to retrieve later lot of data?
Plus, I was thinking that JSON would be a very good exchange format between the Android client application and my server whould is in charge of processing the information from internet third-parties apis and exposing this data with webservices. (rather than trying to implement some RMI-like solution)
Is using the usual Apache HTTPClient enough on Android to communicate with the server?
For those who successfully developped client-server application (which seems very common to me) is this a good approach for Android ?
It seems to me that with mobile platforms, you can't really use the approach that you've learned for more classic J2EE app and such...
Any advice would be greatly appreciated because I'm a student and Android beginner who really want to improve her mobile development skills !
Thanks :)
That's open to discussion, so SO is probably not the best place to ask. In general, before declaring something is too slow (or fast), measure, compare and pick the one that works best for you. Yes, you can save JSON in a DB, an it will generally be faster than having separate files on the FS. But, again, benchmark and compare.
BTW, most J2EE 'approaches' (patterns) are overkill for any platform, let alone mobile.
I need to get an Android app to interface with an XML webservice (it's really just a request which returns XML), but as the data is large and includes some things I don't need (like a huge description block), I was thinking of transforming it via a server into a format that would be good for Android, and also to be reduced considering it will be used in a low bandwidth area.
Does anyone have any suggestions for a good lightweight protocol? I'm especially thinking about libraries for Android that already exist for say REST or even delimited data.
JSON is the alternative to XML. If you're debating whether or not JSON is the preferred way to go, both Twitter and Facebook are going to be getting rid of XML support for their REST APIs and only providing JSON. I'd go that route if possible. XML won't go away, that's a given, but it may just not be used anymore in RESTful APIs.
JSON is very lightweight, so you could use that. I'm sure there are libraries already written to encode/decode it in Android.