Difference between revisions of "Fast Startup (Client)"
(7 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | {{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. | + | {{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) {{Version/WinXSince|3.0.0}} == |
+ | 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: | ||
+ | * [[UBIK_WinX_Client_Basics#Finding_Objects|Search]] | ||
+ | * Scanning | ||
+ | * [[MRO_Objects_(UBIK_WinX)#Basic_User_Interface|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 | ||
+ | <gallery widths="200" heights="100"> | ||
+ | UI_WinX_Fast_Startup_Content_NavButtons.png|Disabled Scan Button | ||
+ | UI_WinX_Fast_Startup_Content_SearchBar.png|Disabled Search Bar | ||
+ | UI_WinX_Fast_Startup_Content_SyncModeSwitcher.png|Disabled Sync Mode Switcher | ||
+ | UI_WinX_Fast_Startup_Content_ContextButtons.png|Disabled Branch Download Button | ||
+ | </gallery> | ||
+ | |||
+ | {{Clear}} | ||
+ | |||
+ | == Optimization regarding property loading{{Version/AndroidSince|2.4.0}}{{Version/WinXSince|2.5.4}} == | ||
On the Android client, a [[UBIK Client Basics#Options|setting]] is provided to control how content is cached in the memory. | On the Android client, a [[UBIK Client Basics#Options|setting]] is provided to control how content is cached in the memory. | ||
{{Attention|The default value for this setting is [[Memory Usage (Android)#Lazy loading|lazy loading]].}} | {{Attention|The default value for this setting is [[Memory Usage (Android)#Lazy loading|lazy loading]].}} | ||
Line 11: | Line 33: | ||
=== Lazy loading === | === Lazy loading === | ||
− | After users log in, only the essential content is loaded initially into memory. For now, this means everything other than | + | 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; | * The icons of objects are to be displayed; | ||
* Users need to look at the properties of objects; | * Users need to look at the properties of objects; | ||
* Documents (Thumbnails) are shown. | * Documents (Thumbnails) are shown. | ||
+ | |||
+ | |||
=== Comparison between eager loading and lazy loading === | === Comparison between eager loading and lazy loading === | ||
Line 32: | Line 57: | ||
== Technical background == | == Technical background == | ||
* [[MetaClass]] and [[MetaProperty]] are not affected by the memory usage setting since they're practically needed all the time; | * [[MetaClass]] and [[MetaProperty]] are not affected by the memory usage setting since they're practically needed all the time; | ||
− | * | + | * 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; | + | ** The memory allocated to {{UBIK}} is running low (On Android); |
− | ** Offline preparation is finished with branch(es) downloaded. | + | ** Offline preparation is finished with branch(es) downloaded (On Android and WinX{{Version/WinXSince|3.3.0}}). |
− | * On WinX: 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 {{Version/WinXSince|2.5.4}} | + | * On Android {{Version/AndroidSince|2.4.0}}: Initially all properties are loaded without property values. Once property values are requested, they are loaded on demand. |
+ | * On WinX{{Version/WinXSince|2.5.4}} and Android{{Version/AndroidSince|3.0.0}} : 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{{Version/WinXSince|2.5.4}}: 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. | ||
+ | |||
+ | |||
== See also == | == See also == |
Latest revision as of 10:20, 13 August 2018
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.
Contents
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 |
Loading delay refers to the time it takes before the next level of content is available during content browsing. |
Android Only: When the setting is changed from lazy loading to eager loading, UBIK® will start loading all the content into memory in the background. |
Technical background
- MetaClass and MetaProperty are not affected by the memory usage setting since they're practically needed all the time;
- Once an object's property values are cached under lazy loading setting, they will remain in the memory until one of the following happens:
- 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.