An online markdown blog and knowledge repository.
All these reading resources are available on Android Developers website.
Create UI Tests with Espresso Test Recorder
SharedPreferences APIs: Good for persisting small collections of data.
SharedPreferences adds methods to use against storage file with the collection's KVPs.
SharedPreferences can be private or shared.
Should not be used to store system or user Preferences (there are other APIs for these).
Create new file or access existing one with either:
Good practice to name files with your 'application ID' e.g.: com.example.myapp.PREFERENCE_<file-key>
Note: Use a 'FileProvider' with 'FLAG_GRANT_READ_URI_PERMISSION' to share private files with other apps.
Use 'geDefaultSharedPreferences()' to get default shared pres file for your App.
Edit shared preferences using either:
An example of something to store in a SharedPreferences file was a high score in a game.
File saves:
Call these methods, providing the KEY of the value you want:
A 'default value' can be supplied (and returned) if no KEY exists.
Go over at least: Overview, Basics, and Recipes.
Write concise Android UI tests.
@Test
public void testName() {
onView(withId($viewIdentifier)).perform($action($param[s]))
onView(with($param[s])).check($assertion($assertedStatus()))
}
// $VARs are used to placehold actual commands
Calling 'onView()' waits synchronously:
These ensure a single UI action will happen at any given time.
View matchers, actions and assertions: 'espresso-core'
Resoruces for 'WebView' support: 'espresso-web'
Synchronizing background jobs: 'espresso-idling-resource'
External contribs: 'espresso-contrib'
Validates sub intents (for hermetic testing): 'espresso-intents'
Where multi-process functionality is found: 'espresso-remote'
Note: Instructation Test root determines where the tests are saved, and it will be in the 'src/*test' directory structure of your project.
Free application with limited quota.
Check out Firebase Test Lab => Real Hardware Environments for Testing Your Android and iOS App
Task: Collection of user-interactive activities.
Back Stack: Arrangement of activities, LIFO storage.
Activities are stored in the Back Stack in LIFO order:
Once all Activities are popped off the stack, the TASK no longer exists.
Root Launcher Activity can either be destroyed or backgrounded depending on Android/API Version:
Note: Instead of overriding 'onBackPressed()', use AndroidX Activity APIs to handle special cases.
When a new App launches, Activities associated with other Apps are put into Background Activity level.
The Home Button causes current foreground Activity Alpha to go into background and a new Task is started with its own Stack of Activities.
When the user returns to the 'warm state' App, the Activity Stack with all Activities still in tact, is restored.
Note: Retaining an Activities in a Background State for long periods, or with many other Apps running, increases the likelihood it will be destroyed to recover RAM.
Multi-Window Environments are allowed and the system manages Tasks (or groups of Tasks) on a per-window bases.
Changing Activities from LIFO to a custom reactivation or start-of-activity is possible:
<activity> manifest element with flags in the Intent to passstartActivity()Activity element attributes:
Principal Intent Flags:
Note: For the most part, Activity back-stack LIFO behavior should not be changed.
Use the Manifest file: Specify how Activity should associate with Tasks when it starts.
Use Intent Flags: Include in Intent that declares how/whether new Activity should associate with current task when calling 'startActivity()'.
A parent Activity that starts a child Activity has precedence over how the child Activity is associated with Tasks.
Specify how Activity should associate with a Task via launchMode attrib in <activity> elements.
Launch Modes definable in launchMode attribute:
onNewIntent(), else new Activity is put on top of Back Stack.Doing this modifies default association on an Activity to its Task.
See the section Background and Foreground Tasks above for the Intent Flags to use.
An affinity is synonymous with preference or owned-by.
Activities started by same App have affinity to each other.
Affinity can be changed for an Activity in element <activity> by using taskAffinity(String) attribute.
Affinities are set and altered by either of the following:
allowTaskReparenting to trueUse taskAffinity(String) to be sure a multi-App APK assigns the affinity in a logical way for your package.
This is an automated process and all Tasks can be cleared except the Root Activity (assumes User abandonment).
Set attributes to alter the default behavior:
alwaysRetainTaskState: True in root Activity to block default behavior.clearTaskOnLaunch: True clears down to the Root Activity when Task is NAV'd away then user returns to it, forcing initial state upon user return.finishOnTaskLaunch: Focused on single Activity (not entire Task), and causes Activity to finish (except Root Activity) when set to true. User NAV'd away then return, the Task is no longer present => disallows user to return to the launched Task.Use Intent Filter android.intent.action.MAIN to specify an entry point for a task, and include android.intent.category.LAUNCHER as the Category specification.
Return to root Readme