[aerogear-dev] New Android Pipeline

[Matthias Wessendorf]

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)

>
> * 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


-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