Will Antennapod integrate the updates made in Podcini?

[pobidcabisthoebirer]

Podcini is an opinionated, but also updated fork of Antennapod.

It removes quite a bit, which is not necessary, but it also builds Antennapod against the latest dependencies, and updates core components.

Will this land in Antennapod too?

[ByteHamster]

Short answer

The latest is not always the greatest. AntennaPod is a bit more conservative with upgrading dependencies. We only upgrade them if it makes sense, and don’t upgrade them if it doesn’t make sense.

Long answer

AntennaPod has one file with all the versions and upgrading just amounts to changing a number there. So in itself, upgrading dependencies is usually a very simple and quick task. So you might ask why we don’t just do it. The reason is that upgrading dependencies means much more than just changing the number. AntennaPod runs on a large number of devices from different manufacturers, using different Android versions, and even custom ROMs. In order to ensure that a dependency upgrade works well on all these devices, a lot of testing is needed.

For example, through testing we know about a dependency upgrade that has no visual changes but makes the app harder to use for blind users with screen readers. So we deliberately do not upgrade that dependency. (Podcini does upgrade it, and I doubt that it did any real testing of those upgrades)

Therefore, our policy for upgrading dependencies is a bit more conservative. If a dependency upgrade fixes a bug or adds a new feature that is relevant to AntennaPod, we do the upgrade. In general, as long as it is useful to upgrade, we do so. However, we don’t upgrade just for the sake of having a larger version number somewhere in the code. If upgrading the dependency does not make any difference for AntennaPod, we don’t upgrade. In that case, it just risks introducing bugs without having any real benefit.

Updating core components

I’m not 100% sure what you mean with that. If you are talking about changing the programming language to Kotlin, here are a few thoughts. Changing a project to Kotlin is a single click in Android Studio - it automatically converts everything. (If one wants to preserve the version history, it is slightly harder but still not a big deal. Note that Podcini does not care about preserving the version history).

If you take Java code that has a bad code structure and up convert it to Kotlin, then you get Kotlin code with a bad structure. So the change of programming language doesn’t immediately make anything better. Since about 3 years, at AntennaPod, we are working on improving the code structure to use modules in order to better enable automated testing. The modules also make sure that when adding new features, contributors have easy access to all relevant files close together. At the same time, the modules make it deliberately harder to create bad code because it prevents cyclic dependencies. Podcini removes all those modules again and throws everything back into one large folder.

While Kotlin is growing a lot recently, the number of Java developers is probably still larger than the number of Kotlin developers. In fact, I would say that most developers who know Kotlin also know Java. So keeping AntennaPod on Java for the moment ensures that as many developers as possible can contribute to make AntennaPod better. Given that AntennaPod is a community project where quite a few contributions come from new developers who are not as experienced yet, I think this is an important point.

To summarize, in terms of code structure, Podcini goes one step forward and 2 steps back. If you like the visual changes of Podcini, you are of course welcome to use it. But I wouldn’t care much about any of the internal changes – even though that seems to be its main selling point.