Hi Kris!<div><br></div><div>One more question,<span></span><div><br></div><div>why &#39;recordId&#39; instead of &#39;primaryKey&#39;? <br><br>On Sunday, September 16, 2012, Matthias Wessendorf  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thx!<br>
<br>
On Sat, Sep 15, 2012 at 8:27 PM, Kris Borchers &lt;<a>kris@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf &lt;<a>matzew@apache.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Saturday, September 15, 2012, Kris Borchers wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Sep 15, 2012, at 10:53 AM, Glen Daniels &lt;<a>glen@thoughtcraft.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; Hey Matthias,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks for taking a look at the prototype!<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On 9/15/12 6:12 AM, Matthias Wessendorf wrote:<br>
&gt;&gt; &gt;&gt; I took a quick look at the Android API. Below are a few questions:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; * AeroGear.java<br>
&gt;&gt; &gt;&gt; - Is the class &#39;just&#39; a util, that offers static methods? If so,<br>
&gt;&gt; &gt;&gt; should have a private ctor and be final (since a private default ctor<br>
&gt;&gt; &gt;&gt; prevents inheritance anyways)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yup, that&#39;s the intent, but since it&#39;s just a &quot;sketch&quot; I didn&#39;t put that<br>
&gt;&gt; &gt; in - will do.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; - is the API_KEY really needed? Not sure, but I think that (the<br>
&gt;&gt; &gt;&gt; API_KEY) is _perhaps_ something on-top of a networking client lib,<br>
&gt;&gt; &gt;&gt; needed when entering the real &#39;BaaS&#39; market, where our lib. is used<br>
&gt;&gt; &gt;&gt; against a (specific) &#39;backend provider&#39;.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Right, I was pretty much following the common BaaS pattern.  It&#39;s<br>
&gt;&gt; &gt; certainly not necessary immediately, but once we start supporting OAuth<br>
&gt;&gt; &gt; we&#39;ll want something like that anyway, so I put it in as a placeholder.<br>
&gt;&gt; &gt; Easy to remove if we decide we don&#39;t want it for now.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; * Utils.java<br>
&gt;&gt; &gt;&gt; - related to the API_key, I think the X-AeroGear-Client header needs<br>
&gt;&gt; &gt;&gt; to be defined/discussed - but IMO the AeroGear client lib should work<br>
&gt;&gt; &gt;&gt; also without such a key, when accessing a simple JAX-RS (read:<br>
&gt;&gt; &gt;&gt; RestEasy) service; Of course, when &#39;cloud provider&#39; start using our<br>
&gt;&gt; &gt;&gt; bits, something like API_KEY is a must.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; +1<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; - the &#39;delete&#39; is public; the others (e.g. post) not...<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; No semantic significance there.  Should probably all be package access,<br>
&gt;&gt; &gt; since AeroGear is the user-facing class.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; * Pipe.java<br>
&gt;&gt; &gt;&gt; - how to update an existing item?<br>
&gt;&gt; &gt;&gt; For instance in JS/iOS we use save which does an &#39;add&#39; if there is no<br>
&gt;&gt; &gt;&gt; _id_ or issues an &#39;update&#39; if the entity already exisits (e.g. has an<br>
&gt;&gt; &gt;&gt; _id_).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yep, will do that.  (although note that &quot;_id_&quot; or &quot;_id&quot; or whatever we<br>
&gt;&gt; &gt; use is another point of coupling ;) )<br>
&gt;&gt; I don&#39;t think it does. In JS, I have made it so that what ever name you<br>
&gt;&gt; use on the server to denote an &quot;id&quot;, you can tell the client lib what that<br>
&gt;&gt; name is. So whether the id field is named id or recordId, or blahblah, that<br>
&gt;&gt; is configurable when a pipe is created.<br>
&gt;<br>
&gt;<br>
&gt; Can you post a snippet for that?<br>
&gt;<br>
&gt; Not exactly sure what you want to see and iOS/Android are probably going to<br>
&gt; have to be different but hope this helps a little.<br>
&gt; <a href="https://gist.github.com/3729174" target="_blank">https://gist.github.com/3729174</a><br>
&gt;<br>
&gt;<br>
&gt; Thx,<br>
&gt; Matthias<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; There is no concept of a &#39;pipeline&#39;, but I guess (at least for now) on<br>
&gt;&gt; &gt;&gt; &quot;Java&quot; (aka Android) a typed list (e.g. List&lt;Pipe&gt; pipeline;) is good<br>
&gt;&gt; &gt;&gt; enough, right?<br>
&gt;&gt; &gt;&gt; But on the other hand, than it&#39;s up to the user of the api to &#39;manage&#39;<br>
&gt;&gt; &gt;&gt; all the pipes (server connections).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Right.  What sort of &quot;management&quot; do you imagine, other than<br>
&gt;&gt; &gt; factory-style creation?  Pipes as they stand are extremely &quot;cheap&quot;<br>
&gt;&gt; &gt; objects (no db connections, network connections, threads, etc).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Best,<br>
&gt;&gt; &gt; --Glen<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; ___Matthias Wessendorf<br>
<br>
blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
</blockquote></div></div><br><br>-- <br>Sent from Gmail Mobile<br>