I used to do all XML with XStream, but now due to deprecation I'm forced to switch to JSON for two APIs, one of which is a Google API. Since there's this google-api-java-client that should work well on Android and allows to do this in a record number of very few lines of code, I'm probably going to use this.
Yaniv's Google I/O 2011 presentation is still ringing in my ear:
This library is basically designed for any API on the Web. ... Why would you want to use a different library with one vendor, and a different library for another vendor? Ideally, you'd like a library that would work with pretty much any API and have a consistent experience.
True. So here's my question: How can I reuse parts of this library for similar but non-Google APIs and make my life easier? Does anyone have any experience with this, or code samples?
The other API uses JSON. I'm talking about very simple REST calls that anonymously get data (i.e. no API keys or OAuth). No advanced stuff. I'd be happy to build my own model classes and of course realize they'd not be available. I'm probably an intermediate level developer when it comes to REST. I'll be using two different transport methods, and two different JSON parsers, based on Android SDK level.
Edit: Yup, implementing the client for the Google API was a breeze, except for wrestling with the new quota limits.
It's hard to say which components you can reuse and how you can reuse without having seen the API :)
I'd probably start by pointing the client directly at the new API and inspecting what breaks. If after digging around with the debugger the problems do not look too bad, I'd tweak the client as necessary.
However, if you're really just reading from a simple rest API, you may not find a whole lot of benefit from attempting to reuse the Google client. An HTTP client combined with a JSON parser like Jackson may be sufficient and less complex.
~~Jenny
Related
Disclaimer. I'm asking this on someone else's behalf and given that I know as much about Android development as penguins about flight, it may be clumsy. In such case, let me know and I'll remove it or try to reformulate.
I've created a web service that's reachable at the URL on the following form.
http://server/Blopp.svc/Store/value1/value2
The back-end part I've got covered but I'm worried about the front-end development. I've got a colleague that's making the app and he's got the rudimentary GUI done. However, in order not to do a lot of convoluted coding, he's heard that there's a certain library for making such URL calls.
What's the name of it? Is there certain other aspects to take into consideration or is there an (almost) standard one that everybody uses?
Please not that the app's functionality is at the moment limited to providing the web service with data. All the logic and presentation is done on the website and not inside the app.
I've never built up an Android app, so I'm asking for understanding if this is a dumb formulation. I just want to help my co-worker and he seemed to struggle with the details.
Is there perhaps a smoother way to make the call to a web service if I substitute the patter of the URL to use query strings? Any other approach that makes it easier for an Android developer? I'm not familiar with the area but I want to make things easy for my team-mate.
There are quite a few different HTTP libraries available and it would really depend on your specific requirements which one you used (if any - you can roll your own HTTP requests using HttpURLConnection) Two of the more popular ones are:
Volley
http://developer.android.com/training/volley/index.html
Written by one of the guys on the Google Play team and part of the AOSP. Very flexible and easy to use however I would hesitate to recommend it as it relies on the now deprecated Apache Http classes in its public API.
Retrofit
http://square.github.io/retrofit/
From Square. Version 2 is currently in late stages of beta. It allows you to define your API as an interface. It has dependancies on their OkHttp library as well. Very fast and also has RxJava support baked in.
I had integrated Google Drive in my app a few month ago but I had to stop working on it for a bit.
Now, my code imports com.google.api.services.drive but all the documentation online refers to com.google.android.gms.drive.
I am confused: should I rewrite my code? What happened while I was away?
Thanks.
These are two different APIs, the REST Api (com.google.api.services.drive) and GDAA (com.google.android.gms.drive). REST is the 'low level' networking API that sits underneath GDAA, it is also more powerful. But with REST, you have to manage the networking issues (on/off-line, waiting for response, ...) yourself, preferably in sync service.
GDAA does it for you, it resides in GooPlayServices and is supposed to simplify things. Please see this answer. If you already started with REST, do not mix these 2, otherwise you'll run into problems with latency. Also, GDAA does not support the full DRIVE scope.
There are two demos, REST and GDAA implementation of CRUD functionality that can show you the similarities/differences.
And finally, to answer 'what happened while you were away'? GDAA was built on top of the REST Api (Jan 2014), to place a layer between the REST Api and the apps. The idea was that they could push new versions of the Drive Api to the devices using the GooPlaySrvcs. And of course to add all the synchronization, networking management to shield the apps.
Good Luck
After a while defining, what my actual problem is, I found Lean-Engine.
It is a library for GAE, which provides afaik all possible authentification methods, supported by GAE (and some features I don't need). The only thing that makes me worried about is, that it is 3 years old.
This means to me that:
This is not the way to go
It is out of date
since I had to search a lot, I guess no one is using it, which propably has reasons.
So my question:
Is there another library (in JAVA!) (a one up to date would be good) like that?
[Edit:]
There is another lib called SimpleOauth, which is python only. Dunno, If I could combine that with my java endpoints. Still a year old... :/
LeanEngine is not developed anymore (I'm the author). Also it's focus was not authentication only, but being a simple mobile-cloud solution (aka an open-source version of mobile clouds, e.g. Parse.com).
Oauth 2.0 is a standard, but it's pretty wide and differently implemented by different vendors. See Pac4j for a cross-vendor multi-protocol authentication library. There is direct support for different vendors supporting OAuth. You can also easily add support for new vendor-specific OAuth logins.
Some time ago I added a patch to make it work on AppEngine.
Our team is working on Android Application back ended with App Engine. We have some difference on opinions regarding the implementation of client-server communication. On one hand App Engine suggesting RequestFactory approach, which (as Google say)
provides a solid foundation for automatic batching and caching of
requests in the future
and light-weighed
But we find this approach a little "clumsy". On the other hand we can use an ordinary servlet approach which we know well, and feel more comfortable with. We sure want lighter, faster and scalable communication, but in what proportion RequestFactory really provides them? What more we can gain and loose from both approaches.
[More of that, we read about such options like GWT-RPC (an older version of RequestFactory), and RestyGWT. But we know little about these approaches and not sure if their fit our case.]
I found here some similar questions not answered. So I suppose, this may be a helpful discussion for many.
A few notes:
RequestFactory is not a part of AppEngine (see here), but an add-on introduced by the latest Android Eclipse plugin. Originally RequestFactory was created for GWT.
The upside of RequestFactory is that is seamlessly works with GWT and Android.
The downside is that it's not cross-platform, i.e. not available for iPhone, etc..
It's unclear how to version RequestFactory. If your app is big and evolving, you are bound to have two or more versions of RPC APIs serving clients. GWT clients can be easily forced to use the newest API (=page reload), not so with Android. AFAIK, there is no option of having two RequestFactory endpoints. With REST you can simply have multiple URLs for different API versions.
Mixing public/private APIs. Since there are no multiple RequestFactory endpoints you can not easily divide them into public (no auth required) and private/secure (= auth required). With REST (and GWT-RPC) you can simply have two servlets (private and public) and set security constraints in web.xml (or have your own servlet Filter).
RequestFactory does not support java.util.Map. This severely limits you ability to have entities with dynamic properties - there are workarounds to this but they are IMO an unnecessary kludge (like having two lists, one for keys the other for values).
Solution: this is a solution that I use in my projects:
Create a service layer that returns POJO domain objects.
Create RPC layer that calls the service layer. You can have multiple RPC technologies calling the same service layer. I usually have GWT-RPC and REST.
Using POJO-only domain objects is sometimes impossible (also due to JPA/JDO), thus forcing you to create DTOs. DTOs are a pain to maintain and I try to avoid them if possible. It's possible to use domain objects most of the time with some workarounds: on AppEngine you can get a lot of help by using Objectify instead of low-level/JPA/JDO. It supports GWT-RPC. With REST I suggest you use Jackson where you can do all kinds of custom conversions.
I'm going to develope an application based on web services (axis2) and android (clients).
I'm now planning the logic architecture for my system and I supose that it should be like a SOA architecture. I have seen that a SOA architecture is based on layers.
So, this would be a "correct" logic architecture for my application? (with some changes of course)
http://geeks.ms/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/unai/DDD_5F00_NLAYER_5F00_ARCHITECTURE_5F00_SMALL_5F00_6ADA95E1.png
Android code (activities) would be on Presentation Layer?
EDIT
April 2014
Now, 3 years later with some more experience... REST is the best :)
Warning, it may that this answer is not at all an answer to you question but anyway, here is my thoughts.
I'm definitely not a SOA specialist but since SOA can be implemented with REST, it should not have any consequences on a SOA architecture. Android is REST-ready (see that Google IO 2010 session on REST) and there is only little SOAP support on android (afaik, but I may be wrong).
At some point, you'll have to evaluate the feasibility of the interop. between your Axis WS-* with any existing android SOAP support (the well-known ksoap2 project for example). The result could be not without impact on your architecture design.
The point here is: if you do use Rampart to use WS-Security, for example, on top of Axis2, it seems to me there are little chances that ksoap may interact at all (technically) with your service provider. On the one hand, if the service is simple and can be bound with ksoap2, great, go on. On the other hand, if you would use a not so simple security or authentication scheme, it could just be a nightmare to get the things done with the simple SOAP support on android. In the latest case and as the REST approach seems to be the preferred philosophy on android, you may be confronted to the decision to have a REST proxy dedicated to android between your Axis2 business WS and the android client-side application.
In the hope it may be of any help.
Perhaps you could even try SOAP. Android supports SOAP web services and provides ksoap2 libraries which you can use for sending request and getting response from your server easily.
For starters just check this out. Now, the latest version of ksoap also supports passing of Object Arrays.
For more information of ksoap2, I suggest to read this
Cheers
All the best