June 19th, 2019 posted by Jabo
When I made the decision to introduce Jnes back to the Google Play store in early 2017, I knew that making it free to download and missing two years of Android platform changes would make it an uphill battle to provide a stable build of Jnes, but I didn't quite anticipate how much. The first decision to make was deprecating support finally for Gingerbread 2.3 and supporting Jelly Bean 4.1 and higher. Gingerbread was old, often single-core, and OpenGL never worked well there.
Removing this code simplified the platforms to test, but it didn't make up for the the amount of time spent with the Storage Access Framework. The SAF as it is called, was introduced in Android 4.4 KitKat as an alternative way to access storage compared to the standard Java File class. The idea being that by introducing another abstraction to files and folders based on a Uri, Android could provide better security and extend storage beyond the local file system to any provider. To me at least this didn't become usable for general purpose storage browsing until Android 5.0 Lollipop with the introduction of the ACTION_OPEN_DOCUMENT_TREE flag which allowed developers to make entire directories available to applications, like Jnes.
While I successfully ignored this for many years! It became obvious in 2018, when Google Play required developers to target newer versions of their SDK, that most newer phones were preventing access to the file system outside of the Storage Access Framework, which of course broke Jnes for Android. Over the course of more than two months, and a lot of frustrated users, I was able to switch over to the new storage framework. The rewrite was definitely worth it as the new storage framework, combined with new user experience on startup in Jnes made things much easier.
I'm happy to say that the Jnes release from April 2019 marked a stable chapter for Jnes on Android. If you gave Jnes a try previously and ran into problems I would suggest trying it out again, it may work better. Overall developing anything of significant quality for a mobile platform is a lot of work, I will be avoiding it for any projects I work on for personal enjoyment.
Lessons Learned
- I didn't really ever think about how much storage access was there until I had to rewrite it all
- If you need to support older phones you need two sets of storage code
-
The helper class for DocumentFile is generally not as easy to use as Java's traditional File class
- SingleDocumentTree is missing functionality that you may need
- Every storage provider may decide to just not implement some functionality
-
You can't rely on being able to parse the storage Uri, although most people rightfully try to