Common flow host and API documentation

Refs: #11

Author: motorro

.idea/markdown.xml

@@ -40,6 +40,7 @@ Please checkout the Medium article on pattern/library usage.
     + [Gestures and view-states](#gestures-and-view-states)
     + [View implementation](#view-implementation)
     + [Adopting foreign state-flow](#adopting-foreign-state-flow)
+    + [Common flow API](#common-child-flow-api)
 - [Running state-machines in parallel (composition)](#running-state-machines-in-parallel-composition)
   * [MultiMachineState](#multimachinestate)
   * [ProxyMachineContainer](#proxymachinecontainer)
@@ -135,6 +136,7 @@ val commonMain by getting {
 - [Navbar](examples/multi/navbar) - several machines running in proxy state, one of them active at a time
 - [Mixed](examples/multi/mixed) - two machines of different gesture/UI system mixed in one state
 - [Lifecycle](examples/lifecycle) - track your Android app lifecycle to pause pending operations when the app is suspended
+- [DI](examples/di) - late child flow binding, allows for a dynamic module ([read more](#common-child-flow-api))
 - [Contacts](https://github.com/Android-Developer-Basic/Contacts) - more or less real world KMP/CMP application with network and database
 
 ## The basic task - Load-Content-Error
@@ -1174,6 +1176,28 @@ or to advance to `Complete` state as described in [Common Api](#common-api). The
 this interface by switching host machine to email or complete states in corresponding 
 `backToEmailEntry` and `complete` functions.
 
+#### Common child flow API
+
+For your convenience there are couple of ready-made interfaces to adopt child flow.
+They are: 
+
+-   [CommonFlowHost](commonstatemachine/src/commonMain/kotlin/com/motorro/commonstatemachine/flow/CommonFlowHost.kt) - 
+    the interface the proxy should provide to the child flow. Child uses this flow to terminate but could 
+    also include any other callbacks
+-   [CommonFlowDataApi](commonstatemachine/src/commonMain/kotlin/com/motorro/commonstatemachine/flow/CommonFlowApi.kt) -
+    contains methods to initiate the flow and to adapt it to the hosting flow.
+
+Check the [example](examples/di) that shows the use of this flow:
+
+-   The app has two states: `Content` and `Auth`.
+-   `Content` requires authenticated user.
+-   We have a basic [authentication flow](examples/di/api) flow defined.
+-   We have two implementation modules [Login](examples/di/login) and [Social](examples/di/social) that authenticate users
+    using different authentication "providers".
+-   The [app](examples/di/app) module has two build variants to support each.
+-   The concrete sub-flow is provided with the late DI binding using `Hilt`
+
+
 ## Running state-machines in parallel (composition)
 
 In case you want several state-machines to run in parallel producing a single combined UI state or you