The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
The Storage Access Framework gives developers access to
ACTION_OPEN_DOCUMENT and related
to perform operations on a document provider.
However, what if you want to be a document provider?
To do that, you will need to create a subclass of
override some abstract methods, and perhaps put up with some really obtuse
This chapter will help you in setting up your
luck, you will escape without encountering errors.
This chapter assumes that you have read the preceding chapter on consuming documents, along with its prerequisites.
Most apps will not need to implement a document provider. They might not even consume documents, let alone provide them to other apps.
However, if your app has document-style content, and that content is of a MIME type that could reasonably be manipulated by other apps, you should consider implementing a document provider to allow the user to manipulate that content using those other apps.
Historically, developers had two main approaches for content:
The internal storage route would be for content that would not normally be user-accessible, while external storage would be for user-accessible content.
In either of those cases, you will want to consider creating a document provider. In the case of internal storage, the user has no way to get to that content except through your app, and so if your app does not offer some capabilities that other apps do for that content, you limit your user by not having a document provider. In the case of external storage, while users in theory could use a file manager or something to try to get other apps to recognize the content, it will be easier for users if you provide a document provider to proactively publish this content to consuming apps.
However, bear in mind that your app does not have to store its content in either of these places. It could store the content in somebody else’s document provider, using the mechanisms discussed in the preceding chapter on consuming documents. In this case, you would not need to publish a document provider yourself, as the content is available through the same provider that your code is using.
It may also be the case that while your app is the one directly storing the content on internal or external storage, that content would not reasonably be used by other apps. Perhaps it is in some non-standard format that other apps are unlikely to support. Perhaps the files are not to be used by other apps for security reasons. In these cases, skipping the document provider is reasonable, though not exactly ideal from the user’s standpoint. In particular, it restricts them from using those files with apps that can work with any file, such as attaching them to email messages.
So, for example:
DIRECTORY_DCIMlocation for photos, but you are storing the photos yourself in files consider implementing a document provider so users can get at the photos you are taking. But, if you are implementing a camera app, you might elect to allow the user to indicate some place in somebody else’s document provider where you could save the photo on their behalf.
The preview of this section is sleeping in.
The preview of this section is being chased by zombies.
The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.