I find it interesting that modern applications, built using stateless architectures, usually maintain state. Let me explain what I’m getting at. I like to play solitaire on my cell phone. I can hide the app, close the app, or even power down my phone. If I return to the application at a later time, it comes back to where I left off. If I was in the middle of a game when the application lost focus, it doesn’t matter. When the application is re-enabled, it returns right back to the state where I left off.
So, how does this differ from a stateless architecture? A stateless architecture is a method of inter-process communication, where there is no assumption of state from one call to the next. It is often used in web sites, where the client application may not connect to the same web server on each round trip. In a client/server environment, any state information needed for the completion of the call, must be passed for every function call. No data is maintained on the server for a client session.
Let’s get back to the topic. Saving state has become an expectation of consumers as mobile devices gain popularity. Indeed, this was a key component of the design requirements for applications to be developed in Windows 2008 as Metro was being developed.
How about us developers who create business applications? Are we somehow exempt from this behavior? Is this something we need to introduce to our applications, custom or otherwise? Should users be able to expect the capability of returning where they left off when an application was “Closed”? Why not share your preference in our comments?
Cheers,
Ben