Consider mechanism to dynamically change next retry for disconnected / suspended states

[mattheworiordan]

Instead of relying on the configured retry intervals, we should offer a way for developers to hook in and define the duration until the next retry.

┆Issue is synchronized with this Jira Task by Unito

[paddybyers]

Instead of relying on the configured retry intervals, we should offer a way for developers to hook in and define the duration until the next retry.

... or some other programmatic way of controlling retries, eg exposing an interface for initiating retries directly.

[mattheworiordan]

exposing an interface for initiating retries directly.

client.connect()?

[paddybyers]

client.connect()?

well, quite.

What I'm saying is that we could think of a ClientOption which is simply connectionStrategy or something, which completely replaces the default strategy and default retry intervals. That object would need to get events on disconnection, suspended, etc, and would need to have an API to retry a connection, fail a connection, etc.

But - would the events need to include anything not already included in the ConnectionStateListener interface? And would the API need to include anything other than what we already provide?

[mattheworiordan]

My preference would simply be that the use subscribes to the events they want to change the default behaviour for, and call a method such as connection.setNextAttemptInterval(ms) and that's that.

[SimonWoolf]

My preference would simply be that the use subscribes to the events they want to change the default behaviour for, and call a method such as connection.setNextAttemptInterval(ms) and that's that.

Agree that the user can just subscribe to connection events. I'm not sure we even need an api to tell the client lib to reset the attempt timer -- could we not just have a autoReconnect client option that someone can set to false to just disable all connection retry attempts? (Or maybe just allow null values for disconnectedRetryTimeout and suspendedRetryTimeout for the same result). Then it's their responsibility to listen for disconnected and suspended events and set their own timers to call client.connect() whenever they like.

[mattheworiordan]

Yes, null or zero values (where nulls are not supported) would work and keeps things simple with no change to the API, only docs & spec

[tcard]

Zero values for *RetryTimeout sounds good to me.

[mattheworiordan]

@SimonWoolf when you are looking at other spec items, mind doing a PR for this too based on 0-10?

[paddybyers]

I suspect that the customer would like to leave the job of sleeping and waking to call connect() to the library instead of doing it themselves. For more extended waits, for example, the library has the option of the option of using power management APIs to control how the device is allowed to sleep whilst waiting.

[mattheworiordan]

What are you suggesting then @paddybyers?

[paddybyers]

What are you suggesting then @paddybyers?

I don't have a concrete suggestion. The idea that the client returns/sets the delay and the library handles the timer might be preferable, for a customer that doesn't want to have to deal with those complications. The option of just setting the timeout to zero, and leaving the app to handle it completely, is the simpler API.

I think if we propose the latter approach, which we seem to be settling on, then we should anticipate that possible pushback. It's possible also that there's an unstated expectation coming from experience with other mobile analytics libraries.

[sync-by-unito]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2829