1. Stop thinking about paths and files. I know it's hard and seems rather pointless (because it is). There are way better ways they could have done this, but they chose...well whatever this nonsense is. I rewrote over 2000 lines of code to support SAF. If you're doubting whether it's really as complicated to support as it seems to be, stop doubting; it is, you just have to accept that file interaction is like pulling teeth now. 2. DocumentFile has getParentFile BUT it doesn't actually work. What I did was wrap DocumentFile to make it useful (UsefulDocumentFile, clever, right?) 3. I'm not sure what you mean by document id. A document uri has it's AUTHORITY which will tell you which provider will handle it. 4. You would need a reliable getParent, which requires wrapping DocumentFile or a similar utility function that slices and dices document uri. 5. I'm assuming you mean Parcelable which they are not.
On Saturday, January 17, 2015 at 11:35:04 AM UTC+1, Grunthos wrote: > > I have an app that needs to support API 7 through lollipop; until KitKat, > it used 'File' objects to talk to the local file system. I had planned to > use DocumentFile as a simple solution to my problems. However, I can not > see simple ways to do the following: > > 1. Save the equivalent of "path and file"; I used to save the last file > written (an export or backup) then next time the user performed this > operation, attempted to return them to the same directory. > > How is this done? In the 'io.File' world, I just save the result of > getAbsolutePath(). In the DocumentFile world (or even the DocumentContract > world) there does not seem to be an equivalent. How can I return the user > to the same location next time? > > > 2. IF I can return to the user to the "same place" next time they try to > open/save, how do I allow them to navigate back up the tree? Sure, a file > can have parents, but I can not see any calls that show me the parents, > which kind of makes remembering locations useless. But failing to remember > them is equally useless in large file trees. > > > 3. If I use the new APIs, I can get document IDs. This is great, but do > they encode the provider? Is there a call to say "I have no idea who the > provider was, just open this doc please, here is the ID...?". This is > related to (2), but also important for using files within the app. > > > 4. io.File has a set of functions relating to temp files. If I move over > solely to the new APIs, how can I create a temporary file IN THE SAME > PARENT as a given file, so that when the output is complete, I just do a > delete/rename (to avoid blowing away the previous file until I know the new > file it fully written). > > > 5. I notice that DocumentFile keeps a link to parents internally. Does it > support serialization, and if so, do the parents also get serialized? > > > Sorry for so many questions, but every time I try to use the new API I > seem to hit roadblocks, and all the samples seem overly simplisitic. > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/bab4c6f4-410a-48df-955c-b0668aa610d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
