[aerogear-dev] iOS device registration AFTER application login

Wed Jul 17 14:52:05 EDT 2013

On Wed, Jul 17, 2013 at 8:29 PM, Yavuz Selim YILMAZ <yavuzsel at buffalo.edu>wrote:

>
>
> ---
> Yavuz Selim Yilmaz
> SUNY at Buffalo
> Computer Science and Engineering
> PhD Candidate
>
> On Jul 17, 2013, at 2:08 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Wed, Jul 17, 2013 at 7:58 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Wed, Jul 17, 2013 at 7:06 PM, Yavuz Selim YILMAZ <yavuzsel at buffalo.edu
>> > wrote:
>>
>>>
>>>
>>> ---
>>> Yavuz Selim Yilmaz
>>> SUNY at Buffalo
>>> Computer Science and Engineering
>>> PhD Candidate
>>>
>>> On Jul 17, 2013, at 11:53 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Wed, Jul 17, 2013 at 5:44 PM, Yavuz Selim YILMAZ <
>>> yavuzsel at buffalo.edu> wrote:
>>>
>>>>
>>>>
>>>> ---
>>>> Yavuz Selim Yilmaz
>>>> SUNY at Buffalo
>>>> Computer Science and Engineering
>>>> PhD Candidate
>>>>
>>>> On Jul 17, 2013, at 11:32 AM, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>>
>>>> On iOS we recommend doing the registration (with UP server) on the
>>>> "didRegisterForRemoteNotificationsWithDeviceToken" callback:
>>>>
>>>> https://github.com/aerogear/aerogear.org/blob/master/docs/guides/aerogear-push-ios/iOS-app.asciidoc
>>>>
>>>>
>>>> However, in AeroDoc-iOS, we just stash the token:
>>>> https://github.com/aerogear/aerogear-push-quickstart-ios/blob/master/ProDoctor/ProDoctor/AGAppDelegate.m#L49
>>>>
>>>>
>>>> And submit it, with the entire metadata, AFTER a successful login:
>>>> https://github.com/aerogear/aerogear-push-quickstart-ios/blob/master/ProDoctor/ProDoctor/Classes/Controllers/AGLoginViewController.m#L138
>>>>
>>>>
>>>> Is it guaranteed that device token is received BEFORE successful login?
>>>> What if registration with APNs fails?
>>>>
>>>
>>>
>>> a different APNs callback is invoked (*
>>> application:didFailToRegisterForRemoteNotificationsWithError)*
>>>
>>>
>>> Yes, but in that case, ProDoctor still registers the device to the Push
>>> EE server (with nil device token afaik). Is it an expected behavior?
>>>
>>
>> not really :-)
>> If APNs fails initially, there should be no registration with the
>> UnifiedPush Server. The metadata, without an APNs deviceToken (where it is
>> 'nil') is pretty much useless :-)
>>
>
> I filed a bug, based on your comment :)
>
>
> \o/
>
>
> https://issues.jboss.org/browse/AGIOS-43
>
> -Matthias
>
>
>
>>
>>
>>>
>>> And my 1st question refers to this scenario:
>>> Application successfully registered with APNs, but the delegate called
>>> AFTER the successful login (I was asking about the time guarantee of APNs
>>> registration),
>>>
>>
>> What delegate do you mean?
>> The "didRegisterForRemoteNotificationsWithDeviceToken" delegate is called
>> right away, regardless of what the first screen does (e.g. offering a login
>> screen).
>>
>
> Yes, I'm talking about "didRegisterForRemoteNotificationsWithDeviceToken"
> method. My question is, how much time are you referring with "right away"?
> Can there be some APNs delays (or something which delays this delegate
> call) which will cause Push EE device registration with nil device token
> (or no registration after bug fix)?
>

Perhaps, but most-likely only when your app (e.g. AeroDoc) is the FIRST app
on the iOS device that uses APNs.
After installing the first, there is a persistent connection to the APNs
server, when ever you have 3G/Data.

I *think* if there is NO connection (to 3G/Data), the callbacks are not
invoked

> Let me give a numerical example:
>
> t=0 app is launched
> t=10 user tapped login button with valid username and password
> t=11 user is logged in successfully
> t=11.x [self deviceRegistration]; is called (device token is nil)
>

no registration will happen:
https://github.com/aerogear/aerogear-push-ios-registration/blob/master/push-sdk/AGDeviceRegistration.m#L60

(Let me close the previous bug :-))

> t=11.x+n didRegisterForRemoteNotificationsWithDeviceToken is called
> (registered to APNs successfully and device token is stashed)
>
> In this case, device will not be successfully registered to Push EE as far
> as I could see.
>

nope, no registration at all :)

(also, if you kill and re-start the app a few times, a lot of
"registration" agains PushEE are performed, to "update" the metadata)

> But it should be registered as it is eventually registered to APNs
> successfully.
>
> And yes, usually didRegisterForRemoteNotificationsWithDeviceToken gets
> called so quickly (as I've experimented so far), but is it guaranteed?
>

what exactly is guaranteed?

> Or should AeroDoc (fka ProDoctor) handle such cases on its own?
>

the lib protects against 'nil' :-)

>
>
>
>>
>>> so in this case there exist no stashed device token at the time of the
>>> execution of the success block. In such a case, when the delegate called
>>> after successful APNs registration, device should still be registered to
>>> Push EE I think.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> Perhaps we could/should docment that somewhere as well ? E.g. in the
>>>> tutorial doc (e.g. since that is a common use-case), or just on the AeroDoc
>>>> code (with some comments) ?
>>>>
>>>>
>>>>
>>>> -Matthias
>>>>
>>>> --
>>>> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130717/cef82156/attachment-0001.html 