What is the architecture of a multi-client program?

Question

Programming

I will describe the task and the current (problematic?) solution:
There are several users on tablets working with a common database.
Currently, users connect to the server via RemoteDesktop, thus. we have a central database, printers registered centrally (each user can use any printer), the program is executed on the server (by instance per user session). Used by Windows.
The tablets themselves use WLAN. And this seems to be a big problem - with a bad signal or when switching from one AccessPoint'a to another, the signal is lost and various incomprehensible things happen.
Symptoms described (and formulated) by users:
- the screen darkens, the session
breaks - the screen does not darken, but the reaction in the program itself slows down a lot
- various errors occur, data is lost
My task, regardless of the described problem, is to rewrite the application from scratch, i.e. I am free to choose the architecture as it suits me and as needed/correctly. But I didn’t have experience in developing multi-client programs and therefore I can’t figure it out how to.
Options:
- Client-Server.
Plus: tablets always have a working program, regardless of the connection. Is there another +?
Minus: conditional functionality - no network = no database. Or turn crutches with a local database and synchronization. The configuration of printers becomes more complicated.
- continue to use RemoteDesktop what other options are there?
How to solve the problem of network availability? Or at least how to make this problem more user-friendly?
-

Answer 1

If you plan to continue using tablets on the move and with a wireless connection, then you should leave RemoteDesktop in any of its manifestations, because the problems will not disappear anywhere.
The essence of the problem is that the WiFi standard does not provide for roaming as such at all, and roaming is implemented by the method of tricky crutches. As a result, when moving from one point to another, communication breaks are possible, and your application must be able to handle them correctly, and RemoteDesktop clearly cannot do this. If the program is used in a limited number of offices, and you can influence the implementation of WiFi in these offices, then you can go this way, improve communication for customers without touching the application architecture and established user habits.
Therefore, you need either a thin client or a browser where you can control and correctly handle communication timeouts with the server, transparently to the user.

Answer 2

Make a WEB application, a browser and a web server will close half of the communication problems for you.