Merge pull request #130 from aerogear/Lavanyagaur22-patch-1

Update docs 2

Author: Lavanyagaur22

README.md

@@ -56,7 +56,7 @@ See [sample](https://github.com/aerogear/offix-android/tree/master/sample) for e
 ## Features in Development 
 
 1. Adding Offline Support when the app is in background.
-2. Provide UI bindings in app. (For the time being, we are using subscriptions to provide them)
+2. Provide UI bindings in app. (For the time being, you can use subscriptions to have UI bindings.)
 
 ## Contributing 
 

docs/README.md

@@ -56,7 +56,7 @@ See [sample](https://github.com/aerogear/offix-android/tree/master/sample) for e
 ## Features in Development 
 
 1. Adding Offline Support when the app is in background.
-2. Provide UI bindings in app. (For the time being, we are using subscriptions to provide them)
+2. Provide UI bindings in app. (For the time being, you can use subscriptions to have UI bindings)
 
 ## Contributing 
 

docs/conflict_resolution.md

@@ -2,21 +2,25 @@
 
 ### Steps to support Conflict Resolution in your app:
 
-- Create a class, let say `UserConflictResolutionHandler` which extends ConfliceResolutionInterface provided by the library.
+- Create a class, let say `UserConflictResolutionHandler` which implements `ConfliceResolutionInterface` provided by the library.
 - Override the `resolveConflict()` method of the interface in your class.
 - You get the **`server state`** and the **`client state`** data associated with that mutation in which conflict occurred.
 - You also get the **`operation type`** of the conflicted mutation. Run a switch case on the operation type to detect which type of mutation is it in which conflict occured and accordingly create an object of that mutation while resolving conflicts.
 - You can resolve conflicts based on your business logic and again make a call to the server.
 
+#### The [conflict protocol/structure](https://offix.dev/#/ref-conflict-server?id=structure-of-the-conflict-error) is descibed on [offix.dev](https://offix.dev/)
+
+
 ### Code:
+#### The sample app contains conflict resolution based on the version strategy. However, the user can use their own markers to resolve conflicts.
+
 
 ```kotlin
 /*
 UserConflictResolutionHandler extends ConflictResolutionInterface.
 Here the user provides the custom implementation of resolving conflicts.
  */
 class UserConflictResolutionHandler(val context: Context) : ConflictResolutionInterface {
-    val TAG = javaClass.simpleName
 
     /*User get the server state and the client state.
      This function resolves the conflicts based on the user business logic.
@@ -27,6 +31,7 @@ class UserConflictResolutionHandler(val context: Context) : ConflictResolutionIn
         operationType: String
     ) {
         /*Version based approach of Conflict Resolution, for instance.
+          You can resolve them based on your logics.
         */
         val serverMap = serverState
         val containsVersion = serverMap.containsKey("version")
@@ -37,42 +42,39 @@ class UserConflictResolutionHandler(val context: Context) : ConflictResolutionIn
             /* You can run a switch case on the operation type to detect which type of mutation is it in which conflict occured
                and accordingly create an object of that mutation, resolve conflict and make a server call with it.
              */
-            when (operationType) {
-                /*
-                According to the schema structure, used a version based approach of resolving conflicts.
-                If operationType is "UpdateTaskMutation" perform the following steps to resolve conflicts.
-                 */
+            when (operationType) {           
                 "UpdateTaskMutation" -> {
-                 
-                    val input = TaskInput.builder().title(clientState["title"].toString()).version(versionAfterConflict)
+                    /* 
+                    1. Get the necessary fields from the clientState.
+                    2. Create an object of mutation.
+                    3. Again make a call to the server.
+                    */                      
+                  val input = TaskInput.builder().title(clientState["title"].toString()).version(versionAfterConflict)
                         .description(clientState["description"].toString()).status("test").build()
 
-                    var mutation = UpdateTaskMutation.builder().id(clientState["id"].toString()).input(input).build()
+                  var mutation = UpdateTaskMutation.builder().id(clientState["id"].toString()).input(input).build()
 
-                    val mutationCall = Utils.getApolloClient(context)?.mutate(mutation)
+                  val mutationCall = apolloclient.mutate(mutation)
 
-                    val callback = object : ApolloCall.Callback<UpdateTaskMutation.Data>() {
-                        override fun onFailure(e: ApolloException) {                       
+                  val callback = object : ApolloCall.Callback<UpdateTaskMutation.Data>() {
+                     override fun onFailure(e: ApolloException) {                       
                             e.printStackTrace()
                         }
-
-                        override fun onResponse(response: Response<UpdateTaskMutation.Data>) {
-                            Log.e("onResponse() updateTask", "${response.data()?.updateTask()?.title()}")
+                        
+                     override fun onResponse(response: Response<UpdateTaskMutation.Data>) {                         
                             val result = response.data()?.updateTask()
                             //In case of conflicts, data returned from the server is null.
                             result?.let {
-                                Log.e(TAG, "onResponse-UpdateTask- $it")
+                              //Perform UI Bindings here.
                             }
                         }
                     }
-                    mutationCall?.enqueue(callback)
-                }
-                
+                    
+                 mutationCall?.enqueue(callback)
+                }              
                 "UpdateUserMutation" -> {
-                    /* Similar for UpdateUserMutation
-                    1. Get all the fields from the clientState.
-                    2. Create an object of mutation.
-                    3. Again make a call to the server.
+                    /* 
+                     Resolve conflicts and make a call to the server.
                     */
                 }
             }

docs/gettingstarted.md

@@ -12,6 +12,7 @@
   - npm run start
 - This will start your server. 
 
+
 ## 2. Android Setup
 
 - Clone [this](https://github.com/aerogear/offix-android.git) repository. 
@@ -36,3 +37,6 @@ For **maven**, add the following dependency: <br/>
 	<type>pom</type>
 </dependency>
 ```
+
+
+#### Note: The library works with the offix-sever that is node.js based and [conflict protocol](https://offix.dev/#/ref-conflict-server?id=structure-of-the-conflict-error) is descibed on [offix.dev](https://offix.dev/)

docs/test_offline.md

@@ -2,6 +2,6 @@
 
 - Create any mutation. (Procedure shown on previous page)
 - If your network is connected, then you will get a successful reponse from the server in ApolloCalback's `onResponse()` method. You can perfrom UI Bindings here according to your needs.
-- If your network is not connected, a toast will be shown regarding the same and your mutation would be successfully stored in an offline store.
+- If your network is not connected, your mutation will be successfully stored in an offline store.
 - Once your network connection is regained, the mutations done when you were offline will try to replicate back to the server till all the offline mutations successfully hit the server and you get a response back from them.
 - To get the most recent data in your application, **refresh** your app once after the network comes back by swiping down on the screen.