How to handle preliminary models while waiting for server responses?

Question

In an Android app I work on, models are stored globally and activities are notified about changes like created, updated and deleted models. The according callbacks are called after receiving the server response.

There is a main activity that lists the models and another activity to create new ones. From there, the user can fill out a couple of fields and click on save. This triggers a server request to create the new model. After getting the response, the validated model from the server is added to the global collection and the notification callbacks are executed. The problem is what to do while waiting for the response.

1. We could block the user interface an show a spinner. But that's not very responsive and results in a poor user experience.
2. We could add a local preliminary model and add that to the global collection and trigger notification callbacks. This would allows the main activity to add it to the list. After the response, we update or delete the preliminary model, depending on the success or failure of the request. However, the preliminary model doesn't have its id yet, so it would be hard to find in the collection for updating or removal.
3. Building on this approach, we could assign a random preliminary id to the preliminary model. However, if the user already interacts with the new model, this could create ill-defined requests that use the wrong preliminary id.

How can we handle preliminary models in multiple activities while waiting for server responses in a clear and responsive way?

Answer 1

The best answer in 2 is to let the client create the ID. Don't use consecutive IDs from a sequence. Use a random UUID of 128 bits. Then the client can randomly create a new id and have virtually 0 chance of failing.

If virtually 0 isn't good enough, have the client create a temporary id. Then have the server either accept that ID, or send down a response with both the temporary and permanent id, so the client can remap the temporary id to a new value. Requests that went out between creation on the client and the server could either be resent by the client or remapped by the server.

Although really- a 128 bit random id has so little chance of ever hitting a dupe that you don't need to worry about it. Everyone on earth could create a billion models and have a less than 1 in 1 billion chance of collision the next time they tried.