I.

Kotlin
1. Coroutine
1.1. Dispatcher
- If dispatcher isn’t Main dispatcher, after suspend functions such as delay… will
aren’t sure that will same thread before, because it depend on dispatcher.
Example:
- flow
.onEach {
Log.i(TAG, "onEach: $it")
delay(2000)
Log.i(TAG, "onEach2: $it")
// Thread.sleep(5000)

it * 10
}
.flowOn(Dispatchers.IO)
onEach & onEach2 may are not run on same thread

2. Flow
Cold & hold flow
Cold flows are created on-demand and emit data when they’re being observed.
Hot flows are always active and can emit data regardless of whether or not they’re
being observed.
3. Callbackflow
- Internally, callbackFlow uses a channel, which is conceptually very similar to a
blocking queue, and has a default capacity of 64 elements. link
- It use channel as internal working -> it is hot flow, with buffer 64 element & drop
latest policy (mean after full queue – 64 element, it will drop new item until queue
is consumed).
- If queue has some items, then collector become active -> it will emit all queued
element to collector. Example in launchWhenStarted: after back to START from
STOP state, collector will receive all queued elements of callbackflow
4. Basic of flow
flow<Int> {
var i = 0
while (true) {
//supend coroutine, it wait until collector consume it ( see collector) to able
to emit new item
 emit(i)
}
}
//collector
flow.collect {
Log.i(TAG, "repeatOnLifecycle receive: $it")
Thread.sleep(100)
//from here, producer (above) able to emit new item
Log.i(TAG, "repeatOnLifecycle receive 2: $it")
}
emit(1) of producer is suspend until consumer consume it
onEach is extension function to create new flow. Can change dispatcher by call
flowOn(dispatcher)
collect is suspend function, so block code inside it is always run by dispatcher of
coroutine that called it (note: don’t depend on flowOn as said onEach above).
Block code of producer above (which contain emit(i)) will run by dispatcher that
call onEach – flowOn() if we set, otherwise it will depend dispatcher that run collect
function => it depend on dispatcher of consumer
5. addRepeatJob and launchWhenStarted
addRepeatJob – job is stop if out of state, then launch block again if state is
comeback.
launchWhenStarted – job is pause if out of state, mean collector pause to handle
data -> cause flow (producer) also pause (all suspend coroutine function?).
internally, launchWhenStarted use PausingDispatcher, so able to pause when out
of state – “implementation that maintains a dispatch queue to be able to pause
execution of coroutines.” PausingDispatcher use ArrayDeque -> infinite number of
pending items
//log example
22:49:33.461 I: normal/cold flow test
22:49:33.485 I: onStart:
22:49:33.487 I: repeatOnLifecycle START
22:49:33.487 I: 1 SEND: 1
22:49:33.488 I: repeatOnLifecycle receive: 1
22:49:33.488 I: 1 SEND OK: 1
22:49:33.490 I: launchWhenStarted START
22:49:33.490 I: 2 SEND: 1
22:49:33.490 I: launchWhenStarted receive: 1
22:49:33.491 I: 2 SEND OK: 1
22:49:35.491 I: 1 SEND: 2
22:49:35.492 I: repeatOnLifecycle receive: 2
22:49:35.493 I: 1 SEND OK: 2
22:49:35.499 I: 2 SEND: 2
22:49:35.500 I: launchWhenStarted receive: 2
22:49:35.500 I: 2 SEND OK: 2
22:49:36.520 I: onStop:
//both are stop until state changed to START
22:49:39.827 I: onStart:
22:49:39.828 I: repeatOnLifecycle START
22:49:39.829 I: 1 SEND: 1
22:49:39.829 I: repeatOnLifecycle receive: 1
22:49:39.829 I: 1 SEND OK: 1
22:49:39.830 I: 2 SEND: 3
22:49:39.830 I: launchWhenStarted receive: 3
22:49:39.830 I: 2 SEND OK: 3
22:49:41.831 I: 1 SEND: 2
22:49:41.832 I: repeatOnLifecycle receive: 2
22:49:41.832 I: 1 SEND OK: 2
22:49:41.834 I: 2 SEND: 4
22:49:41.834 I: launchWhenStarted receive: 4
22:49:41.834 I: 2 SEND OK: 4
 22:49:42.642 I: onStop:

II. Database
1. Realm
- Open Realm doesn’t take long time
About 100Mb data only ~40-65 ms at first time, then open other only take ~1x-2x
ms
- Realm able to sync between android & ios app without much effort.

III. Lifecycle
NonConfigurationInstances data class pass to Activity while recreate activity (as
rotation, configuration changed)

IV. Android Architecture

1. Task & back stack
Reference: Android developer
A task is a collection of activities that users interact with when performing a certain job.
The activities are arranged in a stack—the back stack)—in the order in which each
activity is opened.

Normally, each app has a task by default. By depend on some configuration, app may
have more than one task by:
 The principal <activity> attributes
- taskAffinity
- launchMode
- allowTaskReparenting
- clearTaskOnLaunch
- alwaysRetainTaskState
- finishOnTaskLaunch
 Intent flags
- FLAG_ACTIVITY_NEW_TASK
- FLAG_ACTIVITY_CLEAR_TOP
- FLAG_ACTIVITY_SINGLE_TOP
1.1. Launch mode
 Standard – default mode: The activity can be instantiated multiple times, each
instance can belong to different tasks, and one task can have multiple instances
(even of side by side of two or more instance of an activity class).
 SingleTop: If an instance of the activity already exists at the top of the current
task, the system routes the intent to that instance through a call to its
onNewIntent() method, rather than creating a new instance of the activity.
 SingleTask: if activity is exist -> call onNewIntent for exist activity, otherwise new
instance with new task is created. Only one instance of the activity can exist at a
time. Note: if there is taskAffinity attribute in activity manifest -> activity is prefer
to be assigned to task that have name: “affinity” – it mean that there is no new
task created for new activity instance.
 SingeIntance: Same as SingleTask, but only single instance activity & activity is
in single task – only this activity is in owner task.
1.2. Intent flags
 FLAG_ACTIVITY_NEW_TASK: same as SingleTask. Call onNewIntent if
instance of activity is exist, otherwise create new task for new activity instance
 FLAG_ACTIVITY_SINGLE_TOP: same as SingleTop
 FLAG_ACTIVITY_CLEAR_TOP: if instance of activity is exist in current task, all
top of this activity is clear, then onNewIntent of this is called (no instance
created)
Note: CLEAR_TOP & NEW_TAST is usually used together for best practice: bring
exist activity in other task to foreground & clear other top activities of this.
1.3. taskInfinity
- The affinity indicates which task an activity prefers to belong to (by task name). By
default, all the activities from the same app have an affinity for each other. So, by
default, all activities in the same app prefer to be in the same task. However, you can
modify the default affinity for an activity. Activities defined in different apps can share an
affinity, or activities defined in the same app can be assigned different task affinities.
- The affinity comes into play in two circumstances:
+ When the intent that launches an activity contains the FLAG_ACTIVITY_NEW_TASK
flag or SingleTask launch mode: If there's already an existing task with the same
affinity as the new activity, the activity is launched into that task. If not, it begins a new
task.
+ When an activity has its allowTaskReparenting attribute set to "true": Normally when
an activity is started, it's associated with the task of the activity that started it and it stays
there for its entire lifetime (ref). When new task with same task affinity go to foreground,
activity able to move to this task. For example, if an e-mail message contains a link to a
 web page, clicking the link brings up an activity that can display the page. That activity
is defined by the browser application, but is launched as part of the e-mail task. If it's
reparented to the browser task, it will be shown when the browser next comes to the
front, and will be absent when the e-mail task again comes forward.

V. Android libraries
2. WorkManager

Picture 1.1 Select right service to run background task (ref)

WorkManager key features:
 Work constraint such as: network connection, charging status…
 Scheduling one time, recurring. Alive even of after device reboot (WorkManager
used local db to save job)
 Retry policy: job able to be re-run if failure
 Work chain flexible: job concurrent, queue…
Note: it’s also compatibility in various OS (we no need to care about new OS
upgrade…)

The exact time that the worker is going to be executed depends on the constraints that
are used in your WorkRequest and on system optimizations. WorkManager is
designed to give the best behavior under these restrictions. ref
1.1 Work state
 Picture 1.2 One time state diagram

Picture 1.3 State diagram for periodic work.

1.2 Manage work
Before version 2.3.0-alpha02, Work maybe killed by system if work is running longer
than 10 minutes ref.
From 2.3.0-alpha02, we are able to running work as foreground service by call function
setForegroundAsync in work. ref