| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
android:structure_of_an_android_app [2017/06/05 09:33] ko4bb |
android:structure_of_an_android_app [2017/06/18 17:12] ko4bb |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| An Android app is composed of one or more Activities and optionally one or more Service modules, Class modules and Libraries. | An Android app is composed of one or more Activities and optionally one or more Service modules, Class modules and Libraries. | ||
| - | An Activity is a block of code (a module) that is associated with a particular Graphical User Interface (a Layout in Android parlance,) composed of buttons, labels, pictures, text boxes and other graphical elements. | + | An Activity is a block of code (a module) that is associated with a particular screen layout (a Layout in Android parlance,) composed of buttons, labels, pictures, text boxes and other graphical elements. |
| Since in Android only one Activity can be active at any one time (unlike Windows or Linux where you can have multiple running windows sharing the screen), any Activity that is not currently visible is suspended and can even be unloaded from memory by the OS. Note that in Android 7.0, multiple apps may run in multi-window mode but only one is active at a time, the others are paused. | Since in Android only one Activity can be active at any one time (unlike Windows or Linux where you can have multiple running windows sharing the screen), any Activity that is not currently visible is suspended and can even be unloaded from memory by the OS. Note that in Android 7.0, multiple apps may run in multi-window mode but only one is active at a time, the others are paused. | ||
| - | A Service module does not have a GUI component. A Service can continue running in the background even if the app is not visible. | + | A Service module does not have a GUI component. A Service continues running in the background even if the app is not visible, so a Service is the only way to have code running while the app has no visible activity. However, a Service cannot have any visible element (except for Toast messages). |
| Activities may communicate with a Service module, Class modules and Libraries (both ways) via shared global variables and subroutines. | Activities may communicate with a Service module, Class modules and Libraries (both ways) via shared global variables and subroutines. | ||
| Line 23: | Line 23: | ||
| This is where it becomes interesting, particularly if you have experience writing software for a desktop operating system like Windows or Linux. | This is where it becomes interesting, particularly if you have experience writing software for a desktop operating system like Windows or Linux. | ||
| - | The Android OS is designed to optimize battery and memory usage. Therefore Android can and will stop (and unload from RAM) any process that is not currently active (note that it is easy to keep a Service module active so that it is not unloaded, like a messaging app). You have no control of this, it may happen immediately or after a short delay depending on how busy the device is. | + | The Android OS is designed to optimize battery and memory usage. Therefore Android can and will stop (and unload from RAM) any process that is not currently active (note that a Service module will only be unloaded if the OS has already unloaded paused Activities and still needs more resources). You have no control of this, it may happen immediately or after a short delay depending on how busy the device is. |
| The consequence of that is that if you have an app composed of an Activity and you momentarily leave your app to check your mail for instance; even if you do not close the app when you check your mail, the Activity will start anew when you return to it. The OS will not automatically save the state of your app for you. If you want to return where you were in the app, you have to save the state yourself. That sounds like a pain and it is, but it is better than having the OS guess what you want to keep and what not. There are reasons for this. | The consequence of that is that if you have an app composed of an Activity and you momentarily leave your app to check your mail for instance; even if you do not close the app when you check your mail, the Activity will start anew when you return to it. The OS will not automatically save the state of your app for you. If you want to return where you were in the app, you have to save the state yourself. That sounds like a pain and it is, but it is better than having the OS guess what you want to keep and what not. There are reasons for this. | ||
| Line 51: | Line 51: | ||
| [[https://www.b4x.com/android/forum/threads/android-process-and-activities-life-cycle.6487/|Basic4Android Process and Activities Lifecycle]] | [[https://www.b4x.com/android/forum/threads/android-process-and-activities-life-cycle.6487/|Basic4Android Process and Activities Lifecycle]] | ||
| - | [[https://www.b4x.com/android/forum/threads/statemanager-helps-managing-android-applications-settings-and-state.9777/|Android State Manager]] | + | [[https://www.b4x.com/android/forum/threads/service-modules.7542/|Basic4Android Service Modules]] |
| + | |||
| + | [[https://www.b4x.com/android/forum/threads/statemanager-helps-managing-android-applications-settings-and-state.9777/|Basic4Android State Manager]] | ||