Update README.md

Author: patjackson52

README.md

@@ -30,11 +30,11 @@ The iOS workspace in `/iOS/NameGame` can be open and ran from xCode or AppCode.
 
 ## Architecture
 
-A `GameEngine` object holds the state of the app and provides a methods for views (fragments/UIViewControllers) to "attach".  The `GameEngine` is initialized in the Application class on Android, and the AppDelegate on iOS.  Each view must attach/detach from the GameEngine when it is visible.  `GameEngine.attachView(view)` returns the appropriate presenter for the view.
+A `GameEngine` object holds the state of the app in a redux store and provides a methods for views (fragments/UIViewControllers) to "attach".  The `GameEngine` is initialized in the Application class on Android, and the AppDelegate on iOS.  Each view must attach/detach from the GameEngine when it is visible.  `GameEngine.attachView(view)` returns the appropriate presenter for the view.
 
 `BaseNameGameViewFragment` & `BaseNameGameViewController` handle attaching/detaching the presenter at the appropriate lifecycle methods.  Each Fragment/ViewController extends from these.
 
-An MVP arch is used with a redux store as the 'Model'.  This approach allows maximum reuse of code and a simple contract for the platforms to satisfy.  Presenters send `ViewStates` (simple data classes with fields needed to render UI) to the View interface.  The View implementation has a reference to the presenter, and calls methods for user interaction.  This creates a unidirectional dataflow:
+An MVP arch is used with a redux store as the 'Model'.  This approach allows maximum reuse of code and a simple contract for the platforms to satisfy.  Presenters send `ViewStates` (simple data classes with fields needed to render UI) to the View interface.  The View implementation has a reference to the presenter, and calls methods on the presetner for user interaction.  This creates a unidirectional dataflow:
 
     User interaction -> Dispatch Action -> new state (reduce) -> view rendered by presenter
 
@@ -46,7 +46,7 @@ Views in this arch are truely 'dumb' - they should contain nearly no logic.  The
 ![](https://storage.googleapis.com/treestorage/ui_f_of_state.png)
 
 
-Presenters give a layer of control between subscribing to the new state and the View.  Having views subscribing directly to the store results in code and logic in the View which must be duplicated on each platform.  Presenters are singleton objects that contain no state other than the previous AppState.  This works while presenters are for an entire screen, which for this app is the case.  Another approach will be needed if multiple instances of a given presenter are needed.  The presenter is responsible for rendering the view given the AppState or the delta in AppState.  The Reduks library has a port of Reselect, which allows calling code only when a property changes.  Presenters pass `ViewState` to View methods.  All transformations from Appstate -> ViewState are extension functions in `Transformations.kt`.
+Presenters give a layer of control between subscribing to the new state and the View.  Views subscribing directly to the store results in code and logic in the View which must be duplicated on each platform.  Presenters are singleton objects that contain no state other than the previous AppState.  This works while presenters are for an entire screen, which for this app is the case.  Another approach will be needed if multiple instances of a given presenter are needed.  The presenter is responsible for rendering the view given the AppState or the delta in AppState.  The Reduks library has a port of Reselect, which allows calling code only when a property changes.  Presenters pass `ViewState` to View methods.  All transformations from Appstate -> ViewState are extension functions in `Transformations.kt`.