gistfile1.md

Push once, send anywhere

One of the many challenges developers face when building mobile applications for a business backend, is notification messaging and handling. Each mobile platform offers its own proprietary notification mechanism, such as Apple's Push Notification Service (APNS), Mozilla SimplePush and Google's Cloud Messaging platform (GCM). We can realize that there is a need for a 'Unified' Push mechanism that will integrate all these mechanisms under a single entry point, offer valuable services on top such as selective sends and broadcasts and be flexible enough so it can be easily integrated in any business backend.

Come and join us, we will show you in action how AeroGear's Unified Push Project can help to 'Push' enabled your backend across discrete mobile platforms (and have fun in between!)

Notifications all over the place

Push notifications are a key feature for mobile app, allowing you to quickly reach your mobile users sending targeted information. Whether your app is running in the background or inactive, notifications can be triggered as a message, sound or badge. It sounds like the holy grail of advertising, doesn't it? But don't get lot, which notification type is best fit for your business? Local notification, scheduled messages on same iOS device. Remote notification for a world wide audience, with some pre-requisites (registered device, granted access). Or the latest Bluetooth Smart technology with iBeacon tiny transmitters which can send push notifications within close proximity. Ready to build up our retailer’s app?

Let's practise OAuth2 dance !

You want to build a cool iOS app to share your photos on Twitter, Google+, Facebook... Tackle all the 'cool' social networks. First thing you need to do is: authenticate and authorize your app for each provider. Good news is: there is a common protocol for that. Its little name is 'OAuth2'. Each provider comes with an iOS sdk to ease the OAuth2 dance, but of course, each has its own API. Ouch! And what you really want is use the same API for all them. Let's see how you can implement OAuth2 protocol and provide a common API across providers. Much easier than his elder brother OAuth, we will dive into OAuth2 protocol and see the challenges of implementing it from a native app perspective.

some typos:
s/graal/grail
s/retailler’s/retailer’s
s/providers/provider

Also, not sure what does this sentence mean, possible rephrase -> "are declined in different flavours"

overall looks good!

Ahoy Corinne, here comes my 2 cents of constructive feedback.

• Push once, send anywhere

I would remove the references to "business backends", people run away when they think about enterprise. At least in Brazil people think that you're trying to sell something
Also, I would remove the word "AeroGear", let them discover how you do the Push. If you present the name of the project and they might associate it with selling products. and drop the talk.

• Notifications all over the place
  The description looks really great, I would just remove any association to business for the same reasons described below and the sentence "Ready to build up our retailer’s app?". People don't go to your presentation to make money, but to learn something.
• Let's practise OAuth2 dance !

I think most of the iOS developers already know that it comes with iOS SDK, to it might be obvious for them. 2 questions must be answered into your description:

• Why do people need OAuth2?
• Why should I pick your API for it?

I hope it helps

Thanks abstractj
I'll take your comments and produce a new set of abstract
For the last presentation on Oauth2 i think i will add a comparison sth inspired by my blog post here http://corinnekrych.blogspot.fr/2014/06/different-ways-to-manage-facebook.html where i compare the pro and cons of different way of accessing Oauth2 in ios