[aerogear-dev] New Android Pipeline

Wed Oct 3 09:41:37 EDT 2012

On Wed, Oct 3, 2012 at 2:05 PM, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> 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.

the article is not clear on 'cancel', but I'd 'interpret' it as
'remove ALL orders from the customer...

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