<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 5, 2012 at 4:35 PM, Summers Pittman <span dir="ltr">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">&gt;Do google has plans to phase out GSON? If not what would we benefit from abstracting this?<br>
</div>Google should be keeping this around for a while.  Their project page is getting regular activity.<br>
<br>
If we abstract it away then we can make our serialization format different. (Who knows, someone may want to use SOAP instead of rest)<br>
<br></blockquote><div><br></div><div>Yes, all that. </div><div><br></div><div>- marko</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But for 1.0 I think exposing an option constructor parameter/builder method/config option which takes a GsonBuilder is the way to go.<br>
<div class="im"><br>
<br>
&gt;For me it looks like the way to go on JSON for android.<br>
</div>+1<br>
<div class="HOEnZb"><div class="h5">----- Original Message -----<br>
From: &quot;Douglas Campos&quot; &lt;<a href="mailto:qmx@qmx.me">qmx@qmx.me</a>&gt;<br>
To: &quot;AeroGear Developer Mailing List&quot; &lt;<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>&gt;<br>
Sent: Monday, November 5, 2012 10:27:27 AM<br>
Subject: Re: [aerogear-dev] JSON Serialization in Android<br>
<br>
<br>
<br>
<br>
<br>
On Nov 5, 2012, at 10:13 AM, Marko Strukelj wrote:<br>
<br>
&gt;<br>
&gt; On Fri, Nov 2, 2012 at 3:51 PM, Summers Pittman &lt;<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>&gt; wrote:<br>
&gt; Right now we have JSON serialization in Android implemented by a default configuration GSON instance.<br>
&gt;<br>
&gt; I am updating the docs to note this, however it is &quot;only&quot; an implementation detail.<br>
&gt;<br>
&gt; 1) Do we want to say for 1.x that GSON IS the library we are using?  (Yes)<br>
&gt; +1<br>
&gt;<br>
&gt; 2) Do we want to provide a configuration point for Serialization (GSON if yes to 1, something more general if No)? (Yes, but not for 1.0)<br>
&gt; Yes, I think we should provide pluggability. Maybe even for 1.0 as it seems fairly easy.<br>
&gt;<br>
&gt; This would cover our current serialization needs:<br>
&gt;<br>
&gt; public interface Marshaller&lt;T&gt; {<br>
&gt;    void String marshal(T obj) throws IOException;<br>
&gt;    void List&lt;T&gt; unmarshal(String json) throws IOException;<br>
&gt; }<br>
&gt;<br>
&gt; With Builder pattern you could specify Marshaller at Pipe creation time i.e.:<br>
&gt;<br>
&gt; new Pipe.Builder().useMarshaller(Pipe.DEFAULT_MARSHALLER)<br>
&gt;     .name(&quot;tasks&quot;)<br>
&gt;     .useClass(Task.class).build().<br>
&gt;<br>
&gt; Where Pipe.DEFAULT_MARSHALLER == &quot;org.aerogear.android.serialization.impl.GSONMarshaller&quot;;<br>
&gt;<br>
&gt; User has no compile-time dependency on impl detail, and has the ability to plug in something of her own.<br>
&gt;<br>
&gt; (I noticed Builder vs. Configuration object debate. Will comment more there.)<br>
&gt;<br>
&gt;<br>
&gt; 2.1) How much do we want to expose/allow to be configured? (No idea)<br>
&gt;<br>
&gt;<br>
&gt; The above pattern doesn&#39;t account for any configuration. System properties could be used (ugly). But it can be changed - use MarshallerFactory object instead of Marshaller class name:<br>
&gt;<br>
&gt; public interface MarshallerFactory {<br>
&gt;<br>
&gt;    Marshaller newMarshaller();<br>
&gt; }<br>
&gt;<br>
&gt; new Pipe.Builder().useMarshallerFactory(new org.aerogear.android.serialization.GSONMarshallerFactory())<br>
&gt;     .name(&quot;tasks&quot;)<br>
&gt;     .build();<br>
&gt;<br>
&gt; This time GSONMarshallerFactory is part of an API. And user can create any implementation of MarshallerFactory and use it to create and configure a custom Marshaller.<br>
&gt;<br>
&gt;<br>
&gt; I think pluggability would be really good to have for version 1.0 already. As it influences the builder / factory patterns. It&#39;s the only way to make sure the patterns we use really are pluggable otherwise we may very quickly have to deprecate some of 1.0 API.<br>

&gt;<br>
&gt; Besides Serialization one aspect of pluggability could be Transport i.e. plug in HttpURLConnection instead of HttpClient.<br>
&gt;<br>
&gt;<br>
&gt; - marko<br>
&gt;<br>
&gt;<br>
&gt; Relevant Jira:<a href="https://issues.jboss.org/browse/AEROGEAR-596" target="_blank">https://issues.jboss.org/browse/AEROGEAR-596</a><br>
&gt;<br>
&gt; Summers<br>
&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
-- qmx<br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div>