Library State; OK to use?

[avluis]

Hey there!

I have been tracking down a way to add support for external SD Card storage and by following SO, taking a few looks at the sample code, and then ending here.

How well does the library mask the annoyances of saving files on KitKat and Lollipop?

I'm not too worried about storage permissions since I had to research how to implement that properly in order to move my app into the next API level, but with the glaring issue of not being able to write to external SD Cards on anything Google idiotically limited - which they ended up fixing in 6.0 - to a certain degree 👎

[rcketscientist]

KK is a lost cause. They neglected to put any API at all in KK to remedy the sd card lock. Users have to root to undo that disaster on their end.

What the library excels at currently is masking the annoyances of the Document API as well as patching some glaring issues. There are two aspects. One is UsefulDocumentFilewhich patches many flaws in DocumentFile, consolidates documents and trees into one system, and allows creation of documents from intermediate trees. This can be used as a stand in replacement for DocumentFile without use of the Activity aspect.

• A huge flaw in DocumentFileis that you can only generate from a root, so if a user wishes operate deeper in that tree you couldn't simply save that Document URI for resume etc, you needed to save the root, the tree, and traverse from root to desired tree.
• On that note there's also a functional getParent which doesn't exist for DocumentFile. It uses some URI tricks to determine the parents, so it's not guaranteed to work if a provider doesn't follow the current Document URI format, but it's better than nothing. This way to you don't always have to traverse down from roots using findFile which can be awfully slow.
• If you need access to multiple file aspects it requires multiple provider calls which is a massive overhead, so there's also a shortcut to pull all data at once (getData), speeding up any call to more than one file aspects (length, canRead, canWrite, lastModified, etc)
• The factory is also smart enough to determine document/tree/file, so no need for multiple factory instance constructors.

The second aspect is the DocumentActivity. This addresses that if a user doesn't have permission for a file (never got it, lost it, revoked it manually) when you attempt write you'll have to ask for permission breaking the Android life cycle and interrupting the write task. To a user this is jarring since they would expect to have the write action occur after they grant permission, but the action (and app) was interrupted to request the permission and the action would be lost. This adds an infrastructure to capture the permission activity results and resume pending write actions with a bit of wiring on your end. This is still a bit rough around the edges, but it fits my needs atm and I'm still using it in production code.

You can start with UsefulDocumentFile and if you have complex writes that you wish to automatically resume you can later integrate DocumentActivity, they can be used separately.

If anything isn't clear let me know. I planned on adding all this to the readme, but once I had it stable I dived back into actual app code, so I have no problem elaborating since it'll all end up in the readme.

Also, I'm pretty sure there weren't any improvements to SD cards in 6.0, just the lockdown of USB storage (with a half-ass Document API implementation). Been a while since I read about it though.

[avluis]

Thank you for going into detail, just what I needed to get started.

In regards to Android 6.0, I don't mean improvements per se, what I meant was expandable storage introduced with it - doesn't solve anything if a user decides to keep their SD Card untied to their phone, but fairly painless if they go ahead and format.
I make use of this on a Moto G3 to get around the measly 8GB onboard.

[rcketscientist]

Ahh yes of course, yah I have a Nexus and a Samsung tab (ie: never updated)
so haven't had a chance to play with it. Feel free to look for help here
and I welcome any PRs.
On May 11, 2016 19:01, "Luis E Alvarado" notifications@github.com wrote:

Thank you for going into detail, just what I needed to get started.

In regards to Android 6.0, I don't mean improvements per se, what I meant
was expandable storage introduced with it - doesn't solve anything if a
user decides to keep their SD Card untied to their phone, but fairly
painless if they go ahead and format.
I make use of this on a Moto G3 to get around the measly 8GB onboard.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1 (comment)

[rcketscientist]

Did you have any success with the library? I'm curious how easily it plugged in and if it fit your use-case. It's easy to have tunnel vision designing something so niche.

[avluis]

Hey there - I haven't gotten to the library yet as the app I have to work with needed plenty of structural changes to get it to where I currently have it now.
I have a build to release to the public once I consider it stable and then I will be working on the library.

No worries though, I will keep you posted as to how I got about implementing this library.

[avluis]

@rcketscientist I've been playing with the library lately -- and it's working for the most part.
Though I'm starting to see the big issue with SD Card support on a much bigger level.

Also, the library does not seem to be able to distinguish between a directory in an SD Card, so you must select the root directory in order for it to be able to write to the SD Card.

I've been getting some experience with libraries working with AppInto, so I plan to bring whatever improvements I can throw at this library into a PR.

[rcketscientist]

Elaborate on the big issue?

I'm on vacation till 8/18 but I'll try choosing a child as a root
permission on sd when I get back.

Theoretically you should be able to so. To be clear: You can't write within
the specific folder selected, or the parent-child navigation (which is all
custom) doesn't work?

The former would actually likely be a Google bug, I've submitted quite a
few related to this system. The latter would be on my end most likely; if
so start a new issue with more details please.

On Aug 4, 2016 20:06, "Luis E Alvarado" notifications@github.com wrote:

@rcketscientist https://github.com/rcketscientist I've been playing
with the library lately -- and it's working for the most part.
Though I'm starting to see the big issue with SD Card support on a much
bigger level.

Also, the library does not seem to be able to distinguish between a
directory in an SD Card, so you must select the root directory in order
for it to be able to write to the SD Card.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD1urjTMvHiYkHo1lfeYbOF7iDcbasVZks5qcjgVgaJpZM4Ib8z4
.

[avluis]

Oh, no sorry -- I've should've written that a bit clearer.
What I meant was that unlike a typical file picker for internal storage, first you need permissions for the SD Card, which means that granting permissions require navigating to the root of the SD Card, and not just directly to the folder instead.
This is just my observations from making use of the sample application.

To clarify further, it is your first point -- if I create a directory and choose that when requesting permissions, I cannot write to this directory.
But choosing the root directory of the SD Card, then writing there is not an issue.

In another note: I have some experience with the following library, and it is already integrated into the application I'm working on -- I will most likely be merging relevant functionality from each application, as I see fit, or from whichever works proper.