[aerogear-dev] [AG Push] BASIC (and INITAL) use cases of the Unified Push Server

[Matthias Wessendorf]

here is, including device registration:

https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81

All hammered in java... since this is a test - most of the code will be
executed, when interacting with HTTP endpoints of the thing;

Yes, there is no JS application in the test - but we do have an abstraction
interface for it:
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/org/jboss/aerogear/push/application/ConnectedJavaScriptApplication.java

Connected? Since only "online" JS clients are receiving message - there no
real "push to device" for the JS world...

-Matthias

On Thu, Mar 14, 2013 at 3:41 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> Pushed FIRST/TEST impl + actually test case.....
>
> https://github.com/matzew/ag-unified-push-api
>
> YEs.... I have 'xxx'd out the KEY and certs :)
>
>
> On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>> My UNIT test looks (currently) like:
>>
>> https://gist.github.com/matzew/3d7f9915afd8f6705da5
>>
>>
>>
>> -M
>>
>>
>>
>>
>> On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j at gmail.com <tech4j at gmail.com>wrote:
>>>
>>>> I think this is look really good!
>>>>
>>>> Here some thoughts, and/or possible additional use-cases
>>>>
>>>> * How do we want to handle multiple devices for one user?
>>>>
>>>
>>> Instance of 'MobileApplicationInstance'; each device has (per app) a
>>> different token;
>>> What the apps do themselves, with multiple installs is something
>>> different.
>>>
>>> Twitter, for instance, sends the push-messages to EVERY device - but
>>> that's app specific sync
>>> (yes, i wish there was something like IMAP, for twitter)
>>>
>>>
>>>
>>>>
>>>> * How do we want to handle the other side of unified push (non-native)?
>>>> ** Might just not be there yet, but want to make sure we're still
>>>> thinking the same thing :-)
>>>> ** Would there be an additional abstraction above this for that?
>>>>
>>>
>>> some sub type of 'MobileApplication' can/will cover that "mobile web"
>>> (JS client) side:
>>>
>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/org/jboss/aerogear/push/application/MobileApplication.java#L23
>>>
>>>
>>>>
>>>> * I'm assuming there is no good way for apps to notify you when they
>>>> are uninstalled?
>>>> ** As a way of removing clutter in our tables.
>>>>
>>>
>>> In apple land these are invalid tokens (see
>>> https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoop/apns/ApnsService.java#L161
>>> )
>>> So, on a scheduled base they can be remove;
>>>
>>> Google has similar API (on their MulticastResult (returned by the
>>> sender))
>>>
>>>
>>>>
>>>> * Push filtering - I would think IDM would be very good here.
>>>> ** Sending to roles, groups, etc...
>>>>
>>>
>>> have different users (==roles), but not spec'd out
>>>
>>>
>>>> ** When we store the device and app info what sub-system are you
>>>> thinking?
>>>> *** I know you were using mongo for some of the prototyping
>>>> *** Would be possible to abstract to the IDM?
>>>>
>>>
>>> yes, it should be possible (desirable) to use IDM - but does not really
>>> matter
>>>
>>>
>>> Thanks for the feedback!!!
>>>
>>> -Matthias
>>>
>>>
>>>
>>>>
>>>> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx at qmx.me> wrote:
>>>>
>>>>>
>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew at apache.org>
>>>>> wrote:
>>>>>
>>>>> > ome more APIs, for some basic (initial) functionality:
>>>>> >
>>>>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1
>>>>>
>>>>> I like the current form, but I'm sure we'll get asked about more
>>>>> OO(ish) APIs, like device.send(Message) - is this on the plans?
>>>>>
>>>>> > User/Dev enrollment can be addressed by (hopefully) reusing the
>>>>> ag-security.
>>>>>
>>>>> +1
>>>>>
>>>>> -- qmx
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> blog: http://in.relation.to/Bloggers/Jay
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at 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
>>>
>>
>>
>>
>> --
>> 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130314/d4cd7871/attachment.html