-
Notifications
You must be signed in to change notification settings - Fork 0
ApplicationLifecycle
This page is work in progress. Feel free to contribute.
This is an attempt to describe the current lifecycle of the K-9 Mail application and it's components. The goal is to point out the drawbacks of the current solution and propose changes to improve the situation.
You might want to read:
Every time the K-9 Mail process is started a K9 instance is created (subclass of Application) and initialized using the onCreate() method.
Events that can trigger a process creation:
- Manual start of the application (e.g. via the launcher app)
- Intent that invokes a K-9 Mail activity (e.g. compose new message, search)
- BOOT_COMPLETED broadcast intent
- DEVICE_STORAGE_LOW broadcast intent
- DEVICE_STORAGE_OK broadcast intent
- CONNECTIVITY_CHANGE broadcast intent
- BACKGROUND_DATA_SETTING_CHANGED broadcast intent
- SYNC_CONN_STATUS_CHANGED broadcast intent
- MEDIA_MOUNTED broadcast intent
- remote control intent is sent by another application
- AttachmentProvider is used by another application
- MessageProvider is used by another application
Currently this is quite expensive as we open the database to read the global settings, check whether some services should be enabled or not, and register some broadcast receivers if necessary. This has the potential to cause long waits before the requested activity is shown. Though most of the time the process will already have been created (because of the BOOT_COMPLETED intent) when an activity is requested to be displayed for the first time.
- Don't read global settings on process creation. This takes time and has the potential to trigger a database upgrade (although our preference storage schema usually doesn't change). Instead move the global settings handling code to a separate class. Every piece of code (activity, broadcast receiver, service) that wants to access a global preference needs to acquire an instance of this new class and be aware that this may take some time. That's usually not a problem for broadcast receivers and services. Activities have to do this in a background thread (e.g. via AsyncTask), not in the UI thread!
- We don't care about most of the broadcast intents if no account is configured or if no account is configured for poll/push. So register them at runtime, and only if needed.
- Generally try to only have a service running if it's really necessary. For example when communicating with a server, or when Push is enabled. Otherwise stop the services so the application can be killed by Android when there's not enough free memory. The application will be restarted when necessary (poll time alarm, activity is to be displayed, MessageProvider is used etc.).
Handles starting the poll service to check mail, canceling alarm timer to check mail, resetting push/poll schedule, restarting push, reschedule poll, refresh push connection, connectivity change.
Uses BootReceiver.scheduleIntent() which in turn sends a broadcast intent to itself to set an alarm timer to check for mail.
...
...
...
...
...
...
...
Currently not used. Seems to be intended as part of the remote control interface.
...
...
...