We added an offline mode feature to the mobile client of the 1C:Enterprise platform starting from version 8.3.16 in order to make its use more user-friendly. Previously, in case the connection with the server was lost, the mobile client stopped working, and if the user closed the application before restoring connection, data loss could occur. In the case of a slow connection, requests to the infobase could take a long time, which has an adverse effect on the convenience of work. The mobile client offline mode is designed to solve these issues.
The mobile client with offline mode is able to:
-
work directly with the main infobase with a good connection;
-
work offline when there is no connection with the infobase;
-
provide a choice (offline or online) in the case of a slow connection.
The first task is now solved by the mobile client. Configuration adaption to work through the mobile client can be performed quite quickly.
The second task is solved by the 1C mobile platform. But this approach requires creating a separate mobile application which may be a rather labor-intensive job.
The mobile client with offline mode combines both technologies. Additionally, to the conventional mobile client, it contains a local server with a file database. During configuration adaptation to the mobile client with offline mode, some of the configuration functionality can be transferred to a mobile device. This, of course, will require some work, but it may be easier than creating an application on the mobile platform from scratch. In the mobile client with offline mode, it’s possible to implement only that offline functionality which is critical to have offline and to implement it not all at once, but gradually, as the resources (developers) are available and when necessary.
We suppose that, in practice, the costs for solving the problem of the mobile client work in the case of poor connection/lack of connection using the mobile client with offline mode will be way lower than for developing an application on the mobile platform. Also, the mobile client with offline mode will be able to work both offline (with access only to the functionality designed for offline) and online (with the full functionality).
The offline mode is automatically activated when the WiFi connection or mobile Internet is lost; a user can also turn it on manually if the connection is unstable.
During configuration adaptation to the mobile client with offline mode, a developer can specify which configuration data will be required offline.
The offline mode composition may be specified according to object attributes. For example, a certain attribute of some catalog may contain a large data amount that is irrational to download to a mobile device.In the offline mode composition, the priority for opening forms may also be indicated. According to this priority, when opening a form, the data will be loaded in it from the main or a stand-alone server.
To handle the situation of loss of connection with the main server, the IfMainServerAvailabilityChanged event appeared on the client.
Using the MainServerAvailable method, we can verify at any time whether there is a connection with the main server.
When there is a connection, inter-server calls are available; the mobile server calls the main server in the same way as the mobile client would do it. Through the MainServer context, all server modules that may be called from the client are available.
The MobileApplicationServer preprocessor command was added. Using the constructions of the #If MobileApplicationServer type, it’s possible to perform code on a stand-alone mobile client server.
Based on the offline mode composition, a mobile app is created with the corresponding structure of the local base. This mobile app is able to work in one of the three modes (selected by the user for the configuration as a whole):
1. Normal: objects work with the priority set by the developer in offline mode composition.
2. Offline: the application works only with the local server, that is, only with locally accessible objects; other objects are not available. Standard interface commands automatically adjust to offline mode (corresponding menu items become unavailable).
3. Poor connection: the priorities, set by the developer in offline mode composition, are ignored, and all the objects available locally work with the local server. For instance, in the above example, the Counterparties catalog will open locally, even if there is a connection.
Let’s consider the situation when we have opened a form from the main server but after that the connection has been lost. This form will become unavailable until the connection is restored, but the user can go on to work with other forms available locally. Moreover, if the analogue of the form opened on the main server is available locally, it’s possible to reopen this form from the local server and continue working with it.
The contrary situation takes place when we work with a local form and the connection with the server is restored. We want to open the form from the server since there are more available attributes. For this, we developed a mechanism for reopening forms.
We can reopen the form in a programmatic manner by calling the Reopen method in the event handler of the IfMainServerAvailabilityChanged form. For the already opened form, the BeforeReopening handler is called; for the new form, the WhenReopening developer is called. In the handlers of these events, we can initialize a newly opened form taking into account the data entered (but not saved) on the closed form. We can transfer data manually using the code or automatically using the FillWhenReopening method.
The FillWhenReopening method is automatically called after WhenReopening if the StandardProcessing parameter = True. The FillWhenReopening method has limitations; if the attributes are complex types (i.e., a spreadsheet document or a pie chart), they cannot be copied (because, in particular, the spreadsheet document state is not fully available on the client). In this case, the method won’t copy anything and generate an exception.
In the current implementation, the developer, that adapts the configuration to the mobile client with offline mode, is entirely responsible for the data exchange process between the main and local servers. Using exchange plans, the developer can keep track of data changes and synchronize changes, for example, using background tasks. This is similar to developing an application on the mobile platform with data exchange with the 1C application on the server.
