Connectivity Monitoring - Feature about androidnetworkmanager HOT 13 CLOSED

Yes. When there's a change, network_connected to network_disconnected or vice versa, the corresponding callbacks are triggered

from androidnetworkmanager.

The use case I'm thinking;

/**
*@param this is an Activity or a Fragment or a View or an Application
**/
NetworkManager.monitor(this, new ConnectivityChangeListener{
    @Override
    public onConnected(int connectionType, boolean isFast){
        //user code here
        ...
    }
    @Override
    public void onConnectionLost(){
        ...
    }
});

An overload will provide filtering for ConnectionTypes so we can only listen to connectivity changes of a connection type such as wifi...

NetworkManager.monitor(this,  int connectionType, new ConnectivityChangeListener{...});

from androidnetworkmanager.

Nice, this would be amazing

from androidnetworkmanager.

Just as onConnected(int, boolean) is triggered for the corresponding connectionType or aany connection, so will the onConnectionLost(), i.e;

In the second overload, .monitor(Context, int, Listener) if the Connection of type connectionType is lost the callback to onConnectionLost is triggered.
But for the Listener that listens to any network change, the onConnectionLost is only triggered when all connections are lost.

from androidnetworkmanager.

The .monitor is an amazing feature, esp when building applications that require constant internet connection to work, and even trigger changes to UI componets, like disabling send button. Awesome!

Will the onConnected(int, boolean be triggered when the connection is restored?

from androidnetworkmanager.

@chweez Are you renaming the class from NetworkManager?

from androidnetworkmanager.

We use the NetworkUtil to check type of connection and also speeds of connection and Tovuti for network monitoring, is this correct?

from androidnetworkmanager.

Correct...any suggestions?

from androidnetworkmanager.

The implemented version became

Tovuti.from(context)
    .monitor(..., new Listener{...});

Are there any improvements you'd like to see?

from androidnetworkmanager.

Also, for now, the user must call Tovuti.from(context).stop() but i want to make it automatic when the activity/fragment stops.
So, the way Glide implements this feature is by having a view-less fragment. The view-less fragment is attached to the activity/fragment where the Monitor is attached and these fragment receives the lifecycle events of the parent/host thus allowing the Monitor to respond accordingly without user intervention (i.e. calling stop method).
I'll try see if this way will suit us. The only problem is increasing the complexity of the library unnecessarily. What do you think @jumadeveloper?

from androidnetworkmanager.

I renamed NetworkManager to NetworkUtil, do you wish the name to remain as NetworkManager?

from androidnetworkmanager.

Closed by pull #4... I'll open another issue for the automatic lifecycle management...

from androidnetworkmanager.

The naming is perfect, NetworkManager may seem confusing or as part of the AndroidSDK, let me follow the other open issue

from androidnetworkmanager.