[aerogear-dev] UPS: deviceType semantics

[Matthias Wessendorf]

On Wed, Nov 4, 2015 at 12:34 PM, Daniel Passos <dpassos at redhat.com> wrote:

>
>
> On Tue, Nov 3, 2015 at 5:57 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi Ron,
>>
>> thanks for the mail - let me try to bring some light into the dark
>>
>> On Mon, Nov 2, 2015 at 8:38 PM, Ron Smeral <rsmeral at redhat.com> wrote:
>>
>>> Hi all,
>>>
>>> I noticed the "deviceType" field in UPS seems to be used inconsistently
>>> between Server and the SDKs, and is perhaps underspecified.
>>>
>>> The docs only say this much:
>>> https://aerogear.org/docs/unifiedpush/client-registration/
>>> * "deviceType: The device type of the device or the user agent."
>>> - what does "device type of the device" mean? "Type" in what sense?
>>>
>>
>>
>> like here:
>>
>> https://github.com/aerogear/aerogear-push-ios-demo/blob/master/PushTest/AGAppDelegate.m#L82
>>
>> the iOS API read the type of the device (eg. iPod, iPad, iPhone) etc.
>>
>> It's stored on the server's metadata. Presented to the user, on the admin
>> UI, when browsing the registered devices for a Variant. Below is an example
>> from our users doc:
>>
>> https://aerogear.org/docs/unifiedpush/ups_userguide/index/#_importing_device_metadata
>>
>>
>>>
>>> https://aerogear.org/docs/unifiedpush/push-message-format/
>>> * "deviceType: A list of raw device types that should receive the
>>> message (e.g. Coupon only for iPad and AndroidTablets). The deviceType
>>> needs to be stored when the device is registering itself with the server."
>>> - what's a "raw device type"?
>>> - "needs to be stored" - who needs to do that? Store where?
>>>
>>
>> This API is to actually sent the message to the registered devices -
>> device type here is a filter.
>> Example: you have a generic iOS variant, and have a few iPods, a few
>> iPhone and a few iPads, this filter allows you to just sent messages to all
>> iPhones, by specifiying iphone.
>>
>>
>>
>>>
>>>
>>> When trying to use the Sender API, the obvious question is: what's the
>>> list of possible values? The docs don't answer that.
>>>
>>
>> here is our current version of the doc:
>>
>> https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/sender/index.html#POST
>>
>>
>> but we have a new online in a few days (after the 1.1.0.Finall is out)
>>
>>
>>>
>>> Another missing piece of information:
>>> * Is the deviceType an arbitrary string set by the user during
>>> registration?
>>>
>>
>> usually that's done by the application (develoiper), not the directly the
>> end user of the phone
>>
>>
>>> * Or, is it somehow automatically set by the client SDKs?
>>>
>>
>> yeah :-) but not enforced
>>
>>
>>>
>>> After a bit of digging through the SDKs and APIs, I can see this (not
>>> necessarily 100% correct):
>>>
>>> * The Sender API accepts arbitrary values
>>>
>>> * Android SDK - has deviceType in model, sets to "ANDROID" by default
>>> * Windows SDK - doesn't even have deviceType in model
>>> * iOS SDK - has deviceType in model, doesn't set to any default value
>>>
>>> * Cordova Android - doesn't set, so uses "ANDROID"
>>> * Cordova WP8 - not in model, not set
>>> * Cordova iOS - sets UIDevice.model (I can't really read ObjC, just a
>>> guess by looking at the code)
>>>
>>>
>>> Can we come up with clearer semantics for the deviceType field?
>>>
>>
>> Looks like on Windows it is missing - perhaps we should add that.
>> On Android, I agree the SDK should not set any default here - but I am
>> not sure if there is an equivalent API around like UIDevice, which would
>> the app developer allow to specifiy the actual device type.
>>
>
> You are right, we don't have API like UIDevice. To check if it's a tablet
> or a phone we need to check the screen size
>
> http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts
>

wow - sounds like an advanced API :-)


But serious... in that case... why not just leave the default to ANDROID,
as it is today. I see zero reason to really change that at all...

-M




>
>
>
>> Mind filing a few JIRAs against: AGDROID, AGWIN to get the functionality
>> baked into the native SDKs, and against AGCORDOVA to get this into there as
>> well, once the native bits are done.
>>
>> Great find, Ron!
>>
>>
>>>
>>> Thanks,
>>> Ron
>>>
>>> --
>>> Ron Smeral
>>> Technical Writer, FeedHenry
>>> Red Hat
>>> Brno
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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/20151104/240e102c/attachment.html