Browse Source

[V2] Tweak app lifecycle docs (#4877)

* app launch docs consistent UI capitalisation

* app launch docs greater detail
Evan Ricketts 5 years ago
parent
commit
1c740b74f2
1 changed files with 7 additions and 7 deletions
  1. 7
    7
      docs/docs/app-launch.md

+ 7
- 7
docs/docs/app-launch.md View File

@@ -1,5 +1,5 @@
1 1
 # App Launch
2
-When your app is launched for the first time, the bundle is parsed and executed. At this point you need to show your ui. To do so, Listen to the `appLaunched` event and call `Navigation.setRoot` when the event is received.
2
+When your app is launched for the first time, the bundle is parsed and executed. At this point you need to show your UI. To do so, Listen to the `appLaunched` event and call `Navigation.setRoot` when the event is received.
3 3
 
4 4
 ```js
5 5
 Navigation.events().registerAppLaunchedListener(() => {
@@ -7,7 +7,7 @@ Navigation.events().registerAppLaunchedListener(() => {
7 7
 });
8 8
 ```
9 9
 
10
-!> Register the listener as soon as possible - it should be one of the first lines in your `index.js` file.
10
+!> Register the listener with `registerAppLaunchedListener` as soon as possible - it should be one of the first lines in your `index.js` file.
11 11
 If you're observing a "white screen" or a hanging splash screen after relaunching your app, it probably means `Navigation.setRoot` isn't called once the app has launched. Perhaps the listener was registered too late.
12 12
 
13 13
 ## The difference between the platforms
@@ -15,14 +15,14 @@ When your app is launched, RN makes sure Js context is running. Js context is wh
15 15
 There are a few differences between iOS and Android in this regard
16 16
 
17 17
 ### iOS
18
-Each time the app moves the the background, Js context is destroyed as the app's process is destroyed.
18
+Whenever the app is put into the background, the app process could potentially be destroyed by the system. If this destruction of the app takes place, the Js context will be destroyed along with the app process.
19 19
 
20 20
 ### Android
21 21
 An Android application is typically bound to two contexts:
22
-1. Application - bound to the process
23
-2. Activity - bound to UI
22
+1. Application context - bound to the app process
23
+2. Activity context - bound to app UI
24 24
 
25
-Js Context is executed and bound to the Application. This means, that even when the Activity is destroyed, Js Context is still executed until the Application (and your process) are destroyed by the system.
25
+React's Js Context is executed on and bound to the Application context. This means that even when the Activity context (and thus the UI) is destroyed, React's Js Context remains active until the Application (and your process) are destroyed by the system.
26 26
 
27
-!>*Important!* Because of this, when your app returns to foreground, Js Context might still exist on Android - meaning you might not need to initialise all of your logic, instead you'll only need to call `Navigation.setRoot`.
27
+!>*Important!* Because of this, when your app returns to foreground, Js Context might still exist on Android, even when the Activity and UI context has been destroyed - meaning you might not need to initialise all of your app logic; instead you'll only need to call `Navigation.setRoot` to repopulate the UI context. This circumstance can easily be determined by setting a flag on your app's first `appLaunched` event, and checking the value of that flag on subsequent `appLaunched` events -- if the flag is true in your `appLaunched` callback, you need to call `Navigation.setRoot` to repopulate the UI.
28 28