Make providers more abstract

[se-bastiaan]

The current providers seem to be pretty abstract, but some parts in the application still contain parts of previously used providers. Especially error messages. These should be standardized for all providers.

[aldoborrero]

For this usecase I would try to research the way to provide providers as a plugin much in the way that muzei api works.

That way a user can download butter project and install it desired plugins to have different providers (there in settings can configure what provider wants).

What do you think @blazsolar @se-bastiaan ?

[blazsolar]

That is something we should look into and we can achieve this via content providers. I believe that is the way muzei does it.

Altho that should be different ticket. This one should focus on making abstract API for provider implementation. We can than on top of that build content providers to enable that.

I'll create another ticker for muzei like api.

[xaiki]

i'm going to step in again here, what would be ideal is to get a unified way to use providers from butter-providers (https://github.com/butterproviders/butter-provider) it can be runing the JS, runing the js in another thread, running the js in a server, changing the JS to 'something else' ... but we'd need it to be unified

[blazsolar]

I would say this is out of scope for this ticket and would probably be something to look into after 1.0.0.

But since our provider models will be based on JS models so they will be similar and the way we are doing abstraction this should be possible just to add later on and have possibility to run JS, native and content provider media providers.

I'll crete ticket to implement this later on.

[blazsolar]

https://docs.google.com/document/d/1wQDIhOsqCVnEp1XFue-RDA8eh1GBUAZzXSpq3M2Tqt4/edit

This is a general overview of how media providers should be implemented. If we can agree on this ticket can be moved into TODO column.

[aldoborrero]

My question is, do we need to have the implementation been done in js? Although I'm not particularly contrary to that it would be better to have the API in pure Java for Android, right?

[blazsolar]

The API will be done in Java of of course. There will just be an abstraction over API that developers can use to implement JS providers. It will still be Java SDK but it will have possibility to run JS in it.

[xaiki]

i can't stress enough that i'd rather have the same providers on all platforms, because that helps maintainabilty (code change needed in only one place when the provider breaks)

furthermore there is a lot that can be done in java to improve performance.

• we can uncouple the caching/memoizing code so it's done in java on android.
• cross/provider metadata fetching can be implemented in java.
• i'm opened to a provider description language that can be implemented fully in java, but that needs to be the master source for the js version too (and i'm really interested to see how we can solve archive or ccc with that design).

[blazsolar]

@xaiki I can't agree with you on this. Yes there can be JS provider support but that can't be the recommended way to do it.

It will probably never be as performant as native implementation would be, so why force developers to use it. If we do native implementation we can for example have common networking stack and do optimizations on that level. We can just have way more control over native implementation in comparison with JS.

As per doubling the work with provider development. If you take a look at how much work it is spend developing providers and how much for other stuff you will se that provider development time is really small. So we don't get much benefit form this. Also the code size is small compared to other parts.

There is also the case of user experience. Mobile, desktop and especially tv are different user experiences. Yes at the moment they are pretty similar, but that may change in the future. And even now we can already see differences between mobile and tv and also mobile and desktop. So we may even have some parts of providers that will need to be implemented just in case of tv app,

But the way new provider API is designed you will be able to include JS provider just by adding dependency to it. The rest will be handle by us at compile and run time. But at the end you will get better experience if you implement providers natively.

[aldoborrero]

100% for what @blazsolar has commented above.

[blazsolar]

Hard to believe it but this is now done. Well at leas base is done and we have solid foundation to work on it. Media and subtitle providers are finished. Meta providers were removed at the moment as I am not yet sure how to approach them.

For media provider we have 2 implementations one is mock for testing purposes that is only included in dev builds. the other is Vodo provider that was ported from old implementation.

Porting old provider was a breeze. Networking is done by Retrofit and background work is handled by RxJava. We could even make some more abstractions to make it as east as defining endpoint and network model and that would be it. 🎆

For subs we only have mock provider implementation. Open subs or something like that still needs to be implemented and will be part of next milestone (0.6.x).

One thing still missing here is system to easily import new providers. At the moment it is a lot easier than it was as we expose public APi to implement and include providers. It could still be made easier with use of annotation processor but is not a priority at the moment (#228).