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.
Related
I'm currently developing an Android application and I'd like to have an scalable architecture with a clean separation of concerns. The requirements of this application are, mainly:
User autentication (I'm dealing now with Google Sign-In for Android after many unsuccessful fights agains Android Identity Toolkit)
Synchronization with REST services (this application should be collaborative, I've already done a proof of concept to consume a "heartbeat" service, using AsyncService, that was the only way I've found to clean activies code, I got to that library researching about Robust Android Architectures)
ORM at client side to store user generated data and retrieved data in the future (my choice has been ORMLite for Android)
Material Design (as the best approach to the UI I have in mind)
First of all I'd like advices on how to separate classes inside the project, I mean, should I use folders (activity, model, DAL, service, sync...) or should I create my own libraries? (in .Net I'd create libraries with parent namespace)
My second and biggest concern is about user identity: how should looks like my architecture to achieve my goals? (sign up / Sign in with multiple providers, authenticated rest client and synchronization using SyncAdapter)
I hope you don bane this quiestion because maybe is too generic but I ask about all this stuff because I couldn't find information or advices about this stuff.
Thank you in advance.
This is a generic question and every dev has his own way to achieve this, but I would recommend to follow one of the trending patterns right now.
There is a project call the clean architecture. It has pretty much everything from dB to Api. In my opinion is a over-engineered.
I prefer another pattern called Flux.
Together with retrofit, eventbus or Otto makes building apps easy and keep the structure
You can read more about it here:
http://lgvalle.xyz/2015/08/04/flux-architecture/
What's the best way to design a Java server architecture that interacts with a client-side GWT application, but also responds correctly to various other client-requests from other platforms? Specifically, I'd like to use the same servlet layer to respond to not only my GWT application, but to corresponding iOS and Android applications.
The first approach I thought of would be to implement the GWT client layer using "RequestBuilder" rather than the usual RPC method service interfaces. Using this approach, I could code generic servlets that respond to HTTP requests in a RESTful manner by processing variables encoded in something like JSON or XML. Although this would work, it would be somewhat labor-intensive to have to encode and decode my objects/parameters in JSON on both the client and server, especially when RPC provided such an elegant solution.
The other approach (which I think is better), would be to find out the specification Google uses to serialize and deserialize their RPC method calls and implement some sort of library that does the same thing for iOS (in Objective-C) and Android. The problem is that I haven't been able to find good documentation about this encoding standard, nor have I found libraries that implement it for iOS or Android (although I did find something like it for PHP at www.gwtphp.com).
Could anybody steer me toward a specification for how GWT serializes/deserializes their objects or, even better, libraries for iOS and/or Android that implement RPC interfaces?
Make a "service" layer, i.e. a set of business classes that return POJOs.
Then you can easily have GWT-RPC and REST calling the service layer.
This is pretty easy and straightforward. Your issue is going to be how to create a business layer that only returns POJOs. But that's another story.
If you are truly trying to have a platform-independent server that clients can interact with, then your best bet is going to be to use a "least common denominator" approach, which is often simple data passing and surfacing handles for various actions to occur.
To that end, a RESTful interface, likely with either JSON or XML for encoding the data, is going to be your most supported bet.
The main advantage of going this way is that there are already lots of libraries that deal with serializing / deserializing JSON and XML, and you are keeping your service as flexible as possible, which means that you are not limiting your client base by requiring them to do very much other than deal with text and make web requests (at the most basic level).
It does put a bit more work on making the server-side of the connection do what you want, but that's the trade-off between the flexibility of fairly generic REST that any client can deal with and a much more target RPC-based service that, while it makes some implementations easier, does limit the clients to those that can deal with the specific RPC implementation.
GWT-RPC is really a bad choice when you don't control the clients' deployment, because the clients have to be updated each time you make a change to your classes. This is one of the reasons that led to RequestFactory being developped. And it'll work as-is on Android.
That said, I concur with Peter Knego: build protocol-specific public APIs on top of a single service layer.
Also, you can use GSON, Jackson and/or GWT AutoBeans to serialize objects to JSON.
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
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
I've been hired to develop a mobile framework for a webservice created by my employer. Ideally management would like to have some reusable components that can be shared across mobile platforms (initially iOS & Android, probably Windows Phone 7 at some later point).
I've been wondering how feasible this is. One of the requirements is a native interface, so we would use Cocoa Touch on iOS & whatever (Java-based) toolset is used to create a native UI for Android. The application will interact with webservices, mainly the ones that we've been creating internally. The webservices have been developed in .NET.
As far as reusable components go, I guess we could use some C++ code to make webservice calls and perhaps even more of the backend of an application, yet I wonder if this would be a good approach. Apple's Foundation Framework has some excellent capabilities build-in to access webservices, not to mention other open-source libraries, e.g. ASIHttpRequest, SBJSON, etc... I guess the same would be true for Android (though I have no real Android experience for now). Also, when looking at projects done by companies like Google, Twitter & Facebook, each of these companies offers native libraries built for the major mobile OS platforms. If the big companies take this approach, it seems logical for us to follow suit.
Perhaps we should focus more on a general architecture that we should offer across platforms instead of an implementation that can be shared.
Would anyone advise us to make use of C/C++ to develop such a framework (shared library) for the mobile site of our webservices? If so, why?
It really depends on what level of customized code you want to have. I worked at a game company previously, and we made two games for both iPhone and Android, and at least 90% of the codebase was shared between the two platforms in c++ code. Sometimes it is significantly easier to implement elements with specialized third-party libraries, like for Facebook and the like, but maintaining that code means continually doing it for both platforms. That was one of the reasons why we even implemented our own UI objects in c++ for our games. Because even though the initial setup would have been easier to do with Interface Builder and Android's XMLs, the maintenance and tweaking necessary ended up being significantly less because we went with a shared codebase.
In short, I would highly recommend writing any shared customized code in C/C++, and things that are significantly easier in their native codebases (java for android, or obj-c for iphone) and you don't expect to change much, to keep separate.
Depending on which WS protocol you use it may be more or less hard to do, but anyway I see little advantage in doing that in C/C++ for a mobile platform.
If you were using SOAP, I'd never consider C/C++, even for a desktop app. I already used SOAP libraries for C++ and they are a lot harder to use than their Java/.net counterparts, and the way they are implemented (mapping SOAP objects to C structs) is very prone to crashes if the format changes. Not to mention that you have to recompile your client when the WSDL changes.
As I understood in your case you plan to use REST. I never found a good REST library for C/C++, but recently I did a desktop project in which I implemented a C++ REST client using simply WinHTTP (in Windows) and libCURL (in Linux). Of course, they provide just the HTTP part, so I had to add cppdom for XML parsing. If you use JSON, there are many good libs like jsoncpp, libjson.
I'd say to you that even in a desktop environment it was harder to do than would be in .net or java, and was only done this way because it was part of a larger application already written in C/C++.
Anyway, you'll have more work and not much advantage since all those modern mobile platforms provide rich libraries that do the same thing, and probably the user of your API will develop in the platform's main language, so you'll have the double extra work of implementing the WS access code AND the binding code. As I assume all (or at least most) of your logic is in your server, not the client, there's not much common code between the platforms to justify using C/C++.