Gene Burrus again raises a key point. Platform companies change APIs frequently as a method to deliberately disadvantage other developers, forcing them to play catch up to have a good user experience. #DMAWorkshop

That totally clicked for me, that's how I have been feeling about working with the Storage Access Framework APIs in Android. On top of that, Android APIs prefer cloud services. Guess what: #Google #cloud services are built-in defaults for those APIs on all the Google devices.

@eighthave The restrictions on storage were created because bad apps/SDKs leaked data from shared storage once they got initial access (e.g. to some media file or to download resources).

@rene_mobile I understand why they were created, and I think the core idea is good. But the way it has been rolled out has been painful to a lot of developers, especially if the app isn't just doing a simple tie-in to a cloud service. My experience is that every other OS release introduced new and often conflicting APIs and requirements making it very difficult to make a UX that worked across the currently supported releases.

@rene_mobile And also, I think the right solution is to keep the bad apps out, that's what we work to do in #FDroid. Then users have the freedom to use apps that require flexible access to the external storage to provide their features. The SAF changes felt to me to be a way to cut out apps that do media/app sharing device-to-device, instead of via cloud services. Device-to-device data exchange is very important in places where data plans are expensive and measured in the 100s of MB per month

@eighthave But such an app could act as a storage provider itself, right? Thinking about Syncthing etc.