[aerogear-dev] [Java Sender] Message Fluent API / Builder / DSL ...

Sebastien Blanc scm.blanc at gmail.com
Wed Jul 3 09:45:25 EDT 2013


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<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<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 <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<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<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 <aerogear-dev at lists.jboss.org>>
>>>             https://lists.jboss.org/**mailman/listinfo/aerogear-dev<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<aerogear-dev at lists.jboss.org>
>> >
>>
>>             https://lists.jboss.org/**mailman/listinfo/aerogear-dev<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>>
>>
>>
>>
>>         --
>>         Matthias Wessendorf
>>
>>         blog: http://matthiaswessendorf.**wordpress.com/<http://matthiaswessendorf.wordpress.com/>
>>         sessions: http://www.slideshare.net/**mwessendorf<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 <aerogear-dev at lists.jboss.org>>
>>
>>         https://lists.jboss.org/**mailman/listinfo/aerogear-dev<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<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/101aa616/attachment-0001.html 


More information about the aerogear-dev mailing list