On Mon, Nov 5, 2012 at 4:35 PM, Summers Pittman <supittma(a)redhat.com> wrote:
>Do google has plans to phase out GSON? If not what would we
benefit from
abstracting this?
Google should be keeping this around for a while. Their project page is
getting regular activity.
If we abstract it away then we can make our serialization format
different. (Who knows, someone may want to use SOAP instead of rest)
But for 1.0 I think exposing an option constructor parameter/builder
method/config option which takes a GsonBuilder is the way to go.
>For me it looks like the way to go on JSON for android.
+1
----- Original Message -----
From: "Douglas Campos" <qmx(a)qmx.me>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Monday, November 5, 2012 10:27:27 AM
Subject: Re: [aerogear-dev] JSON Serialization in Android
On Nov 5, 2012, at 10:13 AM, Marko Strukelj wrote:
>
> On Fri, Nov 2, 2012 at 3:51 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
> Right now we have JSON serialization in Android implemented by a default
configuration GSON instance.
>
> I am updating the docs to note this, however it is "only" an
implementation detail.
>
> 1) Do we want to say for 1.x that GSON IS the library we are using?
(Yes)
> +1
>
> 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)
> Yes, I think we should provide pluggability. Maybe even for 1.0 as it
seems fairly easy.
>
> This would cover our current serialization needs:
>
> public interface Marshaller<T> {
> void String marshal(T obj) throws IOException;
> void List<T> unmarshal(String json) throws IOException;
> }
>
> With Builder pattern you could specify Marshaller at Pipe creation time
i.e.:
>
> new Pipe.Builder().useMarshaller(Pipe.DEFAULT_MARSHALLER)
> .name("tasks")
> .useClass(Task.class).build().
>
> Where Pipe.DEFAULT_MARSHALLER ==
"org.aerogear.android.serialization.impl.GSONMarshaller";
>
> User has no compile-time dependency on impl detail, and has the ability
to plug in something of her own.
>
> (I noticed Builder vs. Configuration object debate. Will comment more
there.)
>
>
> 2.1) How much do we want to expose/allow to be configured? (No idea)
>
>
> The above pattern doesn't account for any configuration. System
properties could be used (ugly). But it can be changed - use
MarshallerFactory object instead of Marshaller class name:
>
> public interface MarshallerFactory {
>
> Marshaller newMarshaller();
> }
>
> new Pipe.Builder().useMarshallerFactory(new
org.aerogear.android.serialization.GSONMarshallerFactory())
> .name("tasks")
> .build();
>
> 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.
>
>
> I think pluggability would be really good to have for version 1.0
already. As it influences the builder / factory patterns. It'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.
>
> Besides Serialization one aspect of pluggability could be Transport i.e.
plug in HttpURLConnection instead of HttpClient.
>
>
> - marko
>
>
> Relevant
Jira:https://issues.jboss.org/browse/AEROGEAR-596
>
> Summers
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev