[aerogear-dev] New Android Pipeline

Wed Oct 3 12:55:41 EDT 2012

On Wed, Oct 3, 2012 at 6:53 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>>>
>>> Yes. So that makes Pipes API for java a wrapper around
>>> HttpRestAdapter.
>>> Also from this a gather that Pipes API does not use
>>> GET/POST/PUT/DELETE naming scheme, but it is closely aligned with it
>>> nonetheless.
>>
>> Sorry, my bad here. The way I understand is actually that Pipes API is more of a persistence API - layer 2 API if you wish, not GET/POST/PUT/DELETE (layer 1 type) API.
>
>
> Well, the pipe is just an abstraction layer for 'a' server connection (type).
> It was designed to hide the 'technical' details (e.g. http/rest), so
> yes. more of persistence instead of directly REST (GET/POST....).
> => A pipe can be used for different connection types (Transport
> layers), for instance websocket..
>
> For instance calling 'save' for instance on a pipe
> ('myOtherPipe.save()') would issue something like
> 'websocket.send()'...
>
> For READ, it's a bit different (difficult), since it's more 'event driven'....

At least in iOS (thanks to the blocks), it's not too hard; I guess the
same is true for the JS layer as well (e.g. callbacks)

-M

>
> NOTE: No design was done for that (websocket) so far... just saying.
>
> -Matthias
>
>>
>>>
>>> >
>>> > -Matthias
>>> >
>>> >
>>> > >
>>> > >
>>> > >>
>>> > >> >
>>> > >> >> The above picture 'models' URIs for this UML diagram:
>>> > >> >> http://www.infoq.com/resource/articles/rest-introduction/en/resources/figure1.jpg
>>> > >> >>
>>> > >> >
>>> > >> > Actually I understand this as two layers where figure1 layer
>>> > >> > API,
>>> > >> > uses figure2 layer API.
>>> > >> > That's the business interface layer that delegates to
>>> > >> > HttpRestAdapter, the two layer approach. In our case
>>> > >> > persistence
>>> > >> > view with operations like findById ...
>>> > >> >
>>> > >>
>>> > >> yes figure1 is the 'business' API, and figure2 shows how these
>>> > >> 'methods' map to the URIs...
>>> > >>
>>> > >>
>>> > >>
>>> > >> >
>>> > >> >> (Taken from this article =>
>>> > >> >> http://www.infoq.com/articles/rest-introduction)
>>> > >> >>
>>> > >> >> However the figure2.jpg shows as well, that there maybe cases
>>> > >> >> where a
>>> > >> >> DELETE on /tasks (or '/customers/{id}/orders') and a POST on
>>> > >> >> /tasks/{id} (or '/orders/{id}') can make sense.
>>> > >> >>
>>> > >> >> => We need to cover that too...
>>> > >> >> If I recall correctly those two 'corner cases' are also not
>>> > >> >> covered
>>> > >> >> by
>>> > >> >> the JavaScript library.
>>> > >> >>
>>> > >> >>
>>> > >> >> > - I wouldn't eat exceptions, and return null even in a
>>> > >> >> > not-yet-real
>>> > >> >> > exception handling :)
>>> > >> >> > (https://github.com/danielpassos/aerogear-android/blob/new-pipeline/src/main/java/org/aerogear/android/core/HttpRestProvider.java#L86)
>>> > >> >> >
>>> > >> >> > Really, either don't catch it, or if you do catch it,
>>> > >> >> > rethrow
>>> > >> >> > it
>>> > >> >> > as
>>> > >> >> > is, or wrap into another - normally RuntimeException is
>>> > >> >> > perfectly
>>> > >> >> > fine, so you don't pollute your API with throws
>>> > >> >> > declarations.
>>> > >> >>
>>> > >> >>
>>> > >> >> +1 on this comment - but he added a TODO already ;)
>>> > >> >>
>>> > >> >
>>> > >> > That's why I wrote 'even in a not-yet-real exception handling'
>>> > >> > i.e.
>>> > >> > don't _ever_ do it like that :)
>>> > >> >
>>> > >> >>
>>> > >> >> >
>>> > >> >> > - I would use IllegalArgumentException here:
>>> > >> >> > https://github.com/danielpassos/aerogear-android/blob/new-pipeline/src/main/java/org/aerogear/android/pipeline/AdapterFactory.java#L34
>>> > >> >> >
>>> > >> >> > It's more appropriate, as it's a standard pattern for this
>>> > >> >> > kind
>>> > >> >> > of
>>> > >> >> > use-case. By convention UnsupportedOperationException is
>>> > >> >> > used
>>> > >> >> > for
>>> > >> >> > empty methods where interface contract is not fully
>>> > >> >> > supported.
>>> > >> >> >
>>> > >> >>
>>> > >> >> +1
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >> > - We have to do something about this "getId"
>>> > >> >> > (https://github.com/danielpassos/aerogear-android/blob/new-pipeline/src/main/java/org/aerogear/android/pipeline/RestAdapter.java#L76)
>>> > >> >> >
>>> > >> >> > One idea is to have an annotation - @Id. But scanning for
>>> > >> >> > annotations needs to be done at init time or lazily on
>>> > >> >> > first
>>> > >> >> > use
>>> > >> >> > ...
>>> > >> >> > So maybe we could have an abstract base class with abstract
>>> > >> >> > method
>>> > >> >> > getId() that every data object has to extend, and
>>> > >> >> > implement.
>>> > >> >> > A
>>> > >> >> > simpler, and more robust solution actually, as compiler
>>> > >> >> > will
>>> > >> >> > enforce it so there is no way for not providing one, as
>>> > >> >> > could
>>> > >> >> > happen with forgotten or wrong placement of @Id annotation
>>> > >> >> > for
>>> > >> >> > example.
>>> > >> >> >
>>> > >> >>
>>> > >> >> I think the problem here is that not every object has an
>>> > >> >> 'id',
>>> > >> >> the
>>> > >> >> field could be name 'recordId' - In JavaScript this is
>>> > >> >> configurable.
>>> > >> >> iOS has a TODO here...
>>> > >> >>
>>> > >> >
>>> > >> > That's interesting. Can you give some examples?
>>> > >> >
>>> > >> >
>>> > >> >>
>>> > >> >> -Matthias
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >> >
>>> > >> >> > That's about it for now ... :)
>>> > >> >> >
>>> > >> >> > - marko
>>> > >> >> >
>>> > >> >> >
>>> > >> >> > ----- Original Message -----
>>> > >> >> >>
>>> > >> >> >>
>>> > >> >> >> 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
>>> > >>
>>> > >> _______________________________________________
>>> > >> 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
>>>
>> _______________________________________________
>> 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

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf