Introduce ResolvableSource - #18
Conversation
| * @param url The [HttpUrl] to test. | ||
| * @return `true` if this source can resolve the URL, `false` otherwise. | ||
| */ | ||
| fun canResolve(url: HttpUrl): Boolean |
There was a problem hiding this comment.
Just make getResource return Resource? and remove this method.
Source might need to make network requests to know if they can resolve the thing. Most cases when they instantly return false, the suspend won't cause overhead.
There was a problem hiding this comment.
this is mainly for early filtering on app side. should just be a regular regex check on source side
There was a problem hiding this comment.
getResourcealso needs the regex/URL path check to extract path segments. Your API forces extensions to repeat this logic.- The app just calls the first then the second. What's your use case that only calls the first one?
There was a problem hiding this comment.
Purely for UX reason. When resolving the URL of Source A and B I would rather not show the user Source C with "No result found"
There was a problem hiding this comment.
Returning null is equivalent to "can't resolve". No results found should be conveyed by throwing an exception.
There was a problem hiding this comment.
What you're proposing is that we show user Source A, B and C. When Source C returns null we remove it from the list. Later Source A and B resolves to Manga A. I don't think that's a good UX. There should be a way for the app to filter out sources that 100% will never resolve the URL
There was a problem hiding this comment.
Running regex/path URL checks for a lot of extensions is also a time-consuming I/O task. You still need a loading screen before showing a candidate list. I think it's possible to achieve the same effect by checking if the coroutine returns early (no suspension done).
The two-method solution will require extension developers to write duplicate/boilerplate code and should be avoided if possible.
You also need to document what developers should do in the KDoc, like checking for the domain, etc, and when to throw what exception. How do they convey "this URL is for this site but doesn't resolve to a manga/chapter"?
| * @property manga The resolved manga metadata. | ||
| * @property chapter An optional specific chapter of the manga. | ||
| */ | ||
| data class Manga( |
There was a problem hiding this comment.
Don't use data class. The methods added are useless, and SManga/SChapter are not hashable either.
There was a problem hiding this comment.
Why did we add it for MangasPage then...
There was a problem hiding this comment.
That's an app-side implementation. Extensions should not rely on this. That's why we need to unmark MangasPage in 1.6.
2 participants
No description provided.