Blog on all Things Cloud Foundry

Issues with Mobile App Windows? Think Architecture!

Igor Zubchenok

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.

No Comments

How to Exchange Data with a Mobile Client when It Is Offline?

Igor Zubchenok

Authors: Stepan Churiukanov, Igor Zubchenok

With this post, we want to continue the topic started earlier. The logistics application created for one of our customers was exchanging data with a mobile client used by the company’s cargo vehicles. The mobile client tracked the driver’s location and sent it to the server. This data, including the distance covered by the vehicle, was graphically presented on a visual map in real time. The application also helped calculate the distance, fuel costs, and other expenses.

We discovered that natural inaccuracies in getting coordinates through GPS influenced both the route displayed and the database load. To avoid saving redundant data, we decided to filter it out on the level of the application architecture.

The offline mode

There was another issue that we had to find the solution for. Since the mobile client does not always work in the online mode, you can hardly exchange data with it in real time constantly. The signal may disappear due to the absence of satellites, poor weather conditions, or extreme locations, such as a winding road up in the mountains, a tunnel, etc.

This causes a major problem: what data needs to be sent to the server, when the device is back online?


No Comments

How to Omit Inaccuracy in Receiving Position and Distance Data from GPS? Part 2

Igor Zubchenok

Authors: Igor Zubchenok, Stepan Churiukanov

In our previous post, we’ve described an issue the team faced when developing a GPS module. We now knew how to avoid inaccuracies in computing object’s coordinates, but is it going to be enough to omit data redundancy and make our customer happy?

We decided to test the device and left it turned on in the office overnight. Igor couldn’t help crying out loud the next morning when he walked into the office and looked at the device—it winded over 19 kilometers while just lying on the windowsill! We could not be satisfied with test results, as the application required not only the accurate coordinates, but the precise calculation of distance passed by a vehicle. Now we needed to apply some other techniques for proper distance calculations, because when the signal reception was poor, the inaccurate data was sent.


No Comments


Download Benchmarks and Research