Facilitate changing instance about libretube HOT 7 CLOSED

Hey akano12 👋 👋

I agree that the information is there (although a lot of people don't read it). However, for new comers, it is not always easy to navigate through it.

1. It's their fault for not reading.
   Also It's not the devs job to spoonfeed everybody, there are tens of thousands of active LibreTube users and i haven't seen anyone asking how to switch an instance.

2. How would you know if an instance isn't working? (I'm aware of couple of ways, but asking in the approach you took)

from libretube.

Hey @akano12 👋

Considering your points, I thought about a new behaviour that does not block the loading. It just informs the user that the loading is taking more than it's supposed to, and makes it easier for him/her to change the instance - sample below:

That being said, I think the experience is still not great, since the user has no easy way to reload, without the swiping that I did on the second 16 (the reload is necessary because the ongoing request have the old instance, only by reloading we send the new one).

from libretube.

There's already a flag next to each instance, an explanation what is an instance and in addition to the newly added uptime percentage.

Hence i don't think there should be a change (especially when everything is explained on the first app launch)

from libretube.

Hey akano12 👋 👋

I agree that the information is there (although a lot of people don't read it). However, for new comers, it is not always easy to navigate through it. They just arrived on the App, a look of things to learn. I propose that we guide them, into a working instance. What I propose is something along these lines:

from libretube.

Pretty good addon, i have tried implementing this months ago with same snackbar method(embedded button in it) which will redirect to instance setting list but couldn't complete it unfortunately.

from libretube.

I haven't yet dived into that; in the sample, I just added a timeout of X seconds to the requests. If you could share those ways it would be great 💪

from libretube.

I haven't yet dived into that; in the sample, I just added a timeout of X seconds to the requests. If you could share those ways it would be great 💪

I truly find there's no optimal way to do this.

1. Simplest one would be checking response code received from the instance on app startup, when switching tabs and when doing any action that requires communication with the instance (almost every action in the app).
   This will cause a DoS considering the large amount of users (let alone the number of piped web users) and Spotube and whatever front-end apps that use piped instances

2. The way you did, wait for X seconds timeout. Very impractical on slow networks which could take X+1 seconds to load content.

3. What i suggested in an old issue.

Store currently selected instance in shared preferences, fetch list of available instances on app startup and check if the selected instance is available in the list of fetched instances. If it's available do nothing, else notify with a toast.

But take it from me, it's better to leave things as is because whatever logic you want to implement, you have to implement it for each action that communicates with a piped instance. Also bnyro briefly summarized why such implementations cause problems more than advantages
#3924 (comment)

from libretube.