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

[Sebastien Blanc]

https://issues.jboss.org/browse/AGPUSH-135


On Thu, Jul 11, 2013 at 7:37 AM, Matthias Wessendorf <matzew at apache.org>wrote:

> Do we have a JIRA for the "fluent API" refactorings ?
>
>
> On Tue, Jul 9, 2013 at 10:46 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>> Sure !
>> Thanks for the updates I will for sure add this to the builder API
>>
>>
>> On Tue, Jul 9, 2013 at 10:17 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>> Besides "alias", it is also possible to "filter" based on "deviceType".
>>>
>>> For the fluent API, I think something like ".deviceTypes(varargs)" is
>>> needed as well
>>>
>>> -Matthias
>>>
>>>
>>>
>>>
>>> On Tue, Jul 2, 2013 at 4:34 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 2, 2013 at 3:13 PM, Sebastien Blanc <scm.blanc at gmail.com>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
>>>>>
>>>>
>>>>
>>>> the real doc is located here:
>>>> http://staging.aerogear.org/docs/specs/aerogear-push-messages/
>>>>
>>>>
>>>>
>>>>>
>>>>> 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()
>>>>>
>>>>>
>>>>>
>>>>
>>>> I like the builder!  +1
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> - Same as above but more DSL focused (not sure about this one ;) )
>>>>>
>>>>> Message message = MessageDSL.to("jake","maria").withSound() //etc ...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> +0.5
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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 ?
>>>>>
>>>>> Do we want also to separate the "signalling" part from the "core" part
>>>>> when building a message ?
>>>>>
>>>>
>>>> I think that would be good, without too much thinking about it.
>>>>
>>>> * MessageBuilder -> builds message
>>>> * "signalling" part, on it's own (Filter + FilterBuilder (LOL))
>>>>
>>>> and both parts are combined into the actual "payload" object, to be
>>>> send out.
>>>>
>>>> However.... that can make the bits unnecessary complicated....
>>>> After writing the above lines, why not starting with a
>>>> Message/MessageBuilder. If separation is needed later, we can always do it
>>>> later.
>>>>
>>>> Greetings,
>>>> Matthias
>>>>
>>>>
>>>>
>>>>>
>>>>> Inputs and comments more than welcome !
>>>>>
>>>>> Seb
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>> 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
>>
>
>
>
> --
> 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
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130711/ab7f9ced/attachment-0001.html