Re: [aerogear-dev] Android: some questions

Thx! On Sat, Sep 15, 2012 at 8:27 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Saturday, September 15, 2012, Kris Borchers wrote: >> >> >> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen(a)thoughtcraft.com&gt; 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 >> > >> > >> > ___Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf