Consider using ConnectivityManager to improve battery and notification delivery speed

[outis151]

I have noticed that the app still tries to connect when no network is available. Apart from the battery usage, this causes a delay in notification delivery when the network is back up again due to a reconnect being scheduled for every 1200 seconds.

Perhaps android.net.ConnectivityManager NetworkCallback can be of help here?
I would also happily work on a pull request for this.

[jmattheis]

Some time ago, there was integration with the ConnectivityManager.CONNECTIVITY_ACTION. Sadly, it delayed reconnects in some cases for about 2 hours, even if the network was available. Thus, it got removed. See #153 (comment)

[tkas]

Hello, would if be possible to consider using connectivity manager as an user manageable option (or put maximum check delay (20min now) an option instead)? I have a use case, where the client device is offline important part of the day, and I'm looking for a setup, where I can get notification (without requirement to check for them manually) even when connection is restored for some shorter period of time. Thank you.

[jmattheis]

The connectivity manager didn't reconnect in some cases, so I don't think this would fix your issue. Decreasing the max. check delay sounds okay'ish, and it's probably a pretty small change. Could you create a new issue for this?

[RobertMe]

I'm a bit late to the "party", but anyway.

I installed Gotify yesterday. But during the night I set my phone to offline (/airplane mode) and that's when I noticed this connectivity "issue" (i.e. "Connection lost, will try in 20 minutes"). But for me this "feature" would be a deal breaker, first off because it obviously means that in the morning it will take up to 20 minutes before new notifications are received (and second off because it will drain the battery by waking up every 20 minutes while it can't operate anyway).

@jmattheis , you mention issues with the connectivity manager for this not being implemented (anymore). But to me this seems like an implementation / app issue. As for me both the FairEmail and SyncThing (/SyncThing-Fork) apps never have had any issues with this over the years I have been using these. As soon as I turn off airplane mode both these apps "wake up" and start "doing their thing" (checking for mails / synchronizing files). For neither of these apps I have ever seen that they don't work immediately after disabling airplane mode (noticable because these too have persistent notifications which are on-screen when I toggle airplane mode). So if this didn't work in the Gotify app to me it would seem either like a bug in the Gotify app or usage of a different Android API (and the one being used by Gotify possibly being bugged).

[jmattheis]

@RobertMe since my last comment there were some changes in the reconnect logic, namely #288. gotify/android should automatically reconnect when network is available.

Regarding the battery drain when in airplane mode, this can probably be improved.

[RobertMe]

@jmattheis Thanks for your very quick response (and sorry for my late reply). I missed that some form of handling for the device being (re)connected to the network was added again.

I observed the behavior after disabling airplane mode for a bit the last couple of days, and noticed that after disabling airplane mode the reconnect interval actually increased (so it might show "retry in 15 minutes" and after disabling airplane mode it would show "retry in 20 minutes"). But if I then opened the app it would be connected immediately.

But I just checked the logs, and it weirdly was showing that it couldn't resolve the domain name. So I debugged the network traffic, and the explanation for this is that only a request for an A record is send, while my Gotify instance (/reverse proxy) is only connectable over IPv6 so it should send an AAAA request. So the problem I'm seeing is most likely related to the app trying to reconnect too fast 😄 Meaning that the phone is only connected over IPv4 yet. For the earlier mentioned apps, FairEmail connects to an external server which is reachable over both IPv4 & IPv6 so both A and AAAA should/will just work fine, and SyncThing connects using a hardcoded IP(v6) address so doesn't use DNS. But..., I'm also seeing DNS queries for my local Home Assistant, which is hosted behind the same reverse proxy so has the same issue. But there seem to be 2 tries. There is an A query (which also fails), and a bit later an AAAA and A query, for which the AAAA query then succeeds.
I've also looked into the code of these apps. And sadly I haven't found how the Home Assistant app does this (I searched for ConnectivityManager, but got no hits). In the case of FairEmail it listens for far more changes than the Gotify app currently does. Where Gotify only listens for onAvailable, FairEmail also listens for onCapabilitiesChanged and onLinkPropertiesChanged which might be relevant. At least the LinkProperties also contain information about the IP address(es) of the link so will probably also trigger when an IPv6 address becomes available. And in case of Syncthing-Fork it (only) listens for the ConnectivityManager.CONNECTIVITY_ACTION intent. Which maybe slightly differs in when it is broadcasted? Or that app just handles the retry interval after a network becomes available differently.

Otherwise it might be an idea to at least lower the reconnect timeout after the network connects / switches / ...? I.e.: if the connection is down and a retry is scheduled in X minutes and a network becomes available I think it would be better if a possible reconnect attempt was at 60 seconds (or ever shorter period in this circumstance?). As obviously after connecting to a network a lot of things are changing / have changed so retrying more quickly might solve some issues. Where currently it seemingly retries and when that fails just keeps increasing the retry interval (so from the example of "would retry in 15 minutes, but because of failure on new network connection increases the retry to 20 minutes" while my proposal would be "if the retry timeout is at 15 minutes, and a network becomes available, reset the timeout to (for example) 10 seconds so that in case of a failure it retries sooner").

[jmattheis]

Yeah, we can probably improve this. listening on other events than onAvailable sounds oke.

[RobertMe]

A couple of days back I modified the code to listen for onLinkPropertiesChanged as well. And this does seem to work perfectly fine, and fixes my issue (and the persistent notification updates at exactly the same time as the Home Assistant notification). So I'll try to create a proper PR for this over the weekend.

I'm not sure if onCapabilitiesChanged is needed as well, but might not hurd to do it. I seem to remember capabilities also contained information about a captive portal. So it might be that when connecting to a public network, with captive portal, a capability change indicates that the network is actually usuable (after the captive portal has been "filled in"/"accepted") and thus enabling to connect to, in this case, the Gotify server from that moment onwards. (While in such case I think the link properties will not change as it shouldn't lead to a new IP / route / DNS / ... which from memory are the link properties).