Research conflict implementation on server.

[wtrocki]

Showcase implements sample conflict resolution but to understand how conflicts work we can build our own or experiment with example application in voyager server

[wtrocki]

https://github.com/aerogear/voyager-server/blob/master/examples/conflicts/README.md

[Lavanyagaur22]

@wtrocki So this would include->

1. updating a particular task from the android application with the old version.
2. Conflicts will be generated, so study them.
3. To resolve conflicts, updating that task with the incremented version.
4. query all tasks to get the updated results and populate the list.

Please correct me if I'm wrong :).

[wtrocki]

Applications that have offline support (read, writes) will often experience conflicts, but they can be also simulated. let's not resolve conflict for now. Our target will be just to send update mutation and let's make it to throw conflict all the time by simply calling only: https://github.com/aerogear/voyager-server/blob/master/examples/conflicts/server.js#L62

Then start researching how to do it in mobile app (hint: there will be another layer needed to be created when creating apollo client that will catch this error)

[wtrocki]

Once that is done we will have basic clue how conflicts can be handled and we can start doing proposals. The suggestion is to refactor app little bit - separate queries out of activity etc.

[Lavanyagaur22]

@wtrocki Just wanted to confirm, you said to use cache on the second call using OkHttp cache, or saving the first call result in the database and then using it for subsequent ones?

[Lavanyagaur22]

The suggestion is to refactor app little bit - separate queries out of activity etc.

Hey, @wtrocki I was thinking of using ViewModels to separate out the queries from the activity; let me know what you think?

[wtrocki]

I think that we should follow documentation of the Apollo android first. Most importantly https://github.com/apollographql/apollo-android/blob/master/README.md#support-for-cached-responses

Depending on pattern like MVP or something else data layer will look different but we need to make sure that we follow patterns from Apollo docs and other tutorials, blogs using apollo etc.

[wtrocki]

To provide more context. Cache layer is redundant for this investigation but it is good to have anyway. Please research Apollo Android docs and source code. This should be the main focus. Any Android specific improvements for sample app may obfuscate our intentions so lets keep things simple and focus on results which in this case is to handle conflict that was sent from server.

Edit: I think we could have 2 separate tickets

Implement cache layer for app

Follow https://github.com/apollographql/apollo-android/blob/master/README.md#support-for-cached-responses

Refactor sample app to follow best pattern for Apollo queries and mutations

Low priority for the moment but nice to have