Implicit Broadcast Receivers Going Away After Android N #62

Closed
epicstar opened this Issue May 30, 2016 · 7 comments

Comments

2 participants
@epicstar

Apparently, Implicit Broadcast Receivers are going away in Android O. 3 of them are already gone in N, which includes the CONNECTIVITY_CHANGE broadcast.

I looked into your code and you don't seem to be using that (rather, you create an instance of a generic broadcast receiver and always call the ConnectivityManager for every broadcast received from it), but it's possible your current method of calling for connectivity changes could still be gone in Android N? Google recommends using the JobScheduler API instead (however, you can only use this starting in API 21...).

I'm thinking that releases should consider using the JobScheduler API instead for listening to connectivity changes (with a shim for using the current broadcast receiver below API 21). What do you think?

Source: https://www.youtube.com/watch?v=VC2Hlb22mZM

XDA has a good TL;DR about this: http://www.xda-developers.com/how-android-n-will-improve-battery-and-memory-management/

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen May 30, 2016

Owner

Thanks for creating that issue. I didn't know about that. I'll take a closer look at that update in Android N and write a more detailed answer later when I find some time in the nearest days.

Owner

pwittchen commented May 30, 2016

Thanks for creating that issue. I didn't know about that. I'll take a closer look at that update in Android N and write a more detailed answer later when I find some time in the nearest days.

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen May 30, 2016

Owner

I quickly browsed docs and I can give you a short answer. As far as I see in the documentation, Google Developers extended ConnectivityManager and added some new listeners, what you can read here: https://developer.android.com/reference/android/net/ConnectivityManager.html. I think, we can create a strategy with Broadcast for "pre-N" devices (existing solution) and a new strategy for "N and higher" devices. We'll need to code new implementation of the new strategy, but I think library API could stay the same.

You asked about JobScheduler. I'm not sure if it should be used for checking connectivity. I think it should be used for processing queues of the jobs or operations to be executed. When jobs are done, a scheduler is no longer needed. I don't have that much experience with JobScheduler, so I may be wrong. Moreover, after a quick look at the documentation, I think connectivity monitoring on Android N can be implemented without JobScheduler.

Owner

pwittchen commented May 30, 2016

I quickly browsed docs and I can give you a short answer. As far as I see in the documentation, Google Developers extended ConnectivityManager and added some new listeners, what you can read here: https://developer.android.com/reference/android/net/ConnectivityManager.html. I think, we can create a strategy with Broadcast for "pre-N" devices (existing solution) and a new strategy for "N and higher" devices. We'll need to code new implementation of the new strategy, but I think library API could stay the same.

You asked about JobScheduler. I'm not sure if it should be used for checking connectivity. I think it should be used for processing queues of the jobs or operations to be executed. When jobs are done, a scheduler is no longer needed. I don't have that much experience with JobScheduler, so I may be wrong. Moreover, after a quick look at the documentation, I think connectivity monitoring on Android N can be implemented without JobScheduler.

@pwittchen pwittchen referenced this issue May 30, 2016

Closed

Release 0.5.0 #63

13 of 13 tasks complete
@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen May 30, 2016

Owner

I've added this issue to the Roadmap. The plan is to implement it for release 0.5.0. I think, 0.3.0 should be released in the nearest days and 0.4.0 should be released shortly after the previous version. I just need to find some time for this.

Owner

pwittchen commented May 30, 2016

I've added this issue to the Roadmap. The plan is to implement it for release 0.5.0. I think, 0.3.0 should be released in the nearest days and 0.4.0 should be released shortly after the previous version. I just need to find some time for this.

@pwittchen pwittchen modified the milestone: 0.5.0 May 30, 2016

@epicstar

This comment has been minimized.

Show comment
Hide comment
@epicstar

epicstar May 31, 2016

Wow, thanks for the immediate reply and possible solutions!

Based on your current reply, I was thinking that since NetworkCallback class started at API 21, I was thinking that perhaps instead of using the new solution for N+... should the new strategy start with devices with API 21 (L) instead?

Also, I'm willing to devote my time to improve the library :)

epicstar commented May 31, 2016

Wow, thanks for the immediate reply and possible solutions!

Based on your current reply, I was thinking that since NetworkCallback class started at API 21, I was thinking that perhaps instead of using the new solution for N+... should the new strategy start with devices with API 21 (L) instead?

Also, I'm willing to devote my time to improve the library :)

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen May 31, 2016

Owner

Yeah, I was thinking about NetworkCallback as it's part of new ConnectivityManager. I think new strategy can be implemented for Android L (API 21) and higher because a new implementation is available there. Pull Requests and new issues are always welcome :). I just need to release latest updates, which I have in mind and then this issue can be resolved (after the release of 0.4.0).

Side note: additional code snippet with usage of NetworkCallback: http://www.programcreek.com/java-api-examples/index.php?api=android.net.Network

There's a new branch created for this task named 'issue-62' from 'develop' branch.

Owner

pwittchen commented May 31, 2016

Yeah, I was thinking about NetworkCallback as it's part of new ConnectivityManager. I think new strategy can be implemented for Android L (API 21) and higher because a new implementation is available there. Pull Requests and new issues are always welcome :). I just need to release latest updates, which I have in mind and then this issue can be resolved (after the release of 0.4.0).

Side note: additional code snippet with usage of NetworkCallback: http://www.programcreek.com/java-api-examples/index.php?api=android.net.Network

There's a new branch created for this task named 'issue-62' from 'develop' branch.

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Jul 24, 2016

Owner

Done. Right now, it's in 'develop' branch. Before next release 'develop' branch is going to be merged into 'master' branch and it will be available.

Owner

pwittchen commented Jul 24, 2016

Done. Right now, it's in 'develop' branch. Before next release 'develop' branch is going to be merged into 'master' branch and it will be available.

@pwittchen pwittchen removed the in develop label Jul 24, 2016

@pwittchen

This comment has been minimized.

Show comment
Hide comment
@pwittchen

pwittchen Jul 24, 2016

Owner

Branch 'develop' was merged into 'master' branch. An update will be available in the release of v. 0.5.0.

Owner

pwittchen commented Jul 24, 2016

Branch 'develop' was merged into 'master' branch. An update will be available in the release of v. 0.5.0.

@pwittchen pwittchen closed this Jul 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment