iOS 5 + Reachability Fixes

[Blake Watters]

I have just pushed a massive update to the reachability observer code that will hopefully work around the issues we've been seeing with iOS 5 and devices getting 'stuck'. The changes are as follows:

* Eliminated reliance on synchronous flag retrieval API's that were indirectly called across the API. We now cache reachability flags and use the last values retrieved from the async callback instead of grabbing them all the time.

* Added support for monitoring the local Wifi and Internet access in general instead of just a particular hostname.

* Changed RKClient to use Internet based observation instead of hostname. This may fix the iOS 5 problem and needs testing.

* Expanded the comments and documentation extensively

I could use some testing help from anyone who has been feeling this pain. The code is on the 408-reachability-issues branch and will be merged tomorrow after I make sure I didn't ruin christmas somehow.

Branch: https://github.com/RestKit/RestKit/tree/408-reachability-issues

Commit: https://github.com/RestKit/RestKit/commit/935f6dee913f47b147fa9c465dd569b38635010f

-- 
Blake Watters
Sent with Sparrow

[Thomas]

Hi Blake,

I tried the new observer and got this error:

2011-10-18 10:28:08.946 XxxxXxxx[36250:14003] D
restkit.network.queue:RKRequestQueue.m:299 Queue <RKRequestQueue:
0xa26afe0 name=(null) suspended=YES requestCount=1 loadingCount=0/5>
has been unsuspended
2011-10-18 10:28:08.946 XxxxXxxx[36250:14003] *** Assertion failure in
-[RKReachabilityObserver validateIntrospection], /Users/thomasgr/
Documents/Xcode4.2/RestKit/Code/Network/RKReachabilityObserver.m:288

I looked into your example and changed my observer. But the error is
still there.

Regards,
Thomas

> Commit:https://github.com/RestKit/RestKit/commit/935f6dee913f47b147fa9c465dd...
>
> --
> Blake Watters
> Sent with Sparrow (http://www.sparrowmailapp.com)

[Blake Watters]

Hi Thomas -

I just pushed a small tweak that should hopefully block that assertion from being triggered. Can you pull the branch and try again? If you hit that assertion again, a copy and paste of the 3-4 method calls leading up to it would be helpful.

- Blake

-- 
Blake Watters
Sent with Sparrow

[Thomas]

Hi Blake,

I fetched your commit and build a new version of my app. Tested the
app in the simulator and on an iPhone4 and on an iPod touch 3rd
generation. Everything seems to work fine. No more assertions and no
more stuck in offline mode during the first few tests. I pushed the
new version to my testers and I think I get some response during the
next 24 hours. It is late afternoon here in germany.

Thanks for your fast response. Restkit is awesome.

With best regards,
Thomas

On 18 Okt., 15:25, Blake Watters <blakewatt...@gmail.com> wrote:
> Hi Thomas -
>
> I just pushed a small tweak that should hopefully block that assertion from being triggered. Can you pull the branch and try again? If you hit that assertion again, a copy and paste of the 3-4 method calls leading up to it would be helpful.
>
> - Blake
>
> --
> Blake Watters

> Sent with Sparrow (http://www.sparrowmailapp.com)

>
>
>
>
>
>
>
> On Tuesday, October 18, 2011 at 4:30 AM, Thomas wrote:
> > Hi Blake,
>
> > I tried the new observer and got this error:
>
> > 2011-10-18 10:28:08.946 XxxxXxxx[36250:14003] D
> > restkit.network.queue:RKRequestQueue.m:299 Queue <RKRequestQueue:
> > 0xa26afe0 name=(null) suspended=YES requestCount=1 loadingCount=0/5>
> > has been unsuspended
> > 2011-10-18 10:28:08.946 XxxxXxxx[36250:14003] *** Assertion failure in
> > -[RKReachabilityObserver validateIntrospection], /Users/thomasgr/
> > Documents/Xcode4.2/RestKit/Code/Network/RKReachabilityObserver.m:288
>
> > I looked into your example and changed my observer. But the error is
> > still there.
>
> > Regards,
> > Thomas
>

[Ming Yeow Ng]

I have tested the new version on the iPhone 4 and iPad1, and it seems
to resolve a few crash/reachability issues we had

we are pushing out to a few users with prior problems, will get back
as we hear from them

M

[Blake Watters]

I am about to push another round of cleanups to realign the dependencies within RKClient with the new reachability code. Will send a note when its available and I anticipate merging to master some time tomorrow.

-- 
Blake Watters
Sent with Sparrow

[Blake Watters]

The cleanups are now in place. I believe it should be good for merging and general use

-- 
Blake Watters
Sent with Sparrow

[Thomas]

In my app your fixes just work. Thank you very much for your fast
help.

With best regards,
Thomas

On 19 Okt., 05:27, Blake Watters <blakewatt...@gmail.com> wrote:
> The cleanups are now in place. I believe it should be good for merging and general use
>
> --
> Blake Watters

> Sent with Sparrow (http://www.sparrowmailapp.com)
>
>
>
>
>
>
>

> On Tuesday, October 18, 2011 at 11:12 PM, Blake Watters wrote:
> > I am about to push another round of cleanups to realign the dependencies within RKClient with the new reachability code. Will send a note when its available and I anticipate merging to master some time tomorrow.
>
> > --
> > Blake Watters

> > Sent with Sparrow (http://www.sparrowmailapp.com)
>

> > On Tuesday, October 18, 2011 at 10:43 PM, Ming Yeow Ng wrote:
>
> > > I have tested the new version on the iPhone 4 and iPad1, and it seems
> > > to resolve a few crash/reachability issues we had
>
> > > we are pushing out to a few users with prior problems, will get back
> > > as we hear from them
>
> > > M
>

> > > On Oct 18, 11:30 pm, Thomas <tho...@griwenka.de (http://griwenka.de)> wrote:
> > > > Hi Blake,
>
> > > > I fetched your commit and build a new version of my app. Tested the
> > > > app in the simulator and on an iPhone4 and on an iPod touch 3rd
> > > > generation. Everything seems to work fine. No more assertions and no
> > > > more stuck in offline mode during the first few tests. I pushed the
> > > > new version to my testers and I think I get some response during the
> > > > next 24 hours. It is late afternoon here in germany.
>
> > > > Thanks for your fast response. Restkit is awesome.
>
> > > > With best regards,
> > > > Thomas
>

> > > > On 18 Okt., 15:25, Blake Watters <blakewatt...@gmail.com (http://gmail.com)> wrote:
>
> > > > > Hi Thomas -
>
> > > > > I just pushed a small tweak that should hopefully block that assertion from being triggered. Can you pull the branch and try again? If you hit that assertion again, a copy and paste of the 3-4 method calls leading up to it would be helpful.
>
> > > > > - Blake
>
> > > > > --
> > > > > Blake Watters
> > > > > Sent with Sparrow (http://www.sparrowmailapp.com)
>
> > > > > On Tuesday, October 18, 2011 at 4:30 AM, Thomas wrote:
> > > > > > Hi Blake,
>
> > > > > > I tried the new observer and got this error:
>
> > > > > > 2011-10-18 10:28:08.946 XxxxXxxx[36250:14003] D
> > > > > > restkit.network.queue:RKRequestQueue.m:299 Queue <RKRequestQueue:
> > > > > > 0xa26afe0 name=(null) suspended=YES requestCount=1 loadingCount=0/5>
> > > > > > has been unsuspended
> > > > > > 2011-10-18 10:28:08.946 XxxxXxxx[36250:14003] *** Assertion failure in
> > > > > > -[RKReachabilityObserver validateIntrospection], /Users/thomasgr/
> > > > > > Documents/Xcode4.2/RestKit/Code/Network/RKReachabilityObserver.m:288
>
> > > > > > I looked into your example and changed my observer. But the error is
> > > > > > still there.
>
> > > > > > Regards,
> > > > > > Thomas
>

[Ivan Vučica]

I'm uncertain if this is iOS5-related, because I tested only in the Simulator it seems to occur in the iOS4.3 Simulator as well.

However, prior to fixes, after the first request was successfully finished RestKit was permanently stuck in resolving the reachability.

After the fixes, first request still works, but RestKit is throwing an error and talking about observing reachability for 0.0.0.0. Full log of things happening after initiating the second request:

2011-10-19 10:23:28.041 AppName[4388:bc03] D restkit.network:RKClient.m:265 Reachability observer changed for client <RKClient: 0x59400b0>, suspending queue (null) until reachability to host '0.0.0.0' can be determined

2011-10-19 10:23:28.043 AppName[4388:bc03] D restkit.network:RKClient.m:250 Reachability observer changed for RKClient <RKClient: 0x59400b0>, disposing of previous instance: <RKReachabilityObserver: 0x5943470 host=0.0.0.0 isReachabilityDetermined=NO isMonitoringLocalWiFi=579828 reachabilityFlags=-- ------->

2011-10-19 10:23:28.044 AppName[4388:bc03] W restkit.network.reachability:RKReachabilityObserver.m:350 <RKReachabilityObserver: 0x5943470 host=0.0.0.0 isReachabilityDetermined=YES isMonitoringLocalWiFi=579828 reachabilityFlags=-R -----l->: SCNetworkReachabilitySetDispatchQueue() failed: Invalid argument

Note that I am re-creating the RKObjectManager, and thus RKClient, upon every sync. I'm letting it autorelease itself.

I'm using revision b108fa98ab733d076a21cec549b994d98231f547, the current HEAD of the branch.

--
Ivan Vučica - iv...@vucica.net

[Ivan Vučica]

Nevermind.

Looks like it's got more to do with RestKit being sensitive about recreating the object manager. I moved the instantiation of RKObjectManager and mapping setup to -init. Still, it doesn't seem right that reachability observer should be sensitive about re-creating the object manager.

[Ming Yeow Ng]

Hi Blake, I hit on a pretty severe error that i never noticed before
on previous versions

Essentially, some weird "caching" seems to be happening.

- i used the application for a while (iOS 4.3.3, commit
935f6dee913f47b147fa9c465dd569b38635010f)
- i realized that the content was not being updated even when there is
new content coming in
- for certain calls, it seems like the phone was retrieving data from
the server, but there is not request hitting the server
- it becomes weird when i exited the application, explicitly quit the
app from the multi-tasking bar
- when the app is open again, the older data set gets loaded, even
when the server traces no requests
- i restarted the phone, but the older data gets loaded again

The only thing i can think of is that some data is cached in some way
on the phone, and e phone is not making any server calls, but using
that data instead.

I have coredata for a separate purpose, but i have not set up restkit
to use it in anyway.

Any idea if the latest fixes might be causing this?

This could just be an edge case, but it is severe enough that i feel e
need to voice it out here.

M

> > Ivan Vučica - i...@vucica.net
>
> --
> Ivan Vučica - i...@vucica.net

[Jeff Arena]

The caching is expected. Check out RKRequestCache.

2011/10/19 Ming Yeow Ng <ming...@gmail.com>

[Christian]

The notification doesn't seem to fire when turning airplay mode on and
off. Is this to be expected?

I was checking for RKReachabilityDidChange (or whatever it's called
now) notification.

On Oct 20, 5:19 am, Jeff Arena <j...@gateguruapp.com> wrote:
> The caching is expected. Check out RKRequestCache.
>

> 2011/10/19 Ming Yeow Ng <mingy...@gmail.com>

[Blake Watters]

I pushed a fix a little while ago where non-hostname based initialization was failing to schedule the observer properly. Should fix your issue Christian

-- 
Blake Watters
Sent with Sparrow

--
Ivan Vuèica - i...@vucica.net

--
Ivan Vuèica - i...@vucica.net

[Larry Legend]

Hey Blake, thanks for the reachability update! This looks great.

I'm porting over one of our projects to use the newest code from
master.

In a few places, we check for network availability before doing
things, e.g.

if ([[RKClient sharedClient] isNetworkReachable]) {
// Load remote ad
}
else {
// Show local ad instead of showing failed remote ad
}

However, I'm getting an assertion,

*** Assertion failure in -[RKReachabilityObserver

validateIntrospection], /path.../RKReachabilityObserver.m:291
*** Terminating app due to uncaught exception
'NSInternalInconsistencyException', reason: 'Cannot inspect
reachability state: no reachabilityFlags available. Be sure to check
isReachabilityDetermined'

Do I need to check it every time I try to call [[RKClient
sharedClient] isNetworkReachable] ? And if reachability is not
determined, would it make more sense to just go for it with the
request, or wait?

For example, like this?
if ([[[RKClient sharedClient] reachabilityObserver]
isReachabilityDetermined]) {
if ([[RKClient sharedClient] isNetworkReachable]) {
// Load remote ad
}
else {
// Show local ad instead of showing failed remote ad
}
}
else {
// ?
}

Larry

On Oct 20, 2:24 pm, Blake Watters <blakewatt...@gmail.com> wrote:
> I pushed a fix a little while ago where non-hostname based initialization was failing to schedule the observer properly. Should fix your issue Christian
>
> --  
> Blake Watters

> Sent with Sparrow (http://www.sparrowmailapp.com)

>
>
>
>
>
>
>
> On Thursday, October 20, 2011 at 2:20 PM, Christian wrote:
> > The notification doesn't seem to fire when turning airplay mode on and
> > off. Is this to be expected?
>
> > I was checking for RKReachabilityDidChange (or whatever it's called
> > now) notification.
>

> > On Oct 20, 5:19 am, Jeff Arena <j...@gateguruapp.com (http://gateguruapp.com)> wrote:
> > > The caching is expected. Check out RKRequestCache.
>

> > > 2011/10/19 Ming Yeow Ng <mingy...@gmail.com (http://gmail.com)>

>
> > > > Hi Blake, I hit on a pretty severe error that i never noticed before
> > > > on previous versions
>
> > > > Essentially, some weird "caching" seems to be happening.
>
> > > > - i used the application for a while (iOS 4.3.3, commit
> > > > 935f6dee913f47b147fa9c465dd569b38635010f)
> > > > - i realized that the content was not being updated even when there is
> > > > new content coming in
> > > > - for certain calls, it seems like the phone was retrieving data from
> > > > the server, but there is not request hitting the server
> > > > - it becomes weird when i exited the application, explicitly quit the
> > > > app from the multi-tasking bar
> > > >   - when the app is open again, the older data set gets loaded, even
> > > > when the server traces no requests
> > > > - i restarted the phone, but the older data gets loaded again
>
> > > > The only thing i can think of is that some data is cached in some way
> > > > on the phone, and e phone is not making any server calls, but using
> > > > that data instead.
>
> > > > I have coredata for a separate purpose, but i have not set up restkit
> > > > to use it in anyway.
>
> > > > Any idea if the latest fixes might be causing this?
>
> > > > This could just be an edge case, but it is severe enough that i feel e
> > > > need to voice it out here.
>
> > > > M
>

> > > > On Oct 19, 4:37 pm, Ivan Vuèica <ivuc...@gmail.com (http://gmail.com)> wrote:
> > > > > Nevermind.
>
> > > > > Looks like it's got more to do with RestKit being sensitive about
> > > > recreating
> > > > > the object manager. I moved the instantiation of RKObjectManager and
> > > > mapping
> > > > > setup to -init. Still, it doesn't seem right that reachability observer
> > > > > should be sensitive about re-creating the object manager.
>

> > > > > > On Wed, Oct 19, 2011 at 10:18, Thomas <tho...@griwenka.de (http://griwenka.de)> wrote:
>
> > > > > > > In my app your fixes just work. Thank you very much for your fast
> > > > > > > help.
>
> > > > > > > With best regards,
> > > > > > > Thomas
>

> > > > > > > On 19 Okt., 05:27, Blake Watters <blakewatt...@gmail.com (http://gmail.com)> wrote:
> > > > > > > > The cleanups are now in place. I believe it should be good for
> > > > merging
> > > > > > > and general use
>
> > > > > > > > --
> > > > > > > > Blake Watters
> > > > > > > > Sent with Sparrow (http://www.sparrowmailapp.com)
>
> > > > > > > > On Tuesday, October 18, 2011 at 11:12 PM, Blake Watters wrote:
> > > > > > > > > I am about to push another round of cleanups to realign the
> > > > > > > dependencies within RKClient with the new reachability code. Will send
> > > > a
> > > > > > > note when its available and I anticipate merging to master some time
> > > > > > > tomorrow.
>
> > > > > > > > > --
> > > > > > > > > Blake Watters
> > > > > > > > > Sent with Sparrow (http://www.sparrowmailapp.com)
>
> > > > > > > > > On Tuesday, October 18, 2011 at 10:43 PM, Ming Yeow Ng wrote:
>
> > > > > > > > > > I have tested the new version on the iPhone 4 and iPad1, and it
> > > > > > > seems
> > > > > > > > > > to resolve a few crash/reachability issues we had
>
> > > > > > > > > > we are pushing out to a few users with prior problems, will get
> > > > back
> > > > > > > > > > as we hear from them
>
> > > > > > > > > > M
>

> > > > > > > > > > On Oct 18, 11:30 pm, Thomas <tho...@griwenka.de (http://griwenka.de) (

> > > >http://griwenka.de)>
> > > > > > > wrote:
> > > > > > > > > > > Hi Blake,
>
> > > > > > > > > > > I fetched your commit and build a new version of my app.
> > > > Tested
> > > > > > > the
> > > > > > > > > > > app in the simulator and on an iPhone4 and on an iPod touch
> > > > 3rd
> > > > > > > > > > > generation. Everything seems to work fine. No more assertions
> > > > and
> > > > > > > no
> > > > > > > > > > > more stuck in offline mode during the first few tests. I
> > > > pushed
> > > > > > > the
> > > > > > > > > > > new version to my testers and I think I get some response
> > > > during
> > > > > > > the
> > > > > > > > > > > next 24 hours. It is late afternoon here in germany.
>
> > > > > > > > > > > Thanks for your fast response. Restkit is awesome.
>
> > > > > > > > > > > With best regards,
> > > > > > > > > > > Thomas
>

> > > > > > > > > > > On 18 Okt., 15:25, Blake Watters <blakewatt...@gmail.com (http://gmail.com) (

> ...
>
> read more »

[Blake Watters]

Larry -

How quickly are you dispatching the requests after client init? It should be able to resolve reachability determination pretty quickly since its no longer targeting a hostname. Surprised if you hit this often. I considered making isNetworkReachable on the client safe to call in an indeterminate state, but punted for exactly the reason you outlined -- uncertain of the correct default behavior. Any votes? Could make configurable I guess… I'm guessing we want to assume online since you'll get a failure you can handle, but uncertain...

-- 
Blake Watters
Sent with Sparrow

[Larry Legend]

Hi Blake,

Thanks for the quick reply! Looks like the offending call was in the
method that loads thumbnails from the web, invoked from
cellForRowAtIndexPath: for not-yet-loaded thumbnails in the root view
controller's table view that is presented upon launch.

I fixed it by changing this check in my code:

if ([[[RKClient sharedClient] isNetworkReachable]) {...}

to:

if ([[[RKClient sharedClient] reachabilityObserver]

isReachabilityDetermined] != YES || [[RKClient sharedClient]
isNetworkReachable]) {...}

When the first condition is true, it skips the second condition.

I think my original reason for checking isNetworkReachable here was
because I wanted to differentiate between a fail due to connectivity
versus a fail due to a bad image or URL.

As far as my vote, it would be what you described. In the case of
isReachabilityDetermined == NO, assume online. Maybe make it
configurable to do the opposite, but it looks like you might make this
assumption elsewhere anyway, for example in -[RKRequest
shouldDispatchRequest]:

- (BOOL)shouldDispatchRequest {
if (nil == self.reachabilityObserver || NO ==
[self.reachabilityObserver isReachabilityDetermined]) {
return YES;
}

return [self.reachabilityObserver isNetworkReachable];
}

Larry

On Oct 20, 4:24 pm, Blake Watters <blakewatt...@gmail.com> wrote:
> Larry -
>
> How quickly are you dispatching the requests after client init? It should be able to resolve reachability determination pretty quickly since its no longer targeting a hostname. Surprised if you hit this often. I considered making isNetworkReachable on the client safe to call in an indeterminate state, but punted for exactly the reason you outlined -- uncertain of the correct default behavior. Any votes? Could make configurable I guess… I'm guessing we want to assume online since you'll get a failure you can handle, but uncertain...  
>
> --  
> Blake Watters

> Sent with Sparrow (http://www.sparrowmailapp.com)
>
>
>
>
>
>
>

> ...
>
> read more »