Or maybe it is only me?
When I’m clicking a link to a community on the instance I’m logged into (Lemmy.world), the community opens in my web browser rather than in jerboa. Given, this is annoying especially when I want to subscribe to that community.
I should note that I’m using a url checker app so this might be the reason for such behavior.
Only for external links opened through intents. Within the app, you are free to intercept all link opens.
Which is what OP is inquiring about, redirecting external links through intent (clicking link in a web browser and having them open in Jerboa).
That’s not how I interpreted it - I understood it as OP being logged in through Jerboa, and then clicking a community link, and subsequently having it open in the web browser, in place of opening in Jerboa.
This is my biggest frustration as I try to find new communities, via the NewCommunities community. Each link opens the browser, which for some reason continuously has me signed out, so I cannot join easily. 😵💫🫠
And this is an even bigger problem on communities on other instances, since you are not only signed out, you don’t even have an account there. So you are forced to go back to your instance and search for it, hoping that it is seen through federation. imho what should happen in that case is that Jerboa should “adapt” the URL so that you see the community as from your own account’s instance. So if I click on a link to blah.ml/c/blahcommunity, that should actually open lemmy.ml/c/[email protected]. Hm, but actually it shouldn’t do that because it should just open the community directly in Jerboa. But that would be second best.
would this be able to be bypassed if you add a link to open by default that redirects to the actual link?
So how I would implement this would be to instead of firing an intent directly on tapping a link, instead have it defer to a service where link handlers are registered. The service would check if there are any interested handlers for the provided link - if yes, it would be the thing opening the link. If not, the default path of opening the link would activate
The functionality would then be implemented by registering a link handlers for all Lemmy-instances the app wants to handle (this can be fetched remotely, with a fallback to a local well-known list).
This design could then be extended for an arbitrary amount of link handlers. You could add one for YouTube-videos that opens the YouTube-SDK, one that opens images in an inage-screen, one that opens videos in a video playback-screen, etc.
I dont really know how HTTP Requests work but wouldnt it be possible fo Jerboa to open all Links with an in app Browser and checking for a lemmy flag in this request? I imagine it can be janky if the in app browser first opens a new window and falls right back to the app but if this is possible, there would be no need to have a never complete list since everey instance will have this flag.
Sorry if i wrote nonsense, just an idea
Substitute ‘in-app browser’ for ‘service’ in your sentence and it says essentially the same thing as what my sentence did.
So yeah, not nonsense - totally sensible.
Oh, i understood your way of doing it as a service that checks a list (remote or local) if this is an instance, where the list needs to be updated regulary, thats why i wanted a flag that tells the service “Hey, i am a Lemmy instance!” when it checks every link before opening.
But yes, your implementation would be a future proof idea that would work like a charm!
you should post on their GitHub 👀