When working with modal windows in mobile applications, users can face certain difficulties. Picture the situation. A technician of a logistics company has to work onsite (say, at a warehouse). S/he is filling out the order form on the mobile device. At some point, the technician receives the messages with the updated instructions or a new customer request, but can’t open the message window, until s/he finishes filling out the order form! As a result, the technician fills out the form and sends it for billing, though the information there may not be precise.
Books to be read separately
This kind of situation is common for a single-threaded application. When developing a mobile client for a logistics-focused app, we kept the clumsy modal windows in mind. If all the modules of our mobile client—messaging, logging, orders, inventory, etc.—operated in a single thread, the user would face the usability problem described earlier.
That is why we decided to design a multi-threaded core architecture and the engine codenamed Book Manager. Every module works within the separate thread, which we call a Bookshelf. Each Bookshelf contains different pieces of functionality, or Books. The engine extracts the needed functionality from the certain module and chooses what to display to the user in the window.
In other words, every Book (messages, inventory, orders, etc.) stands separately, on its own Bookshelf (thread). Not only does the Book Manager choose which Book to read from the Bookshelf, but it also selects which page to open in the modal window. As a result, the user can see the requested window, switch between several windows without closing them, and therefore perform a number of tasks simultaneously.
More efforts, but better app maintenance
One may hesitate whether to create an application that uses more than one thread or not, because multi-threaded programs are sometimes considered to be complex and difficult to debug. Furthermore, there are few developers who can create well-thought-out business logic for a multi-threaded enterprise application.
On the other hand, the proper architecture is the answer to the issues like that. If a third-party developer wants to create new modules for our app (which is very likely to happen considering the tempo the industry evolves), s/he can build them as single-threaded programs. This makes it easy to add new functionality—without extra testing, debugging, or writing complex code. Definitely, a win-win case.
This solution also helped us solve a performance issue, which I am going to share with you in my next post. See you.