Provide callbacks to user for UI Bindings.

[Lavanyagaur22]

Description

We can modify the enqueue method of the Offix file in such a way that it will now take 2 parameters, mutation object and a custom interface which can be of the type Offix Interface.

    fun ApolloClient.enqueue(
    mutation: Mutation<Operation.Data, Any, Operation.Variables>,
    customInterface: OffixInterface) { 
   ----
}

This interface will have 2 methods: onSuccess() and onSchedule().

   val customInterface = object : OffixInterface{

            override fun onSchedule(e: ApolloException, values: JsonObject) {
             //get the apollo exception when offline
             // Perform UI bindings according to the requirements.
            }

            override fun onSuccess(string : JsonObject) {
            // User knows the structure of his schema (for that mutation), so he can parse the 
                response accordingly.
            // Perform UI bindings according to the requirements.
            }
 }

In the enqueue method we can create a minimal object of ApolloCall.Callback and in it's onFailure() we can set error data and the mutation's valueMap( json ) in the custom interface's onSchedule() and in it's onResponse () we can simply set the json string response (which we get from the server) in the onSuccess() of that callback.

In this way, the user can do the UI bindings according to their needs. And also if the network is not there, they can still perform UI bindings with the help of the mutation value map variables provided to them in thr onSuccess() method of the custom Interface.

[Lavanyagaur22]

@harshithdwivedi @wtrocki WDYT?

[harshithdwivedi]

in onSchedule why don't we return the Mutation object instead and let the user do whatever they want.

[Lavanyagaur22]

They would probably don't know how to get access to the variables or the values provided in mutation. I mean just for their simplicity, we can return mutation too, no harm. But user has the need of only the variables stored in it and not the entire mutation obj, so..

[Lavanyagaur22]

@harshithdwivedi For now, I am returning mutation object then.

[harshithdwivedi]

Yep

[wtrocki]

Late to the party, but @harshithdwivedi made a really nice comment. I would prefer mutation. In fact we can allow people to reschedule operation if they get entire mutation object.

[wtrocki]

Guys.. How about we do different path.. Instead of passing this interface to enqueue we can..

1. Extend ApolloClient
2. Allow to pass all custom stuff including - Abstraction for network detection Global listener like above
3. On query we can detect if the network is down and force use cache only

I think this may just make thins much more clean and simple to end users. We can finally have some place to hold the data instead of using singletons and static fields.

Many different things. I think we are extending client anyway so let;s do it properly. WDYT?

[wtrocki]

Above is just a suggestion.

[Lavanyagaur22]

1. Extend ApolloClient

@wtrocki We can't do this as ApolloClient is a final class. That's why we can't make an OffixClient sort of thing which extends ApolloClient.

[Lavanyagaur22]

That's why we have 2 options left, either take the client from the user or make a new one in our library. For now, we are taking it from the user. We are not extending it. In this case the user can create a client according to his needs. I think let's first do this with callbacks and then we can go back to the board and think about a different approach for this?

@wtrocki @harshithdwivedi WDYT?