Issues with Mobile App Windows? Think Architecture!

by Igor ZubchenokMarch 25, 2011
Learn how a multi-threaded mobile architecture makes it easy for developers to add new functionality without extra testing, debugging, etc.

When working with modal windows in mobile applications, users can face certain difficulties. For example, a technician of a logistics company has to work onsite (e.g., 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 cannot 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 as is, 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 application, 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 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 a 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 the Book Manager chooses 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. The reason is that 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, proper architecture is the answer to issues of this kind. 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 to solve a performance issue, which we are going to share in the next blog post.

 

Further reading

 


This post was written by Igor Zubchenok and edited by Katherine Vasilega and Alex Khizhniak.

  •  
  •  
  •