PieterVanPoyer commented on issue #110:
URL: 
https://github.com/apache/cordova-plugin-network-information/issues/110#issuecomment-639588835


   > I've reproduced the described behaviour on an Android API 29 simulator 
using the latest cordova tooling and plugin.
   > 
   > Just posting some information... Couple of different theories.
   > 
   > ### Theory 1
   > Broadcast event is firing because we unregister and register to the native 
listener onPause/onResume. I assume the act of registering the event causes the 
event to fire at least once, producing an event to the javascript.
   > 
   > It didn't always unattach/re-attach the listener on pause/resume. This was 
changed by #74 for #64
   > 
   > ### Theory 2
   > The native broadcast simply fires when the activity is resumed.
   > 
   > I'm not really sure on the behaviour of the Intent broadcaster, but if 
theory 2 is actually what is happening, then I don't think this is a bug.
   > 
   > But if I were to make a bet, I think Theory 1 is why we are seeing these 
events on pause/resume. If we consider this a bug, then I think we should keep 
track of connection types, and only propagate the event to the javascript 
**if** the connection type actually changes. I'd support a PR that makes this 
change.
   > 
   > I'd also like to see if this behaviour is observable on iOS, but I don't 
have mac equipment to use to test this.
   
   Hi
   
   Thanks for the great work with Cordova!
   
   I think Theory 1 is correct.
   By reattatching the native listener it fires.
   This reattaching helped to fix the bug where the connection state seems to 
be wrong after an amount of time when the app was idle.
   
   I admit, it would be an improvement if we could keep the state of te 
connection and only propagate a change when the online/offline state 
effectivily changes.
   
   In my opinion, this plugin is very usefull, but aims to do too much.
   It was originally developed when there we're a lot **less** restrictions and 
rules in the Android system. 
   
   - Now the Android OS can stop the listeners for working when the app is idle.
   - Now the Android OS is much more watching the battery drain, and stopping 
apps when they are idle. 
   - Now there are a lot of more restrictions to privacy, and this affects the 
detection of the effective Network.
   - The ios system has even more restrictions about privacy.
   
   In the documentation of this plugin there is an example of an upload of a 
file in the background 
https://github.com/apache/cordova-plugin-network-information#sample-upload-a-file-depending-on-your-network-state-
 , this used to work great, but now you have to work with WorkManager and stuff 
like that to do work in the background.
   
   ## A suggestion
   _Loosen the requirements of the plugin to it's barebone's essentials._
   
   Requirements
   - Detect online/offline only when the app is active.
   - When online, only detect following types: WIFI, MOBILE
   - If possible, only fire when the state effectivily changes. So keep track 
of the previous state before the app went in the background. And the app is not 
killed by the system.
   
   Stop with next requirements
   - Detect online/offline when the app is not active.
   - Don't try to detect other network type's beside WIFI and MOBILE.
   - Do not let this plugin support background work like fileupload's and 
datasyncs. Remove it from the doc's.
   
   ## A suggestion to do on short notice
   - If 
https://github.com/apache/cordova-plugin-network-information/issues/91#issuecomment-531343312
 this comments work for the state. Maybe it should be mentioned in the README 
of this plugin.
   
   Kind regards
   Pieter


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to