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

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(a)apache.org&gt;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(a)redhat.com&gt;wrote: > >> plus plus >> >> On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> https://issues.jboss.org/browse/AGPUSH-86 >> >> >> On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com&gt;wrote: >> >>> >>> >>> Sent from my iPhone >>> >>> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> 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(a)apache.org&gt; >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)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(a)gmail.com&gt; wrote: >>>> >>>> >>>> >>>> >>>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org&gt; 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(a)apache.org&gt; wrote: >>>> >>>> >>>> >>>> >>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych < >>>> corinnekrych(a)gmail.com&gt; 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@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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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