[aerogear-dev] Android: some questions

[Matthias Wessendorf]

On Saturday, September 15, 2012, Kris Borchers wrote:

>
> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen at thoughtcraft.com<javascript:;>>
> wrote:
>
> > Hey Matthias,
> >
> > Thanks for taking a look at the prototype!
> >
> > On 9/15/12 6:12 AM, Matthias Wessendorf wrote:
> >> I took a quick look at the Android API. Below are a few questions:
> >>
> >> * AeroGear.java
> >> - Is the class 'just' a util, that offers static methods? If so,
> >> should have a private ctor and be final (since a private default ctor
> >> prevents inheritance anyways)
> >
> > Yup, that's the intent, but since it's just a "sketch" I didn't put that
> > in - will do.
> >
> >> - is the API_KEY really needed? Not sure, but I think that (the
> >> API_KEY) is _perhaps_ something on-top of a networking client lib,
> >> needed when entering the real 'BaaS' market, where our lib. is used
> >> against a (specific) 'backend provider'.
> >
> > Right, I was pretty much following the common BaaS pattern.  It's
> > certainly not necessary immediately, but once we start supporting OAuth
> > we'll want something like that anyway, so I put it in as a placeholder.
> > Easy to remove if we decide we don't want it for now.
> >
> >> * Utils.java
> >> - related to the API_key, I think the X-AeroGear-Client header needs
> >> to be defined/discussed - but IMO the AeroGear client lib should work
> >> also without such a key, when accessing a simple JAX-RS (read:
> >> RestEasy) service; Of course, when 'cloud provider' start using our
> >> bits, something like API_KEY is a must.
> >
> > +1
> >
> >> - the 'delete' is public; the others (e.g. post) not...
> >
> > No semantic significance there.  Should probably all be package access,
> > since AeroGear is the user-facing class.
> >
> >> * Pipe.java
> >> - how to update an existing item?
> >> For instance in JS/iOS we use save which does an 'add' if there is no
> >> _id_ or issues an 'update' if the entity already exisits (e.g. has an
> >> _id_).
> >
> > Yep, will do that.  (although note that "_id_" or "_id" or whatever we
> > use is another point of coupling ;) )
> I don't think it does. In JS, I have made it so that what ever name you
> use on the server to denote an "id", you can tell the client lib what that
> name is. So whether the id field is named id or recordId, or blahblah, that
> is configurable when a pipe is created.


Can you post a snippet for that?

Thx,
Matthias




>
> >
> >> There is no concept of a 'pipeline', but I guess (at least for now) on
> >> "Java" (aka Android) a typed list (e.g. List<Pipe> pipeline;) is good
> >> enough, right?
> >> But on the other hand, than it's up to the user of the api to 'manage'
> >> all the pipes (server connections).
> >
> > Right.  What sort of "management" do you imagine, other than
> > factory-style creation?  Pipes as they stand are extremely "cheap"
> > objects (no db connections, network connections, threads, etc).
> >
> > Best,
> > --Glen
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20120915/86a12d9e/attachment.html