Types of user interactionLet’s look at user interactions from the perspective of user expectations. When doing some operations in the application, the user can’t be sure about the result — before a publication is opened, it’s hard to predict its contents. On the other hand, some operations are highly predictable for the user:
- liking a favorite post
- writing a comment
- following/unfollowing another user
IdeaSomehow we need to convince the user that these operations are performing immediately. And here we’ll explain how we do that in our applications. This approach doesn’t require big architecture solutions from the start and can be implemented at any moment of the application development cycle, without any harm to the original. Still, there are few things which are not required, but highly recommended. These things aren’t new and you can find a lot of information about how to use them correctly and why you need to have them in your application.
View Layer without logicTaken from MVVM pattern. The main idea is that the View Layer doesn’t know anything about your business logic. All that this View Layer should care about are simple, plain objects, which have no business logic in them, or at least the View Layer shouldn’t know anything about it:
Updateable View LayerThe View layer should reflect any data changes that are performed in the data it renders. Let’s say a person’s name was changed. Your view should behave correctly, and be able to update itself when this happens. In our examples UIViewController will be the object which will respond to the changes in the model and will tell View to update itself with new data.
Request ManagerThis is the object that is responsible for network operations in your application. You should have one (I hope you do). Also, it’s even better if your ViewController speaks with the Model layer, and the Model layer itself speaks with Request Manager. Again, this is not required, but this is how it works in our applications.
Application StructureHere’s how(probably) your application works now. This is waaay too schematic, but you can update it with your own Structural Units. So here’s what happens:
- Model gets the data from internet
- ViewController listens to the data from Model and updates View
- User Performs some Action on the View
- Spinner starts
- View Controller tells Model to handle action
- Model goes to the internet(to the server, for example)
- Model gets response from the server
- ViewController’s callback got called
- ViewController updates view
- Spinner stops
Let’s add one small thingIn order to trick the user we’ll need to have just one simple thing — the Optimistic Model.
Optimistic Model[caption id="attachment_10243" align="aligncenter" width="766"] Do not let your user see spinners — Optimistic Model[/caption] The idea behind that is pretty straightforward. When the user changes something, the optimistic model gets the original object, tries to predict the potential result, then calls ViewController’s callback with this updated object, and then performs the actual operation in the background like the default Model. Once the real result is returned from the server, the optimistic model calls callback with the real object, or in case of an error, the Model performs callback with the original object and then calls error callback. If we highlight possible flows, they can look like this: [caption id="attachment_10244" align="aligncenter" width="766"] Do not let your user see spinners — Optimistic Model Flows[/caption]
Optimistic Model ImplementationNow, let’s look how the Optimistic Model implementation can look like. With this simple update we were able to perform network operations “immediately” (at least from the user perspective).
Let’s SummarizeWhat do we have as the result?
- A happy user who doesn’t need to wait for each operation to finish:)
- A happy user, who thinks that your application is blazingly fast(even if your server is really slow).
- In the example, we’re copying the object. This is done to prevent some unexpected changes, which can occur, for example, when there are other references on this object in the application.
- In the example, in server response, we have a fully updated object. In the real world application, this rarely true. Anyway, even if server responds with partial updates, this approach can work correctly.
- The Optimistic Model can be simply used for independent properties or groups of properties of object.
- Depending on your needs, you probably would need to have Local Storage, which will store data that has not been sent to the server yet.
- In complex case, when user tries to perform different operations quickly on the same object, you will probably need to use Temporary/Shadow Storage, which will decide what to show. An example of the implementation of this object will be covered in next post.
Subscribe to updates
Share this article