So with GCM and Android, Google may decide to update the devices token.
The device will receive a Intent saying that the token has changed and
it needs to eventually update the remote server's data before the token
Right now the application checks the device id on startup and
reregisters if there is a change. If the user doesn't interact with the
applicaiton for a long period of time and the device token changes he
will eventually stop receiving messages.
Ideally, I would think that handling this as soon as the intent comes in
would be great. However, how should failures to reregister be handled?
My easy answer is Log and retry with exponential backoff (and maybe send
a error message).
trying to build the site (on mac), I am getting:
pluto:aerogear.org matzew$ bundle install --path vendor && bundle exec
jekyll serve --watch
Using RedCloth (4.2.9)
Using asciidoctor (0.1.4)
Using fast-stemmer (1.0.2)
Using classifier (1.3.3)
Using colorator (0.1)
Using highline (1.6.19)
Using commander (4.1.5)
Using directory_watcher (1.4.1)
Using liquid (2.5.2)
Using syntax (1.0.0)
Using maruku (0.6.1)
Using posix-spawn (0.3.6)
Using yajl-ruby (1.1.0)
Using pygments.rb (0.5.2)
Using redcarpet (2.3.0)
Using safe_yaml (0.7.1)
Using jekyll (1.2.1)
Using net-ssh (2.7.0)
Using net-sftp (2.1.2)
Using bundler (1.2.3)
Your bundle is complete! It was installed into ./vendor
Configuration file: /Users/matzew/TEMP/aerogear.org/_config.yml
Generating... You are missing a library required for Markdown. Please
$ [sudo] gem install kramdown
Conversion error: There was an error converting '_posts/
ERROR: YOUR SITE COULD NOT BE BUILT:
Missing dependency: kramdown
Yep, I did try the "[sudo] gem install kramdown" trick... not working.
ruby 1.9.3p327 (2012-11-10) [x86_64-darwin12.2.0]
Any thoughts/ideas ?
I was wondering what was the common/best practice when you want to
contribute (with commits) to an existing PR (assuming you have no commit
rights on the branch where the PR comes from) :
- Commits on the PR is only the responsability of the one who created it,
he has to report the fixes.
- The "fixer" forks the PR branch, fix it, close the old PR and resubmit a
- The "fixer" forks the PR branch, fix it and submit a PR to the branch
from the original PR (this way after the merge, the existing PR will be
- For big PRs where other team members are likely to submits commits make
sure to submit a PR from the aerogear repo ? (but this just counts for team
Thx for you input !
me again with another thing to share. On iOS, when the application is not in foreground, the system decides what to do with it. So I was thinking, that for Android, there might be some kind of example implementation of MessageHandler, that would behave similar to iOS.
It might use the "sound", "alert" and maybe even the "badge" properties.
I've made a ticket before, so more information can be found there:
I just wanted to do a quick write up of my experience at jQuery Conference Austin. Overall, the talk went really well. I gave a talk on SimplePush and the need to bring push notifications to the web. People really enjoyed my talk and demo which basically allowed the audience to open my slides on their computer or mobile device and see the slides transition in real time as I gave my talk.
I had a number of great questions but the one that came up a couple of times was security, both in terms of registration as well as sending notifications. Admittedly, this is lacking right now in our 0.8 release but I explained it is on our roadmap and will be added soon. I also had a couple of people tell me it was their favorite talk of the conference.
All of these reactions demonstrate to me that the community is much more interested in innovation and new offerings than they are having some competing offering from another company trying to keep up in the mobile space so let's make sure we continue the innovation spirit in our future work!
I would also like to send one more special thank you to Dan, Bruno and Doug for their help right up until the last minute making sure all of the services and servers I needed were running at peak performance. I couldn't have had such a successful talk without them!
According to yesterday's team meeting, we need to update our Grand RoadMap.
Things to note:
- We know the schedule will slip, because push - we just need to
- IMHO Security will need a little bit more room than the aggressive
6-week cycle - my shoot is 8-week minimum.
- What about the showcase app? Does it have more priority than the
- Offline/Sync: To do it together or not, that's the question!
Let's discuss this RoadMap during this week so we can just agree on the
outcome at our next team's meeting, **next monday**. I know timing is
tight but Jay needs this...
I've been thinking and got an idea that would improve consistency of the push messaging. Right now, Android and iOS are kind of consistent, so when you send a push message, they both receive the same data. But simplepush behaves differently. I know, it's because mozilla made it that way, but let me show you my idea.
Let's say we have this payload, that's gonna be send to all three platforms at the same time:
"postId" : "1234567890",
"title" : "Aerogear RULEZ!"
"simplepush" : "version=123"
This payload has 88 bytes, so even for APNS, the size of this message is not a problem (GCM even has limit of 4kB). And I've counted the simplepush field into that size (that would of course get removed from the final message).
As you can see, there is no change in the message format. There are several ways for declaring which messages should be saved and which not. It might be "variant-scoped" or "category-scoped" (making it category-scoped would mean there would have to be some category management). So let's say that we have it variant-scoped, meaning that when you create a Simplepush variant, you can decide if messages should be stored or not. If you want them stored, the unifiedpush server will store the payload under the version number (it will store only the latest payload for the version number) and the aerogear-js will then fetch the payload automatically and give it to your callback. That way, you wouldn't have to make your own web service and logic to pull the data.
In this example, we're talking about application that's made for browsing content of a website like the Verge, Engadget etc. The notification is then for notifying the user that a new post has been released. You could of course just send information that there is a new post and make the application pull it from the web. But that consumes additional battery and data for no reason. With this data, the post id and the title, you have enough to notify the user about new content and to be able to directly open your application and load desired post when the user wants to.
And I'm not making this up, this is a real use case. We've made an application , that does exactly this, but uses just the GCM. Now if I wanted to make it use aerogear unified push, it'll be easy transition. If we had an iOS application, it would behave the same (or just very, very similar). But if we've built Firefox OS application using the simplepush notifications, we'd have to make additional logic just to fetch the post id and title. And that makes the simplepush inconsistent with the Android and iOS messaging.
So to wrap it up,
* you register simplepush variant, setting "storePayloads" to true
* then you register a simplepush device for that variant, also with setting "fetchPayloads" to true
* you send your message as usual
** you'll receive the payload directly on iOS and Android
** in JS, aerogear-js will first make a request to unifiedpush server, to fetch the payload, which will then deliver into your callback
Let me be clear, that if you don't use the "storePayloads" and "fetchPayloads" (naming is temporary ofc), the simplepush would behave like it does now. If you'd use "storePayloads" but not "fetchPayloads", it would also behave like it does now, but the unifiedpush will store the payloads. Using "fetchPayloads" but not "storePayloads" would result into error on the JS client side.
So, what do you think? Also, if something is not clear, just ask.
PS: Some of you might say that push notifications are not meant to carry data. Well, the world is not always following the guidelines (also the GCM is made  to deliver data and APNS is somehow in between as it allows some data to be sent but not as much as GCM).
1 - https://play.google.com/store/apps/details?id=com.brainwashstudio.dotekom...
2 - http://developer.android.com/google/gcm/adv.html#payload