Here is the REST API for "Push App" (+mobile app) registrations:
https://gist.github.com/matzew/2da6fc349a4aaf629bce
Questions:
The post to "/applications/das231432qwdsa2/iOS" and/or
"/applications/das231432qwdsa2/android" are different (payload-wise)....
Not sure if that is best solution.... However, we need to differentiate
between different "mobile os variants" anyways....
My (CURRENT) feelings is that a different "endpoint" is better instead of
an ugly, large - but generic - API that does everything, and the server
figures out what type of mobile app has been registered ...
NEXT: Device Registrations + Sender Endpoints
(Followed by "management" (get, put, delete.....)
Greetings,
Matthias
On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Hello,
here is the 'overview' section of the Unified push....:
AeroGear Unified Push (DRAFT 0.0.2)
This is an *early* version of a 'spec' for the AeroGear Unified Push
server.
<
https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview>Overview
The *Unified Push* solution contains the following components:
- Native Push Component: *sends native push message to registered apps*
- Web Push Component: *sends web push message to online client (e.g.
WebSocket/SockJS clients)*
- Client SDK API
- Native Push Client for iOS
- Native Push Client for Android
- Web Push Client for JavaScript
Details are discussed on the each of the different components
NOTE: LINK need to be enabled :) :)
HOWEVER.......
Here is what I'd like to add to the home page for the native push
component - based on last weeks discussion:
https://gist.github.com/matzew/69d33a18d4fac9fdedd4
PLEASE comment on the gist....
--
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