[aerogear-dev] Android keys (Re: AeroGear Push Message Format)
Matthias Wessendorf
matzew at apache.org
Tue Jun 18 15:00:09 EDT 2013
On Tue, Jun 18, 2013 at 5:25 PM, Summers Pittman <supittma at redhat.com>wrote:
> On 06/18/2013 10:55 AM, Matthias Wessendorf wrote:
>
>
>
>
> On Tue, Jun 18, 2013 at 4:50 PM, Summers Pittman <supittma at redhat.com>wrote:
>
>> On 06/18/2013 10:46 AM, Matthias Wessendorf wrote:
>>
>>
>>
>>
>> On Tue, Jun 18, 2013 at 4:42 PM, Daniel Passos <daniel at passos.me> wrote:
>>
>>> We don't have special words on Android, but we can use the same of iOS
>>> and shoot the same behaviors. wdyt?
>>>
>>
>> Like you did on the PR, for "alert", right ?
>>
>> I personally do like that very much
>>
>> So Android doesn't define any specific "keys".
>>
>
> awesome, even better.
>
> Forget what I was asking :)
>
>
>
>>
>> Are you asking for some generic "keys" which pushee and ag-android will
>> "natively" support?
>>
>
>
> I like what you guys did for "alert", on Android :) That would be
> cool, I think :)
>
>
> https://github.com/danielpassos/aerogear-android/blob/push/src/org/jboss/aerogear/android/unifiedpush/AGPushMessageReceiver.java#L46
>
> Ahhh. We moved that out to an interface the user can implement :)
>
Like a "message handler" ? any chance to post the branch/gist or so for
that ? Very interested :)
>
>
>
>>
>>
>>
>>>
>>> On Tue, Jun 18, 2013 at 9:15 AM, Matthias Wessendorf <matzew at apache.org>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
>>>>
>>>>
>>>> -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?
>>>>>>>>>
>>>>>>>>>
>>> _______________________________________________
>>> 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 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
>
>
> _______________________________________________
> 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/b802c83e/attachment-0001.html
More information about the aerogear-dev
mailing list