[WIP] deep refactoring search

[theScrabi]

This PR will ulitmtively removes the legecy SearchEngine and replace it with a propper SearchExtractor. Also It refactors URLIdHandlers. They are short UIHs (UrlIdHanlder) and QIHs (QuerryIdHandler) now. These are Immutable and must be created by UIHFactories QIHFactories which must be overwritten by the service. QIHs can store more information than just the Id. They can also accept sort and filter parameter, which is why they are not simply called UIHs. The QIH where necessary to for supporting SearchEngineExtractor. They will also make it possible for other ListExtracotrs to let the content be sorted in the future.

[karyogamy]

In general, good job =D

I think the new structure is pretty good. Though my IDE is highlighting (on IntelliJ/AndroidStudio, analyze -> inspect code) a lot of things that can be improved, it might be a good idea to do on a separate PR. Also, there are some failing unit test that might need some look into.

[karyogamy]

Please don't abbreviate class names. Since this is a library, we should try to make names clear, even if they are long so they don't confuse the users. This is especially the case for UIHandler, I thought we are doing something graphical in the extractor when I saw this initially.

In case of UrlIdHandler, I think we should think of a different name for it, such as LinkHandler, because this now also contain other data. Similarly, we can simply drop the Handler suffix since now the class is just a pojo and doesn't handle any logic.

This way, UIHandler class becomes Link class, ListUIHandler to ListLink and SearchQIHandler to SearchQuery. What do you think?

[theScrabi]

I agree. I will rename them.

[karyogamy]

Ideally, I would keep this as an interface and use default method for fromUrl and others which can be used by the implementor. Always go for composition over inheritence when the code is still simple to refactor ;)

This also means we might want to do to same to UIHandler and make it implement a Linkable that only has the originalUrl and url and Identifiable that contains the id. This way, ListUIHandler no longer have to extend UIHandler, and instead implements Linkable, Identifiable and Filterable.

This gives us more flexibility later down the road and also helps addressing potential misuses where the id in ListUIHandler is used as a holder for the search query string in SearchQIHandler, which would be decoupled from ListUIHandler and instead implements Linkable and Filterable and the search query becomes a field.

I understand this is probably a lot of work, so I'm fine with keeping the inheritance structure for now. However, I recommend having it done right now as there will likely be a time when more complex url uses arise when simple inheritance will not be enough.

[theScrabi]

The reason I did it this way was because I didn't want this structure in order to ensure UrlIdHandler stays final:

UrlIdHandler handler = new YtUrlIdHandler();
handler.fromUrl(url);

Since this is not possible:

UrlIdHandler hanlder = YtUrlIdHandler.fromUrl(url);

because you can not override static methods I went with a factory/builder structure.
You are right tho the idea with the interfaces sounds cleaner, tho I would stick to the factories.