Skip to content
Source

State Problems

I find it hard to imagine a more painful problem in modern software than how much everyone doesn't care about state preservation in applications.

My expectations from the world on this issue look something like this:

  • If I didn't explicitly close the application myself, but it was killed there by the system, for example, then the application should unfold as much as possible in the form that is shown in "recents".
  • If I closed the application myself with the back button, killed it from recents, or even rebooted, then with some chances I still want it to restore in a form as close as possible to how I remember it.
  • And as a bonus, if I navigate through the application deeper and back, then everything happening at the current and higher navigation levels in the absolute majority of cases should remain in their places so that I can calmly return to them.

Suppose you're Instagram, Reddit, or TikTok. As a user, I scroll through your infinite feed on the main screen. Got distracted, answered a call there, or suddenly had to work in the middle of a workday while scrolling reels. And, of course, unfolding the application in about half an hour, I will never return to this state again, because you decided to dump random content on me and scroll to the very top. Literally, I see some post in the application in "recents", I click on the application, and inside it's not there. This is some kind of disgrace. The example with feeds is probably the most illustrative. In my memory, only the Twitter application in this sense does what I expect from it: it leaves me exactly in that scroll position where I was last time. I understand everything, algorithmic feeds, pagination, all that, it's complicated, but in my worldview in projects with such a number of users and developers, this is generally a basically necessary thing.

As for the last point, these are the biggest sufferings for the user. I love the case when the application restores some last activity, from which "back" you go nowhere. And so in a circle, the situation is hopeless if you don't know you need to kill the application.

Or when you press some button on the screen, and the entire activity stack somehow recreated from scratch instead of the expected push of a new screen. And this is all, for example, because the button actually leads to its own deep link, which is historically handled that way.

Let me also remind you in one line how half the world tries to solve the configuration change problem by locking portrait mode.

This is also self-criticism, by the way. If I were paid every time I see in production code that someone tried to save state, I would be the poorest of people, as they say. Praise the gods at least in the libraries we use, most often someone thought about it.

Despite the external similarity of problems, they all have very different causes. Somewhere the developer was in a hurry or didn't know how to write it correctly at all, somewhere when compiling requirements they simply forgot a huge UX-critical layer, somewhere you can also scold the system for excessive complexity of correct state restoration. And what kills it all is that it's hard to test it, it's too much of an edge case, so hands rarely get to it. That's how we live.