Re: [aerogear-dev] iOS device registration AFTER application login

--- Yavuz Selim Yilmaz SUNY at Buffalo Computer Science and Engineering PhD Candidate On Jul 17, 2013, at 2:52 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Wed, Jul 17, 2013 at 8:29 PM, Yavuz Selim YILMAZ <yavuzsel(a)buffalo.edu&gt;wrote: > > > --- > Yavuz Selim Yilmaz > SUNY at Buffalo > Computer Science and Engineering > PhD Candidate > > On Jul 17, 2013, at 2:08 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Wed, Jul 17, 2013 at 7:58 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> >> >> >> On Wed, Jul 17, 2013 at 7:06 PM, Yavuz Selim YILMAZ < >> yavuzsel(a)buffalo.edu&gt; wrote: >> >>> >>> >>> --- >>> Yavuz Selim Yilmaz >>> SUNY at Buffalo >>> Computer Science and Engineering >>> PhD Candidate >>> >>> On Jul 17, 2013, at 11:53 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> >>> On Wed, Jul 17, 2013 at 5:44 PM, Yavuz Selim YILMAZ < >>> yavuzsel(a)buffalo.edu&gt; wrote: >>> >>>> >>>> >>>> --- >>>> Yavuz Selim Yilmaz >>>> SUNY at Buffalo >>>> Computer Science and Engineering >>>> PhD Candidate >>>> >>>> On Jul 17, 2013, at 11:32 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> 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... >>>> >>>> >>>> However, in AeroDoc-iOS, we just stash the token: >>>> https://github.com/aerogear/aerogear-push-quickstart-ios/blob/master/ProD... >>>> >>>> >>>> And submit it, with the entire metadata, AFTER a successful login: >>>> https://github.com/aerogear/aerogear-push-quickstart-ios/blob/master/ProD... >>>> >>>> >>>> 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/pu... (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? In current setup, is it guaranteed that "didRegisterForRemoteNotificationsWithDeviceToken" will be called BEFORE [ self deviceRegistration]; call?

If not, then there can be devices which is successfully registered to APNs but not registered to Push EE server.

> 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(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 > _______________________________________________ > 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