The dark side of ContentProvider
ContentProvider is an Android class for exchanging data between applications . This is exactly what is written in Yavadok : A content provider . But who reads the documentation while everything works? Obviously, only the one who stuffed enough lumps, stepping on all sorts of rakes.
So, in this post I would like to share my negative experience of using ContentProviders as a data source within the application. Why is it actually unreasonable to use them to access data within the program?
The most important, in my opinion, problem is that getContentResolver (). Query (..) returns either a cursor with data or null. If an exception appears inside the ContentProvider, the calling code will not know about it. The maximum that you can find out by running a null test is the fact that something went wrong.
')
Such an approach is definitely not suitable for working within one application, since sometimes the exception rises from the lowest level of data down to the user interface. For example, a message about the unavailability of a web service or an authorization error.
Of course, there is a workaround. You can write to the cursor information about the error, and process it in the calling code. But this is too artificial a decision.
Cursor is good exactly as long as the returned data is representable as a table. But what if you need a more complex structure?
For example, a web service can return data page by page, while on the first page there will be some meta-information, at least the number of pages. You can combine several cursors into one, and in the calling code, parse them back. But it will greatly complicate the logic both at the model level and at the presenter level.
Often there is a need to track the progress of the operation. For example, reading a large amount of data from a file. ContentProviders do not provide this feature.
You can create a private field, write current progress to it and return it as a separate request. But then immediately there will be problems with multithreading and parallel execution by the provider of several identical requests from different clients.
The code running in ContentProvider will most likely not be stopped. If you do not use AsyncQueryHandler, then in general we will have no control over the execution of the operation.
The workaround is approximately the same as in the previous problem - we set up a private field-flag, and switch it when the request needs to be stopped. In the request, we constantly check the status of the flag. This solution is not suitable for all the same reasons.
The conclusion of the above, I can do this. It makes sense to use ContentProviders only if atomic operations are performed inside them that do not take much time and return strictly homogeneous data that can be used by other applications. Here all other cases use ContetProvider'ov seems to me unjustified.
So, in this post I would like to share my negative experience of using ContentProviders as a data source within the application. Why is it actually unreasonable to use them to access data within the program?
Exception Handling
The most important, in my opinion, problem is that getContentResolver (). Query (..) returns either a cursor with data or null. If an exception appears inside the ContentProvider, the calling code will not know about it. The maximum that you can find out by running a null test is the fact that something went wrong.
')
Such an approach is definitely not suitable for working within one application, since sometimes the exception rises from the lowest level of data down to the user interface. For example, a message about the unavailability of a web service or an authorization error.
Of course, there is a workaround. You can write to the cursor information about the error, and process it in the calling code. But this is too artificial a decision.
Complex data structures
Cursor is good exactly as long as the returned data is representable as a table. But what if you need a more complex structure?
For example, a web service can return data page by page, while on the first page there will be some meta-information, at least the number of pages. You can combine several cursors into one, and in the calling code, parse them back. But it will greatly complicate the logic both at the model level and at the presenter level.
Progress progress
Often there is a need to track the progress of the operation. For example, reading a large amount of data from a file. ContentProviders do not provide this feature.
You can create a private field, write current progress to it and return it as a separate request. But then immediately there will be problems with multithreading and parallel execution by the provider of several identical requests from different clients.
Stop execution
The code running in ContentProvider will most likely not be stopped. If you do not use AsyncQueryHandler, then in general we will have no control over the execution of the operation.
The workaround is approximately the same as in the previous problem - we set up a private field-flag, and switch it when the request needs to be stopped. In the request, we constantly check the status of the flag. This solution is not suitable for all the same reasons.
Conclusion
The conclusion of the above, I can do this. It makes sense to use ContentProviders only if atomic operations are performed inside them that do not take much time and return strictly homogeneous data that can be used by other applications. Here all other cases use ContetProvider'ov seems to me unjustified.
Source: https://habr.com/ru/post/134305/
All Articles