On Mon, Apr 7, 2014 at 3:50 PM, Michi Oshima <michi.oshima@gmail.com> wrote:
Hi.  Thank you all.  I successfully got multiple registration working last week.  

  1. Sebastien, what is the purpose of using the local storage to store the mapping between channel ID and category?  I'm at this time keeping the map in memory.
  2. Matthias, using the current time makes sense.  I'll do that.  Why didn't I think about that?
eventually, the Mozilla guys figured that out as well.
The newest/latest spec (of SimplePush) contains that now: no body; server will use the current timestamp;

Note: our SPS server is being updated to do that too - we will do the same for UPS and our java client

 

Thank you all again for your attention and advice thus far.

Michi


On Fri, Apr 4, 2014 at 5:13 AM, Matthias Wessendorf <matzew@apache.org> wrote:
Hello Michi,

IMO the version number string is a bit odd for most backend applications. :-) If you don't want to maintain a "version per channel", I'd just do the current timestamp (e.g. Date.now() in JS)

-M


On Fri, Apr 4, 2014 at 11:04 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
Hey Again ! 

To make it even easier I've deployed a "multi-channel" version of the quickstart here  : http://mutlichannels-sblanc.rhcloud.com/
Then you can fire the CURLs for each category to see how it can handle different channels : 

curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{


       "categories" :["mail"],
       "simple-push": "version=1111"




curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{

       "categories" :["news"],
       "simple-push": "version=1112"







If you fire these multiple time don't forget to change the version value !





On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
Hey Michi,
I realized that the code I pointed you to could be a bit confusing and also contains a small bug.

I wrote this gist based on the quickstart example. Basically we register to 2 channels : mail and news, we store the channelID and map that with a String containing the service name, then in the onNotification we check which service to call : 


Hope this example will make more sense ! 

Seb




On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
Looks at this more advanced example here https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js 

You will see that we register 2 times and we get 2 different endpoints. Then you have to keep somewhere a link between your endpoint and let's say the service you want to associate to , like using the localStorage : localStorage.setItem(theEndpoint, "scoreService"); 

Then when you receive a message, besides the version (which is btw not mandatory to be used) you also receive the channelId, then you can choose which service to call : 


 navigator.setMessageHandler("push", function(message) {







		var myService = localStorage.get(message.channelID);


		//now based on this you can call your specific log
	});







I Hope this will help you.




On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima <michi.oshima@gmail.com> wrote:
Thank you, Sebastien.  I'll try multiple registration.  Although, I'm a bit confused.  Because:

  1. As far as I can see from the quick start example, per SPS Client, there'll be one registration with the SimplePush server.  That means I only get one endpoint.
  2. So I'd use the same endpoint to register multiple times with the unified push server using different category each time.
  3. When the SPS client receives a version number, how can it associate a given version number to a particular category?  (I've not seen categories reaching the client.)

Am I wrong somewhere above?  



On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima <michi.oshima@gmail.com> wrote:
Hi Lucas,

Following might do what I want (sending a "door bell" message in one shot to all variants)?  Send a unified message like the following one:

  • '{ "message": { "version":"123" }, "simple-push": "version=123" }'

One slight deviation is that mobile variants like iOS and Android will get the message regardless of whether the the version number is "old" or not.  Is this correct?
 
Yes iOS/Android ignore the version since that is really something tied to Simple Push 

So I revisited the SimplePush spec, and I noticed it describes support for subscription to multiple channels.  

Aerogear doesn't allow multiple channels per installation, correct?  I dug up an old post from Matthias:

Well yes,  but multiple installations can belong to the same SPS Client. You can register multiple time, differentiate them by passing them a category for instance.
 


If an installation can subscribe to multiple channels, then it would allow me to get what I originally asked about:

Me: 'My client application (javascript on browser) holds multiple types of data.  It would be nice if I can send a notification saying "there's an update for this data type", rather than just "there's an update".  Or, in general it'd be nice if I can send more information than just a monotonically increasing number. '

What do you think?

That would be quite a breaking change and we need to discuss that, in the same time, as said before, you can still register a single client to multiple channels (and es you will have multiple installations but that do not really matter) 
 



On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist <lholmqui@redhat.com> wrote:
On Apr 2, 2014, at 11:38 AM, Michi Oshima <michi.oshima@gmail.com> wrote:

Thanks, Lucas.  I read the spec yesterday and ended up looking at disturbing auctions for 30 minutes.  I'll read it again.

Another question, is there a way to send a "door bell" message *in one shot* to all iOS, Android, and SimplePush variants?

well, iOS and Android notifications aren't really doorbells,  but you can send a "message" to all clients that are registered in your Push Server.

we have a Java client 

and a node.js client  for this




(m:)


On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist <lholmqui@redhat.com> wrote:
SimplePush works only as a "door bell" to tell your app,  hey,  you should go look on your server.



On Apr 2, 2014, at 11:02 AM, Michi Oshima <michi.oshima@gmail.com> wrote:

Hi,

Yesterday I managed to send my first message to a browser.  Thanks for all your help.

I've tried sending a few different types of messages, and it so far appears to me the only thing I can send to a simple push client is a version number.  Can a simple push client receive anything else other than version numbers?  If so, what does the sender need to do, and what does the client need to do?  (If there is a good example somewhere online I can work from that also.)

My client application (javascript on browser) holds multiple types of data.  It would be nice if I can send a notification saying "there's an update for this data type", rather than just "there's an update".  Or, in general it'd be nice if I can send more information than just a monotonically increasing number. 

Here's my setup:

  • AeroGear Push Server 0.10.0 hosted on OpenShift.
  • Sender is a JBoss app using org.jboss.aerogear.unifiedpush.JavaSender (unifiedpush-java-client-0.5.0.jar).
  • Client is a web browser using aerogear.js 1.4.0.

I read this documentation, but my wishful thinking refused to interpret it as saying: SimplePush variants use the "extra simple-push object" only.

Thank you,

Michi Oshima

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev




_______________________________________________
aerogear-dev mailing list
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
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