[aerogear-dev] New Android Pipeline

[Marko Strukelj]

> On Wed, Oct 3, 2012 at 4:54 AM, Glen Daniels <glen at thoughtcraft.com>
> wrote:
> > Hi Passos,
> >
> > A few comments below.  I recognize that some of these things are
> > derived
> > from the JS implementation, which was the source for the iOS
> > implementation - so some of these are questions about the the API
> > in
> > general as opposed to Android in particular.
> >
> > * I'm not sure I like creating an initial Pipe at Pipeline-creation
> > time.  I guess this is meant as a shortcut, but in fact I think it
> > confuses things.  Since we need a line of code to get the Pipe
> > anyway,
> > I'd rather it be consistent and look like this:
> >
> > Pipeline pipeline = new Pipeline(baseURL);
> > Pipe<Task> tasks = pipeline.add("tasks", Task[].class);
> > Pipe<Tag> tags = pipeline.add("tags", Tag[].class);
> >
> > ...rather than special-casing the first "tasks" pipe and using
> > pipeline.get("tasks") to retrieve it.
> 
> I think I can see room for improvement here too... At least on the
> iOS/Android side of things...
> 
> I guess the following 'scenario' is fine:
>  => creating an empty pipeline with just the base URL, where adding
> new pipes is only done with an 'add' method.
> 
> > * Another consistency/symmetry issue (ah, I just read Marko's
> > comments
> > and I see he mentions the same thing): I think it's odd that get()
> > and
> > post() in HttpRestProvider can't take id arguments, and therefore
> > must
> > always work at the collection, as opposed to the individual
> > resource
> > level.  Simply adding overloads with an id argument would solve
> > this I
> > think, but maybe better to always require the id argument and allow
> > null
> > to access the collection.
> 
> Right, the get(id) is needed and as seen in the references to Stefans
> article (see previous email) a post(id) is also needed on the API, in
> general.
> (in the same way, how a DELETE on a 'collection' is needed => DELTE
> on
> /customers/{id}/orders cancels all orders for the customer)

Do you mean to define DELETE operation as a 'cancel' (not actually as a 'remove' - more like an 'update' of existing entity)?
Maybe that is a blackbox for this discussion, the important thing is that GET on collection returns empty after a successful DELETE operation.
But still it is an interesting question to me ... what are best practices when it comes to mapping a RESTful view of an application to the actual model behind - the controller in-between the view and the model could map these GET, DELETE, PUT ... to some business logic operations - like 'cancel' the orders, as opposed to 'delete' them ...

> 
> >
> > * HttpRestProvider again: the post() method at least (and perhaps
> > also
> > put/delete) should probably return a value so we can get server
> > data
> > back to the caller if appropriate.
> >
> > * I'm not quite sure I understand why we need the HttpProvider
> > interface
> > at all.  What other implementations of this (that aren't
> > HttpRestProvider) are there going to be?  We could get rid of it
> > and
> > just bake HTTP functionality into RestAdapter directly, no?
> 
> I think this comes from the iOS layer...
> I added a AGHttpClient, which is a very tiny subclass of
> AFNetworking's HTTP client (recommended pattern by AFNetworking). The
> subclass does (right now) not too much...
> 
> So the 'restful adapter' basically delegates all HTTP calls to the
> AGHttpClient:
> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/AGRestAdapter.m
> 

I asked myself the same question. Anyway it makes sense to make an API abstract in a way that allows plugging in a different implementation.
It could maybe be HttpClient as opposed to SFTPClient? Or HttpRestClient as opposed to HttpSOAPClient?


> 
> -Matthias
> 
> > * We should discuss testing + mocking and write down some common
> > tools +
> > patterns.
> >
> > That's it for the moment...  I'm in Chicago on the way home to
> > Boston
> > right now, and will be tuned back in on Wednesday afternoon.  I'll
> > try
> > to write up some more Android thoughts at that point, specifically
> > about
> > the Android-specific surface area of AeroGear.
> >
> > Time to catch my last plane!
> >
> > Best,
> > --Glen
> >
> > On 10/2/12 7:12 AM, Daniel Passos wrote:
> >> Hi guys
> >>
> >> I did some changes in the android library based on iOS stuff, it's
> >> closer to the pipeline adapter implementation. I would appreciate
> >> feedback and review.
> >>
> >> https://github.com/aerogear/aerogear-android/pull/1
> >> https://github.com/aerogear/aerogear-android-todo/pull/1
> >>
> >> Thanks,
> >> Passos
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> --
> Matthias Wessendorf
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>