Antennapod: Support for Podcast Index namespace "Funding" tag

[keunes]

Checklist

• [x] I have used the search function to see if someone else has already submitted the same feature request.
• [x] I will only create one feature request per issue.
• [x] I will describe the problem with as much detail as possible.

System info

App version: 2.0.2

App source: Google Play

Feature description

Problem you may be having, or feature you want:
Most podcasters do great work, and some users might want to support them. Since the removal of flattr AntennaPod has not have a function to support podcasters financially.

The Podcast Index has introduced a namespace to enrich the RSS standard. It introduces a new 'funding' tag, in which podcasters can provide links to payment options. More specifications here.

Suggested solution:
It would be great if we support this tag in its most basic form, meaning:

• On the podcast 'information' screen, add a 'Funding' title/section
• If the tag is not present, display the text "The creators have not indicated any way to financially support their work. If you want to donate, contact the podcast creator(s) and suggest them to include the funding tag in their RSS feed."
• If one or more tags is present, list each of the tags on one line. (They would be links that open in the phone's default browser.)

Screenshots / Drawings / Technical details:

• Tag: <podcast:funding>
• Parent: <channel>
• Attributes:
  
  
  
  • url: The URL to be followed to fund the podcast.
  
  
  • platform (optional): Identifies a payment or funding platform for the podcast. Service slugs should be recorded here in the repository.
  
  
• Example: <podcast:funding platform="paypal" url="www.paypal.me/myshow">Support the show!</podcast:funding>

[tonytamsf]

I would support adding a 4th tab in the playing screen for funding.

Or add the funding information in the show notes tab.

[ByteHamster]

Funding seems to be related to the show, not an individual episode. I therefore think that it would be better to have this on the podcast info page than on the player screen (which is about an individual episode).

[keunes]

(Personally I feel like this feature request is the minimum we should do. But once that's implemented we can maybe think of ways to make if more prominent/convenient.)

[ByteHamster]

By the way, there already is an existing standard for dealing with payment URLs: <link rel="payment" href="...">. AntennaPod already parses and stores that one because it was used for Flattr support. It currently does not display the URL, though.

The implementation of the funding tag could reuse the same database column (maybe separated with newlines if there are multiple URLs).

[keunes]

The implementation of the funding tag could reuse the same database column (maybe separated with newlines if there are multiple URLs).

Would that be possible while supporting the full podcast namespace spec, which includes the specification of a text that can be displayed?

[ByteHamster]

I suggest to store one URL (+maybe text, separated with a special character) in each line of the database field. If there is already something in that field, it will probably just work. Doing this with an extra table like in the textbook examples seems a pretty big overkill to me. Additionally, that makes updating harder (we would run into the same problem as with chapters in #4212)

[keunes]

maybe text, separated with a special character)

Actually I don't care so much about the full spec, just abut the text :P Maybe instead of a single character we can use a series of characters? Like |pi2ap| (podcast index to antennapod) - to avoid issues if a podcaster happen to use the one character we pick?

[ByteHamster]

Actually I don't care so much about the full spec, just abut the text

Yeah, this was mainly to the person who picks up this issue :)

Maybe instead of a single character we can use a series of characters?

If we use a character that is not allowed to be used in titles (eg. the ASCII record separator), it should be fine, I guess

[widlok]

I can look at this feature, i have some questions about implementation. I found code in the method handleSuccessfulDownload where feeds are updated. Where is code for marshaling requested podcasts from ITunes? I assume there will have to be added mapping from xml funding to Feed class payment class variable. Idk if its just me, but for some reason Feed seems like an unfortunate name for Podcast.

[antennapod-bot]

This issue has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/ability-to-skip-ads-in-the-podcast/212/12

[widlok]

Tbh advertisements in podcast i listen are not very long and don't ruin the experience. I think its unfair to podcasters who do it for free to block their ads. After all if im really frustrated with ad i just skip it, its not like other platforms(ex. Youtube vids) where they serve the overlay and you are forced to watch it.

[ByteHamster]

@widlok:
I can look at this feature

Nice! Please keep in mind that this task is a bit difficult. I suggest to start with things labelled good first issue first.

Where is code for marshaling requested podcasts from ITunes?

Have a look at the classes NSITunes and NSMedia. This change would need a new class NsPodcast.

Idk if its just me, but for some reason Feed seems like an unfortunate name for Podcast.

Feed is the technical term for the RSS file that the podcast is published in. I think the name is fine :)

[widlok]

Thanks for answer @ByteHamster . What was the reason to start off that feature, was there any research done beforehand? Tbh i didn't see any other podcast player ( I looked at top 6 in google play) implementing this feature. I don't know if Itunes support tag for funding(all of the podcasts i checked there was no tag) and Antenapod pulls podcasts from them, this would mean none Itunes podcasts will show this option. I'm worried that this tag is not commonly used by podcasters and its not going to help them get donations.

Nice! Please keep in mind that this task is a bit difficult. I suggest to start with things labelled good first issue first.

I actually did one good first issue #4610 :)

[keunes]

What was the reason to start off that feature, was there any research done beforehand? Tbh i didn't see any other podcast player ( I looked at top 6 in google play) implementing this feature.

Firstly there are discussions about implementing a system to automatically skip ads - we want at the same time to support creators.
Secondly, this tag is part of the very recent Podcast Index namespace. See also the link in the OP. We want to implement it to create support for this new namespace - being early adopter in an otherwise chicken-and-egg story.

I don't know if Itunes support tag for funding(all of the podcasts i checked there was no tag) and Antenapod pulls podcasts from them, this would mean none Itunes podcasts will show this option. I'm worried that this tag is not commonly used by podcasters and its not going to help them get donations.

I suspect that iTunes indeed doesn't support this tag. But they don't have to: it are podcasters that need to include it in their RSS. They can do this regardless whether they are in iTunes or not.
And it's logical you didn't see the tag in use yet; see second comment above.
If the tag is not used by podcasters there's no still no need to worry, because there's no harm done implementing this :)

[ByteHamster]

I don't know if Itunes support tag for funding(all of the podcasts i checked there was no tag) and Antenapod pulls podcasts from them, this would mean none Itunes podcasts will show this option.

iTunes is just a directory. It lists RSS feeds. After subscribing, AntennaPod is completely independent from iTunes: The feeds are loaded from the publisher's websites.

[widlok]

iTunes is just a directory. It lists RSS feeds. After subscribing, AntennaPod is completely independent from iTunes: The feeds are loaded from the publisher's websites.

I intercepted some request in AP it looks like it still pulls data for feed on subscribe overlay from iTunes. Regardless of that, it doesn't answer my question, do you have examples of popular podcasts using funding tag? I was going to implement this feature but if its not used by creators it will only cloud interface with more or less useless feature. Do other podcast players implement it - i couldn't find any.

Edit: sorry didn't see first response by @keunes :)

Generally you want to allocate time on most useful features :) but i agree if that's new PI namespace like you said - podcasters will slowly adopt - being early adopter will work both way, encourage podcasters to take advantage of this tag, and AP will be more appealing to users. But if we add new UI item that is not used it becomes counter-productive and users get overwhelmed.

Regarding Ads i don't know what is AP mission/policy but i wrote it in other thread, in my opinion its unfair to podcasters that do it for free to work way around and block ads. I never came across annoying ads, and ultimatelly if I am in hurry i just skip it manually. In comparison to frustrating TV ads or overlay Youtube ads where you have to sit through them.

[keunes]

I intercepted some request in AP it looks like it still pulls data for feed on subscribe overlay from iTunes.

Can you specify what kind of data AP pulls or identify where/when it does so?

i agree if that's new PI namespace like you said - podcasters will slowly adopt - being early adopter will work both way, encourage podcasters to take advantage of this tag, and AP will be more appealing to users. But if we add new UI item that is not used it becomes counter-productive and users get overwhelmed.

Right, we absolutely want to keep a clean interface. Which is why ByteHamster and I often reject requests and do multiple mock-ups to gradually improve the UX.
But a bit of extra text on a page dedicated to information about a podcast to me is not a new 'UI' element - it's an extra paragraph/section to an existing text. We're not introducing new information elements on a screen with a different purpose (e.g. the queue or player screen), not adding new options, not adding new buttons. So I don't think this particular change would overwhelm users, let alone it becoming counter-productive.

But if you disagree and don't want to take this up please say so, to manage expectations (mine and that of potential other contributors). No angry faces, promised ;)

[widlok]

Can you specify what kind of data AP pulls or identify where/when it does so?

I was wrong, logcat doesn't show download http requests it only logs requests to Itunes.

But a bit of extra text on a page dedicated to information about a podcast to me is not a new 'UI' element - it's an extra paragraph/section to an existing text. We're not introducing new information elements on a screen with a different purpose (e.g. the queue or player screen), not adding new options, not adding new buttons. So I don't think this particular change would overwhelm users, let alone it becoming counter-productive.

I get what you're saying. I looked more indepth through PI documentation for new schema, it is only about 1 month old so obviously it will take time for podcasters to adopt it. Now, it looks like they have whole new schema and namespace, I feel like it would be better to implement whole namespace as new class including all tags (along with funding tag). I can do that if you agree with that approach.
Regarding text - if AP really wants to help podcasters, could it be better to implement something more outstanding. There is already icon redirecting to podcaster website, we can add let's say $ sign icon next to it redirecting to funding url. That's what I had in mind when I said additional item.

But if you disagree and don't want to take this up please say so, to manage expectations (mine and that of potential other contributors). No angry faces, promised ;)

I wouldn't think about it any other way :) I'd be happy to implement it.

[keunes]

it looks like they have whole new schema and namespace, I feel like it would be better to implement whole namespace as new class including all tags (along with funding tag). I can do that if you agree with that approach.

I think I'd be all in favour :D But I let @ByteHamster comment on that first. I'm not sure it makes sense, though, to collect all this information in the database (which, consequently will grow bigger), when we're not using it (yet). 'Cause before we can really use it, for each of them we need to think _how_ we can/will use it and how it will integrate in the UI. E.g. how/where would we display soundbites; what would be the relevant use-cases?

Regarding text - if AP really wants to help podcasters, could it be better to implement something more outstanding. There is already icon redirecting to podcaster website, we can add let's say $ sign icon next to it redirecting to funding url. That's what I had in mind when I said additional item.

Ah, I didn't realise you were thinking of this. I like the idea, but I guess a channel can have multiple funding tags (e.g. one for a single PayPal donation, one to become a paid ad-free subscriber). We'd have to account for that (e.g. display a menu when there's more than one entry, with the menu text taken from the tag).

In terms of icon it's a bit challenging. A simple currency sign is not international-friendly (I prefer euro, others yen, pound or dollar). For the charity hands icon is not clear it's about money. I've requested a new icon for our purpose, not sure if it'll be picked up any time soon, so we might have to do with what's out there now.

[ByteHamster]

I feel like it would be better to implement whole namespace as new class including all tags (along with funding tag).

I don't know what exactly you mean. If you mean the namespace parser: definitely (I suggested that earlier). If you mean data storage, I don't agree. PI basically re-invented the wheel - most of their tags already existed in another form. We already have a database location for many of their tags, so we can just use the ones that already exist.

I like the idea, but I guess a channel can have multiple funding tags

I would just add the individual funding tags to the podcast info screen. That's more prominent and maybe leads to more donations :) Also, we can directly display all methods at once.

[widlok]

Are you fine with dependency injection in the project? We have Namespace abstract class, but we don't use advantage of inheritance really anywhere, but in SyndHandler we call all namespaces one by one by where we could use for example Visitor pattern to make it automatic and SyndHandlerwill not have to know specifics of all Namespaces.

[ByteHamster]

Could you please write an example of how DI would decouple SyndHandler and the Namespace classes? I am not experienced with DI - as far as I understand it, SyndHandler would still need to know the list of Namespace classes.

[widlok]

It wouldn't decouple them since they depend on each other and are part of tight structure, Namespaces exist for Syndhandler. If Namespaces had access to Syndhandler, i thought about DI but if there easier way im fine with it, they could register themselves in Syndhandler and Syndhandler won't know about implementations of Namespaces only about that interface. This is an idea, i feel like it will improve code but i might be wrong. Its a cosmetic change but usually when i implement anything in the code i always try to improve it around the change im writting.
Beside DI other option is reflection or one of OOP patterns.

[ByteHamster]

they could register themselves in Syndhandler and Syndhandler won't know about implementations of Namespaces

To be honest, I don't think this is a critical problem. There are more important refactorings to do :) While decoupling could be more generic, it sounds like it will make the code harder to read and debug. The data model (FeedItem etc) needs to know about new elements anyway - we usually don't add new namespaces that are completely independent of the rest of the app.

[tonytamsf]

Is anyone taking this issue? If not, I can give this a try. @keunes ?

[widlok]

I was implementing it but unfortunately i won't be able to focus on it in near future so go ahead @tonytamsf .