UBIK® caches all the local content (which exist on the device) in the devices' memory for fast access. However, as the number of objects grows, the device might become less responsive because of the large memory consumption. Also, the initial loading will take a considerable long time. Certain optimizations are added to overcome these problems.
Optimization regarding object loading (WinX client)
In a lot of scenarios, users want to log into the app and start browsing through the object hierarchy as soon as possible. To offer better efficiency for these users, UBIK® divides the loading of all local objects into two phases during the initial loading.
- First, the essential objects including the root and the infrastructure are loading during the login process;
- Then, the login finishes and the user gets to use some basic features of the app while the rest of the objects are being loaded in the background;
- Once the background loading is finished, all the previously unavailable features will function properly.
The temporarily unavailable features mentioned above include:
- Search
- Scanning
- MRO related: During the background loading phase, the status information displayed might not be correct. And actions such as confirming a work package are not possible.
- Modifying objects (including all special objects such as MRO)
- Updating or committing objects
- Sync mode switching
- Branch download
Optimization regarding property loading
On the Android client, a setting is provided to control how content is cached in the memory.
The default value for this setting is lazy loading. |
On the WinX client, lazy loading is the only mode. Therefore, there is no such setting.
Eager loading
After users log in, all content is initialized and loaded into memory. This includes the content hierarchy, object display names, property values, etc.
Lazy loading
After users log in, only the essential content is loaded initially into memory. For now, this means everything other than properties and property values, which are not needed at initialization. That means some properties and property values are loaded initially as they are for example needed for MRO status calculation or similar. Other properties and property values are then loaded on demand. For example, when
- The icons of objects are to be displayed;
- Users need to look at the properties of objects;
- Documents (Thumbnails) are shown.
Comparison between eager loading and lazy loading
Setting Name | Memory Usage | Loading Delay (See hint below) | Initialization Time after Login |
---|---|---|---|
Lazy Loading | Less | More | Less |
Eager Loading | More | Less | More |
Technical background
- MetaClass and MetaProperty are not affected by the memory usage setting since they're practically needed all the time;
- On Android: Once an object's property values are cached under lazy loading setting, they will remain in the memory until one of the following happens:
- The memory allocated to UBIK® is running low;
- Offline preparation is finished with branch(es) downloaded.
- On Android : Initially all properties are loaded without property values. Once property values are requested, they are loaded on demand.
- On WinX and Android : In general, properties and property values are only loaded on demand. However, those that are classification related are loaded initially so that certain classification-based calculations do not lead to all other properties being loaded as well. Since the information regarding which properties should be loaded initially is stored in the database, it is recommended to have a clean installation. WinX: If a clean installation is not possible, the app will still function if an old database is found. In that case, the first login will take a much longer time and the database will be automatically upgraded afterwards, which could take a couple of minutes depending on the amount of local content.