[aerogear-dev] Android keys (Re: AeroGear Push Message Format)

Tue Jun 18 10:45:43 EDT 2013

On Tue, Jun 18, 2013 at 3:34 PM, Summers Pittman <supittma at redhat.com>wrote:

>  On 06/18/2013 08:15 AM, Matthias Wessendorf wrote:
>
> Summers, Passos,
>
>
>  wondering if we should/could honor "android" specific keys as well
> (similar to the iOS keys that we "honor")
>
>  See:
>
> https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-push-messages/index.markdown#ios-special-keys
>
>   Well the Google provided libraries are rather open ended.  I'm not
> saying we shouldn't have android specific keys, I'm just wondering what
> keys we want to support.
>

so... since pushEE is just "dispatching" the keys... it's already there....

Let's imagine there is a "special key", which has some "special" meaning by
the Android-OS (e.g. like alert on iOS).
Let's name the key "google-magic". If "google-magic" has some value that
makes sense..... it would be straight submitted, from PushEE, to the GCM.

The Android lib would receive it. And perhaps google does some
introspection and read the value of the "google-magic" key....

That's how it works on iOS. if the PushEE receives "alert", it jist
dispatches it to APNs, and Apple does the work.

I guess, this would work with some Android "speciofic keys" as well

>
>
>  -Matthias
>
>
> On Thu, Jun 13, 2013 at 5:36 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>> reminder, that ID is just the primary key :-)
>>
>>  meaningful are "pushApplicationID" and "variantID"
>>
>>
>> On Tue, Jun 4, 2013 at 3:17 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>> Luke
>>>
>>>  once this landed, it will be "pushApplicationID" and "variantID" - the
>>> ID is than meaningless (at least for PushEE server).
>>>
>>>  -M
>>>
>>>
>>> On Fri, May 31, 2013 at 6:45 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>>>
>>>> plus plus
>>>>
>>>>  On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>>
>>>>  https://issues.jboss.org/browse/AGPUSH-86
>>>>
>>>>
>>>>  On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui at redhat.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew at apache.org>
>>>>> wrote:
>>>>>
>>>>>  somehow the device needs to say: "I belong to android variant"
>>>>>
>>>>>  besides the @Id /PK, we can have a second field / column that
>>>>> represents:
>>>>> * PushAppID
>>>>> * VariantID
>>>>>
>>>>>   Yup. Having these would solve that
>>>>>
>>>>>
>>>>>
>>>>>  Was that your question?
>>>>>
>>>>> On Friday, May 31, 2013, Lucas Holmquist wrote:
>>>>>
>>>>>> something that i was thinking about after doing some examples is that
>>>>>> i'm not sure how i feel about using the PK's of each table as the
>>>>>> identifier to register/broadcast clients.
>>>>>>
>>>>>>  We are sort of giving meaning to data that really shouldn't have
>>>>>> meaning.  it should really only be used to identify the row.  It might be
>>>>>> better to have another key on each table/object that is the identifier.
>>>>>>
>>>>>>  So in one of the examples i did,  the app on the device will
>>>>>> register the device with the push server,  but i needed to also include the
>>>>>> id of the variant instance
>>>>>>
>>>>>>  i guess i'm thinking if someone migrates their database,  these
>>>>>> keys could get messed up.
>>>>>>
>>>>>>
>>>>>>  wdyt?
>>>>>>
>>>>>>
>>>>>>  On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew at apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <
>>>>>> corinnekrych at gmail.com> wrote:
>>>>>>
>>>>>> in selective push is:
>>>>>> ==> variant: iOS  + alias: mwessendorf
>>>>>>  a valid criteria too?
>>>>>>
>>>>>>
>>>>>>
>>>>>>  yes. let me update the related doc(s)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 28 May 2013 08:51, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On 28 May 2013 08:48, Matthias Wessendorf <matzew at apache.org> wrote:
>>>>>>
>>>>>> TYPO:
>>>>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant)
>>>>>> + deviceType:iPadMini  + alias: mwessendorf
>>>>>>  or
>>>>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant)
>>>>>> + deviceType:iPhone  + alias: mwessendorf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <
>>>>>> matzew at apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <
>>>>>> corinnekrych at gmail.com> wrote:
>>>>>>
>>>>>> When doing selective push query, is there any overlap between mobile
>>>>>> variant (which I understand like mobile type which contains certificates)
>>>>>> and device type?
>>>>>>
>>>>>>
>>>>>>  MobileVariant (or call it type) is something like "Android", or
>>>>>> "iOS".
>>>>>> deviceTypes would be iPad, iPod, iPhone, iWatch :)  - or "Android
>>>>>> Table", "Andrpid phone", android what not
>>>>>>
>>>>>>
>>>>>>  Sure.... ideally there are several variants:
>>>>>>  - iOS iPhone 5 optimised app in the app store
>>>>>>  - iOS iPhone 4s optimised app in the app store
>>>>>>  - iOS iPhone 3 optimised app in the app store
>>>>>> - iOS iPad mini optimised app in the app store
>>>>>> etc :)
>>>>>>
>>>>>>  But, if there is only one variant, it's totally valid to install an
>>>>>> iOS application (from the appstore), on an iPad and an iPhone;
>>>>>>
>>>>>>
>>>>>>  Both aimed at defining categories.
>>>>>>  Are those categories defined and fixed in the spec or can they be
>>>>>> extended?
>>>>>>
>>>>>>
>>>>>>
>>>>>>  I don't understand categories, here
>>>>>>
>>>>>>
>>>>>> Can we do a selective push based on mobileType=mobile variant and
>>>>>> alias=john at gmail?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>>  _______________________________________________
>>>>>
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130618/8fbb21d4/attachment-0001.html 