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

observer for WIFI disconnected state doesn't work #159

Closed
wujianv5 opened this Issue Mar 6, 2017 · 10 comments

Comments

3 participants
@wujianv5

wujianv5 commented Mar 6, 2017

ReactiveNetwork.observeNetworkConnectivity(context)
                .subscribeOn(Schedulers.io())
                .filter(ConnectivityPredicate.hasState(NetworkInfo.State.CONNECTED, NetworkInfo.State.DISCONNECTED))
                .filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI))
                .observeOn(Schedulers.io())
                .subscribe((connectivity) -> {
                    switch (connectivity.getState()) {
                        case CONNECTED:
                            onWifiConnected();
                            break;
                        case DISCONNECTED:
                            onWifiDisconnected();
                            break;
                    }
                });

With above code, when I switched off wifi, onWifiDisconnected() wasn't called.
And then I tried to remove .filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI)), and onWifiDisconnected() was called with connectivity.getTypeName() == null, it's supposed to be WIFI.

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Mar 6, 2017

Owner
Owner

pwittchen commented Mar 6, 2017

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Mar 6, 2017

Owner

I took a quick look at the code. We can try to keep information about the last network device was connected to and then pass it to Connectivity object. This will allow obtaining the desired result.

Owner

pwittchen commented Mar 6, 2017

I took a quick look at the code. We can try to keep information about the last network device was connected to and then pass it to Connectivity object. This will allow obtaining the desired result.

@wujianv5

This comment has been minimized.

Show comment
Hide comment
@wujianv5

wujianv5 Mar 7, 2017

I think the following code
.filter(ConnectivityPredicate.hasState(NetworkInfo.State.CONNECTED, NetworkInfo.State.DISCONNECTED))
.filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI))
suggests I will be notified when WIFI is switched both on and off, which is not happened in my case.
I think if it's hard to implement the wifi disconnection filter you should change some design pattern to make people not confused.

And I'm not familiar with network state changing things, but I think when I switch off wifi, I'm not in an offline mode, since I still have mobile network connection, and maybe I could also have bluetooth connection. In that cases I guess the disconnection type can be detected ??

BTW, it's a really good work and a very easy tool to use. Thanks!

wujianv5 commented Mar 7, 2017

I think the following code
.filter(ConnectivityPredicate.hasState(NetworkInfo.State.CONNECTED, NetworkInfo.State.DISCONNECTED))
.filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI))
suggests I will be notified when WIFI is switched both on and off, which is not happened in my case.
I think if it's hard to implement the wifi disconnection filter you should change some design pattern to make people not confused.

And I'm not familiar with network state changing things, but I think when I switch off wifi, I'm not in an offline mode, since I still have mobile network connection, and maybe I could also have bluetooth connection. In that cases I guess the disconnection type can be detected ??

BTW, it's a really good work and a very easy tool to use. Thanks!

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Mar 7, 2017

Owner

You're right. Android SDK works in such way and behavior with filtering Observable mentioned by you may be confusing. It can be fixed within the library code. I have some sort of idea how to do that and I will notify you about the updates in this issue.

Owner

pwittchen commented Mar 7, 2017

You're right. Android SDK works in such way and behavior with filtering Observable mentioned by you may be confusing. It can be fixed within the library code. I have some sort of idea how to do that and I will notify you about the updates in this issue.

@pwittchen pwittchen modified the milestone: Fixing bugs & making enhancements Mar 7, 2017

@pwittchen pwittchen self-assigned this Mar 17, 2017

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Apr 10, 2017

Owner

@wujianv5 Can you provide details of your device and Android version? I've performed a test on Nexus 6 with Android 7.0 and it works fine. I mean, bug reported by you does not occur. When I apply filter: ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI), connectivity.getTypeName() is never null. It does not matter if it's in CONNECTED or DISCONNECTED state. It returns WIFI all the time.

Owner

pwittchen commented Apr 10, 2017

@wujianv5 Can you provide details of your device and Android version? I've performed a test on Nexus 6 with Android 7.0 and it works fine. I mean, bug reported by you does not occur. When I apply filter: ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI), connectivity.getTypeName() is never null. It does not matter if it's in CONNECTED or DISCONNECTED state. It returns WIFI all the time.

@wujianv5

This comment has been minimized.

Show comment
Hide comment
@wujianv5

wujianv5 Apr 17, 2017

My phone is MI 5s, and Android version is 6.0.1 MXB48T. I think because it's a customized version of Android, the manufacturer might have changed something.

wujianv5 commented Apr 17, 2017

My phone is MI 5s, and Android version is 6.0.1 MXB48T. I think because it's a customized version of Android, the manufacturer might have changed something.

@IonutNegru87

This comment has been minimized.

Show comment
Hide comment
@IonutNegru87

IonutNegru87 Jun 8, 2017

I encounter the same issue and I think it is because of the Connectivity.create(context) in the NetworkCallback#onLost(Network).
From what I noticed, this will create an Connectivity object which has the type == -1 (ConnectivityManager.NONE)

Changing .filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI)) to .filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI, -1)), seems to fix this issue.

IonutNegru87 commented Jun 8, 2017

I encounter the same issue and I think it is because of the Connectivity.create(context) in the NetworkCallback#onLost(Network).
From what I noticed, this will create an Connectivity object which has the type == -1 (ConnectivityManager.NONE)

Changing .filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI)) to .filter(ConnectivityPredicate.hasType(ConnectivityManager.TYPE_WIFI, -1)), seems to fix this issue.

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Jun 8, 2017

Owner

If the solution provided by @IonutNegru87 works, we can add this type (unknown), to the list of initial types by default inside ConnectivityPredicate.hasType(...) method. This should fix problems for all types of connections in the described situation because when we are disconnected from the network, the type is unknown. It's correct behavior but may be misleading in the case of reactive programming when we don't operate on the state, but on the stream.

Owner

pwittchen commented Jun 8, 2017

If the solution provided by @IonutNegru87 works, we can add this type (unknown), to the list of initial types by default inside ConnectivityPredicate.hasType(...) method. This should fix problems for all types of connections in the described situation because when we are disconnected from the network, the type is unknown. It's correct behavior but may be misleading in the case of reactive programming when we don't operate on the state, but on the stream.

pwittchen added a commit that referenced this issue Jul 7, 2017

updating network filtering inside ConnectivityPredicate#hasType metho…
…d by adding unknown netowrk type as initial type in the filters array - fixes #159
@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Jul 7, 2017

Owner

I've created an initial fix in PR #186. Now, it's tested only via unit tests. I'll perform a few manual tests before a merge. You can also test it on a feature branch on your own if you would like to. Any feedback is welcome. This PR is for RxJava2.x branch, but we can add it to RxJava1.x branch as well (e.g. via git cherry-pick).

Owner

pwittchen commented Jul 7, 2017

I've created an initial fix in PR #186. Now, it's tested only via unit tests. I'll perform a few manual tests before a merge. You can also test it on a feature branch on your own if you would like to. Any feedback is welcome. This PR is for RxJava2.x branch, but we can add it to RxJava1.x branch as well (e.g. via git cherry-pick).

pwittchen added a commit that referenced this issue Jul 7, 2017

updating network filtering inside ConnectivityPredicate#hasType metho…
…d by adding unknown netowrk type as initial type in the filters array - fixes #159

@pwittchen pwittchen closed this in #186 Jul 7, 2017

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Jul 7, 2017

Owner

Fix will be available in the next release.

Owner

pwittchen commented Jul 7, 2017

Fix will be available in the next release.

@pwittchen pwittchen referenced this issue Jul 7, 2017

Closed

Release 0.10.0 #185

16 of 16 tasks complete

pwittchen added a commit that referenced this issue Jul 7, 2017

RxJava1.x: Fixing network filtering inside ConnectivityPredicate#hasT…
…ype method by adding unknown netowrk type as initial type in the filters array - fixes #159
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment