[aerogear-dev] Android: some questions

[Kris Borchers]

On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> On Saturday, September 15, 2012, Kris Borchers wrote:
> 
> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen at thoughtcraft.com> 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?
Not exactly sure what you want to see and iOS/Android are probably going to have to be different but hope this helps a little. https://gist.github.com/3729174

> 
> 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
> > 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
> 
> 
> -- 
> Sent from Gmail Mobile
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20120915/2ed8a43a/attachment.html