-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bugfix - Network Reachability #2688
Conversation
Prior to this change, the reachability listener was notified at launch if the device was not in airplane mode. When in airplane mode, the reachability flags were 0, which is what we were defaulting the previous flags to. Because of this, the notifyListener function would early out since the flags had not changed. The core issue here was that the default value of previousFlags was poorly chosen. It should instead default to a value that represents and unknown status. One way to do this would be to make previousFlags an optional. However, this change would not be backwards compatible, so it was abandoned. The best backwards compatible way to make this change was to set previousFlags to a rawValue that is not currently used. That way, we can guarantee that the originally computed flags will be different than the default previous flags. This change results in the listener being called at launch even when in airplane mode. Please refer to issue #2677 for more details.
164c738
to
b050cc6
Compare
b050cc6
to
6f01350
Compare
</tableViewCell> | ||
</cells> | ||
</tableViewSection> | ||
<tableViewSection headerTitle="Reachability" id="7nc-cQ-nUY"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a new Reachability
section with a Reachability Status
cell that prints out the reachability status when you tap it. All of the other changes are just Xcode feeling the need to rebuild the entire storyboard.
Wow good timing! I was actually looking into this yesterday because I was encountering the same issue, I'll take a look and see if your patch fixes it for us. |
Great! Thanks for the quick turnaround, @cnoon! |
👍 |
Issue Link 🔗
This PR resolves Issue #2677.
Goals ⚽
The goals of this PR are to resolve the issue reported where the reachability listener closure is not being called when launching an app in airplane mode.
Implementation Details 🚧
Prior to this change, the reachability listener was notified at launch if the device was not in airplane mode. When in airplane mode, the reachability flags were 0, which is what we were defaulting the previous flags to. Because of this, the
notifyListener
function would early out since the flags had not changed.The core issue here was that the default value of
previousFlags
was poorly chosen. It should instead default to a value that represents and unknown status. One way to do this would be to makepreviousFlags
an optional. However, this change would not be backwards compatible, so it was abandoned.The best backwards compatible way to make this change was to set
previousFlags
to arawValue
that is not currently used. That way, we can guarantee that the originally computed flags will be different than the default previous flags. This change results in the listener being called at launch even when in airplane mode.Testing Details 🔍
All the original reachability tests are still passing as expected. Given the nature of this particular change, there's no way to test this specific change unless we would redesign the
NetworkReachabilityManager
to decouple the actual Reachability API calls and inject them. This type of change is out-of-scope for AF 4.x release train.