[aerogear-dev] Android: some questions

[Matthias Wessendorf]

:) I think there is no 'ideal' name for that value :)

On Mon, Sep 17, 2012 at 1:24 PM, Kris Borchers <kris at redhat.com> wrote:
> Because not all data storage refers to this as a primary key, right? I'm
> thinking of MongoDB for example.
>
> On Sep 16, 2012, at 2:58 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>
> Hi Kris!
>
> One more question,
>
> why 'recordId' instead of 'primaryKey'?
>
> On Sunday, September 16, 2012, Matthias Wessendorf wrote:
>>
>> Thx!
>>
>> On Sat, Sep 15, 2012 at 8:27 PM, Kris Borchers <kris at redhat.com> wrote:
>> >
>> > 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
>> >> >
>> >> >
>> >> > ___Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Sent from Gmail Mobile
> _______________________________________________
> 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