Provide hook for network availability notification on Android

I new a stub with a multiplexed channel like this:

ServiceGrpc.ServiceBlockingStub stub = ServiceGrpc.newBlockingStub(getChannel());

 public static ManagedChannel getChannel() {
        if (mChannel == null) {
            mChannel = ManagedChannelBuilder.forAddress(Config.HOST, Config.PORT)
                    .usePlaintext(true)
                    .build();
        }
        return mChannel;
    }

Launch the application when the network is close , then open the network . Invoking method of stub that is built with a multiplex don`t work immediately. While invoking method of stub that built with new channel can get response from server immediately . It will happen also when the network was unavailable long time .and then network turn available .

How does channel judge network state ？How to reconnect immediately with multiplexed channel ?

Build and platform infomation:

            compileSdkVersion: 23,
            buildToolsVersion: "23.0.2",
            minSdkVersion    : 14,
            targetSdkVersion : 19,

application is running in Android 5.1.1 and 6.0.1

Thanks !

[ericgribkoff]

I haven’t had the chance to work further on this yet. It’s still on my task list, but I have some higher priority items that have taken precedence for the moment.

FYI Cronet, which is being open-sourced for gRPC in https://github.com/grpc/grpc-java/pull/3349, already includes some pretty sophisticated network availability monitoring on Android that gRPC gets for free when using Cronet as the transport.

[bubenheimer]

Having this functionality would be immensely useful for my Android use case as well. Have implementation plans become more concrete?

Could there be an option to offer a more aggressive backoff strategy for Android/OkHttp in the meantime? Is backoff carried over to future connection attempts right now, instead of resetting the backoff to 0 on success?

If the current exponential backoff mechanism focuses on not overloading a busy server with requests it may be misplaced when the client is Android. I’d think in most connectivity cases it’s the mobile client that has issues (namely with the network, especially away from WiFi), not the server being overloaded. At least that would be true for my use case, where I control the server. And I’d much prefer my server getting hammered on occasion over my client being unresponsive all the time.

With a flaky network or scheduled execution I’d need to reconnect as soon as I’m back online to not miss the connectivity window. I guess the network monitoring hook would address this need.