Delay refreshAllSubscriptions after timer deadline

[barijaona]

Work around issue #2005 "On system wake, Vienna should wait a couple of seconds until the network connection becomes available before refreshing feeds"

[barijaona]

Vaguely inspired by 0f44c88
😆

[Eitot]

I added a commit to check for network availability.

I think there were two pitfalls with your commit:

1. The refreshImmediately flag is only used to refresh feeds when Vienna starts, it doesn't have any other purpose right now. A user might have this enabled and still run into the problem of On system wake, Vienna should wait a couple of seconds until the network connection becomes available before refreshing feeds #2005 later on. Checking this flag means that the workaround would not have applied.
2. The performSelector:withObject:afterDelay: would also apply when the timer is manually fired (‑fire), such as when the user clicks on the toolbar button, which leads to an (for the user unexpected) delay in those cases where the network is reachable.

I think checking for network availably improves on this. It might be enough to resolve #2005 without making this too complicated for now.

[barijaona]

I reckon there is a problem related to manual refreshes in my initial commit.

@Eitot's additional commit behaves correctly even on macOS 26, but in fact it depends heavily on SCNetworkReachability, which makes it fragile as these functions are deprecated.

I'll push an alternative correction.

[Eitot]

nw_path_monitor is the replacement for SCNetworkReachability, but not available for macOS 10.13. I might have a look as well to see if there is an equivalent function.

[Eitot]

This code path gets executed if the user enabled refreshOnStartup and automatic fetching. This means that your fix isn't applied.

[barijaona]

This is not really a problem, as the issue we have (in at least 99% of real life cases) is with wakes from sleep, which lead the system to re-establish network connections.

This part of code would be executed in the aftermath of a manual launch of Vienna by the user: in most of cases, whether the network has already been established, or you have a more permanent problem which might require another intervention, and just waiting a little more would not help.

[Eitot]

The entire block is executed whenever the timer fires. refreshImmediately is only set on launch or when the user changes the refresh frequency in settings. It makes no sense to refer to it within the inner block because its value will realistically never change. As I said, if refreshImmediately is set to YES (e.g. on launch), then the other code path – and therefore your fix – is simply never executed.

[Eitot]

This applies the delay to every automatic fetch, even for those users that have a good network connection.

[barijaona]

Yes, but as the delay is applied for all automatic launches, subsequent intervals are respected.
Anyway, the offset is within the 10% leeway we have given to the timer.

Let's note that this code is inspired the logic that was implemented in year 2006 by commit 0f44c88 and went away in 2020 as an unexpected consequence of modernization in commit 03a58f0

[barijaona]

So I consider this is good enough and I tend to think that less code means less maintenance 🙂

[Eitot]

The old 2006 code you refer to was only executed on wake-up, so this delay didn't generally apply to every automatic fetch.

I just don't find this elegant and there is no guarantee that a hard-coded delay even reliably fixes the bug. Whether 20 seconds is enough is ultimately just a guess.

[Eitot]

@barijaona: A minimal implementation of a network monitor based on the Network framework (10.14+): https://gist.github.com/Eitot/6ce39a604b67be34036d83d9b25d9e4b