+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(a)gmail.com> wrote:
On Wed, Jul 3, 2013 at 3:41 PM, Summers Pittman <supittma(a)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-e...
?
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(a)gmail.com
<mailto:scm.blanc@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(a)apache.org <mailto:matzew@apache.org>> wrote:
On Tue, Jul 2, 2013 at 5:57 PM, Summers Pittman
<supittma(a)redhat.com <mailto:supittma@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/Mess...,
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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@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(a)lists.jboss.org <mailto:aerogear-dev@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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev