[aerogear-dev] [Java Sender] Message Fluent API / Builder / DSL ...
Corinne Krych
corinnekrych at gmail.com
Wed Jul 3 10:06:35 EDT 2013
+1 for builder i don't think for now we need to separate message content from signalling
As per whether we should support Object for message input that could be JSONnified. Those objects will have to be implement an interface/protocol.
Could be nice though
Corinne
On Jul 3, 2013, at 3:45 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
>
>
> On Wed, Jul 3, 2013 at 3:41 PM, Summers Pittman <supittma at redhat.com> wrote:
> On Wed 03 Jul 2013 09:15:24 AM EDT, Sebastien Blanc wrote:
> Speaking more about implementation details , do you think this is a
> good approach (don't like very much the code duplication between the
> builder and the object but like the result)
> http://javarevisited.blogspot.fr/2012/06/builder-design-pattern-in-java-example.html
> ?
> Just a script to generate the builder and constructor from the fields in the class. I wouldn't worry about code duplication (IN THIS ONE NARROW INSTANCE) too much.
> A groovy Script ?Sure ;)
>
>
> On Wed, Jul 3, 2013 at 10:10 AM, Sebastien Blanc <scm.blanc at gmail.com
> <mailto:scm.blanc at gmail.com>> wrote:
>
> Ok,
> Progress will be tracked here
> https://issues.jboss.org/browse/AGPUSH-135
>
>
> On Tue, Jul 2, 2013 at 6:14 PM, Matthias Wessendorf
> <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>
>
>
> On Tue, Jul 2, 2013 at 5:57 PM, Summers Pittman
> <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>
> On 07/02/2013 09:13 AM, Sebastien Blanc wrote:
> Hi Folks,
> As you know we have a Java Sender Library that can be
> used by any backend application that want to send
> messages to the Unified Message Push Server
> (https://github.com/aerogear/aerogear-unified-push-java-client).
> The format is quite open and flexible as
> Matthias described it here :
> https://gist.github.com/matzew/b21c1404cc093825f0fb
> We can divide the creation of a message in 2 main parts :
>
> - The "signalling" part : list of client identifiers /
> specific devices etc ...
> - The "core" message containing actually the information
> we want to push
>
> Both are passed as Map and are finally converted into JSON.
> Here an example of how a "core" message is build :
>
> |Map categories = new HashMap();
> categories.put("lead", "version="+leadVersion++);
> Map json = new HashMap();
> json.put("id", lead.getId());
> json.put("messageType", "pushed_lead");
> json.put("name", lead.getName());
> json.put("location", lead.getLocation());
> json.put("phone", lead.getPhoneNumber());
> json.put("simple-push", categories);
> json.put("sound" ,"default");
> json.put("alert" ,"A new lead has been created");|
>
> Even the format is open, we could "assist" a bit
> the developer in building the message. For that we have
> different options :
> - Propose a simple Message object containing the message
> "API" :
>
> |Message message = new Message();
> message.setClientIdentifiers("jake","maria");
> message.enableSound();//by default use "default" or we could do message.enableSound("boing")
> message.setAlert("Watch out!);
> message.setAttribute("customAttribute","yo"); // custom simple strings
> message.setAttribute("customStructure",myObject); // passing objects|
>
> - Propose a Message Builder (following the Builder
> Pattern) to propose a more fluent API :
>
> |Message message = new Message().builder()
> .clientIdentifiers("jake","maria")
> .enableSound()
> .alert("AAAAHHH!")
> .attribute("customAttribute","yo")
> .attribute("customStructure",myObject)
> .build()|
>
> - Same as above but more DSL focused (not sure about this
> one ;) )
> |Message message = MessageDSL.to("jake","maria").withSound() //etc ...
>
>
> |
>
> So, beside that we have to discuss what we want allow to
> pass to the message API : only Strings and simple Maps ?
> Full Objects that will be JSONified ?
> +1 to Strings and Simple Maps.
>
>
> +1 on that too.
>
> See here too :)
> http://developer.android.com/reference/com/google/android/gcm/server/Message.Builder.html#addData(java.lang.String,
> java.lang.String)
>
> JSONIfying full objects can be error prone/tricky
> sometimes so -.5 to that.
> I don't hate it would rather just not give people that gun
> to shoot themselves with so soon ;)
>
>
> I am for Strings and Simple Maps as well
>
>
>
> Do we want also to separate the "signalling" part from
> the "core" part when building a message ?
>
> Inputs and comments more than welcome !
> I like the Builder. It is very simple, very neutral, and
> very exact.
>
>
> Seb
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> <mailto: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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <mailto: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
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130703/4e30097c/attachment-0001.html
More information about the aerogear-dev
mailing list