0

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?

danijar
  • 32,406
  • 45
  • 166
  • 297

1 Answers1

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.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
  • I don't believe the same UUID would be generated by chance. But an attacker could sent requests with conflicting ids easily. Could anyone comment whether checking for conflicts in the server is save, please? – danijar Feb 06 '16 at 00:55
  • If you're worried about an attacker sending a UUID of someone else's already existing model- you have to worry about that no matter who generates the id. Always check permissions/ownership of your data before allowing someone to edit it. – Gabe Sechan Feb 06 '16 at 00:57
  • Well, any user is allowed to send create requests. So I have to check if the ids coming with those requests are already in use. Otherwise I could easily end up with the same id twice in the database table. For attackers (or even wrongly programmed clients) its is easy to cause a collision. – danijar Feb 06 '16 at 09:41
  • Yes, you do need to check. But then you can just return failure since that will only happen to legit requests every few billion tries. Test that failure just like you would a networking failure- either retry or make them redo it – Gabe Sechan Feb 06 '16 at 09:50