What is the expected behavior of SQLite CRUD operations after a configuration change or if the activity that started those operations is destroyed?

后端 未结 1 1051
再見小時候
再見小時候 2021-01-15 04:29

I\'m refactoring an app I made some time ago. Back then I was taking my first steps into Android and the easy way to go was to avoid orientation changes, for almost all my C

相关标签:
1条回答
  • 2021-01-15 04:48

    If you use AsyncQueryHandler you have to take into consideration that this abstract wrapper is created and executes provider operations on the thread that it was started on. If you call this from UI thread the callbacks will be sent to the UI thread. If you call this from another working thread, the callbacks will be sent to that working thread.

    This is not bound to the lifecycle of the fragment or the activity, ContentProviders don't have an lifecycle.

    The AsyncQueryHandler at an basic level, creates an Message object which is added to the MessageQueue of an single background thread. No matter from which activity/fragment you use the AsyncQueryHandler all the Message objects will end up on the same MessageQueue. Once the background thread processes an request it will send the response back to the instance of the AsyncQueryHandler from which the request was initially made.

    My recommendation is to use the Loaders from Android. These are directly tied to the lifecycle of the activity/fragment. You can have multiple Loaders in a LoaderManager(one LoaderManager per activity/fragment) which allows to do more complex operations. Your activity/fragment will automatically be notified when the content has changed(very useful when you want to combine it with your custom methods for CRUD operations or if you need to use long running services). Another very important feature they have is that they will always reconnect to the last Loader, thus you will avoid re-querying your content.

    I recommend you search for some tutorials for implementing Loaders in Android. You can start with these:

    • Loaders - part 1
    • Loaders - part 2
    • Loaders - part 3
    • Loaders - part 4

    Answer for your last comments:

    I suggest to use the EventBus library (https://github.com/greenrobot/EventBus) to make the communication between your AsyncTasks/Thread and your other components. You can start by creating an abstract AsyncTask/Thread and on top of that to make your specific command. For example:

    public abstract class AbstractThread extends Thread {
    
        @Override
        public void run() {
            super.run();
    
            command();
        }
    
        abstract void command();
    }
    

    In the abstract class you could make some DB initialization, verification or anything else that might make sense for your application.

    public class InserTask extends AbstractThread{
    
        @Override
        void command() {
            //TODO: Add logic for the insert task
        }
    }
    
    public class UpdateTask extends AbstractThread{
    
        @Override
        void command() {
            //TODO: Add logic for the update task
        }
    }
    

    In these specific classes, just add your logic of the CRUD operation.

    To have control over these threads, like when they should be stopped, paused, resumed you could create and ThreadPool manager which controls your threads. You can read more how to achieve this here: Thread Pool

    0 讨论(0)
提交回复
热议问题