On Wed, Oct 3, 2012 at 4:54 AM, Glen Daniels
<glen(a)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/AeroGea...
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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev