Universal Development Update – September 2018

  • 21 January 2019
  • 0 replies
Universal Development Update – September 2018
Gather ’round, gather ’round, we got another Universal Development Update for you! We are closing in on a version which has most of the features covered to act as a read-only version of the current Mobile GUI. The plan is to have something for you all to play around with by the time 2018.3 releases!


A read-only version of the form has been completed for Universal. The basic controls have been implemented like the different text control for email, phone number, multi-line etc. The controls for checkbox and radio buttons are in development as we speak.

The form positions the fields according to the optimal placement over the suggested number of columns, so there is no space wasted. The “number of columns” setting in the Software Factory will be moved from subject to the screen type, so you can modify the number based on the available room on the screen. You might want fewer columns on a detail screen type, or even when the screen gets smaller (using a breakpoint).

A new concept “keep groups together” is introduced to specify whether grouped controls are placed together in the same column or not. If you don’t keep groups together, the group might be spread out over multiple columns.

Let’s talk more about setting the number of columns. Let’s say we want three columns as an example. The form will now have at most three columns, but if the controls fit in only two columns, the third column will be dropped.

Tabs have been replaced by vertical scrolling. The fields which are placed in a tab by the Software Factory will be put in their own section. The decision on how many columns are needed will be made for each section. So if you have three sections, it’s possible the first section has three columns, the second section two and the last only one column.

The width of the controls is equal to the width of the column. If you want a control (like a multiline) to span multiple columns, place it in its own section.

There are some things that are not yet implemented:

  • Controls side-by-side on the same line
  • Field width as a percentage of the width of the column
  • The good old tabpage-based layout

A form with one section containing 3 groups spread over 3 columns

Card list improvements

To finish up development on the card list, we’ve managed to surpass the features of the Mobile card list. This was needed since we will be relying a lot more on the card list in the future, when the good old grids from master-details won’t display data to our satisfaction on small phone screens.

Instead of implementing all control types for the card list, we’ve decided to add an overflow menu to each card. This menu allows you to execute the actions normally available on the control, such as URL navigation, calling a phone number, sending an e-mail or checking out the location on a map.

Overflow menu showing the control actions for a card


Filtering using the global filter and prefilters has seen great progress. Thanks to the Indicium team, filtering works blazingly fast and feels incredibly smooth in the Universal GUI.

The filter and prefilter components are still in development, this is planned to be completed by the next update.

Screen types

Screen types are now being loaded by Universal, components are placed according to the definition of the screen type. The definition of the screen type needs to be converted into a definition which only includes supported components, since not all components are supported yet. A tabpage will, for now, show the first component that is supported. And a splitter which has a grid (supported) on one side, and a cube (not supported) on the other side gets replaced by only the grid. This still needs to pass QA but the development is mostly done.

This is the first step of 5 phases when it comes to screen types.

The second step involves a concept called ‘breakpoints‘ to ensure the screen type always fits, no matter the size of the device, browser window or application, or the room it has when shown as a detail. More about this in a future blog.

Once this is completed, we can work towards autosizing components, for instance a grid or form that keeps growing vertically. What happens when this autosizing grid is in a detail? That’s what we try to tackle in this phase.

Navigating within a screen type is something that was very common in mobile (cardlist to form, form to detail) but not in Windows or Web. We plan to create a common solution between those two, by having hierarchy-like screen types act as fullscreen navigation.

Tabpages, as we know them now, will be the last milestone to achieve and will herald the completion of screen types in Universal.

Lazy model loading

A massive change has been completed regarding model loading. This will not affect developers using the Software Factory much at all, but it might be interesting to take a peek under the hood.

First, a bit of history.
The Windows, Web and Mobile user interface have always loaded the entire application up-front. This is quite a bit of work. Loading every prefilter condition, every grid position of every column in every variant and every drag-drop bound parameter takes some time.

The mechanism that we use for this are so-called get-gui’s. The get-gui’s get the GUI information from the SF or IAM. As time went by, the model got larger, more get-gui’s were introduced and existing get-gui’s got bigger.

The amount of get-gui’s called by the user interfaces has increased quite a bit over time.

The total number of columns returned by all get-gui’s has also doubled over time.

Because of this, applications boot slower and slower. We’ve improved this by loading the model in the background and some funny caching mechanisms, but this is a band-aid and not a proper solution.

We’ve also gotten to the point where we have to limit the model for Mobile. This is currently done by creating a specific menu so it can load properly on a 3G connection. After all, loading a 50mb model is just not feasible.

The size of the model will continue to grow in the future. Adding schedulers, maps and other components to the model will only increase the size of the model further.

Furthermore, Indicium was also built to use the get-gui’s to load the model, but couldn’t care less about icons, form groups or screen types. Universal, on the other hand, doesn’t want anything to do with prefilter queries, file storage types and database connections, since this is all handled by Indicium.

Time for change!
We’ve revised the way the model is loaded for Universal, in concert with some changes for Indicium.
We’ve split up the get-gui’s and replaced them with 3 different segments, called core, api and ui.

The core segment is only used by Indicium to load information about the database and back-end logic. This part of the model is the same for all users. It is loaded on-demand by Indicium when the first user accesses an application.

The api segment is loaded by Indicium for an authenticated user and determines which actions an authenticated user can perform. This is loaded on-demand by Indicium when the user logs in. Users with the same authentication profile will share this data.

The ui segment contains relevant model information for the user interface, split up into different parts corresponding to visual components. Universal will load specific slices of specific parts, and only when it is needed.

The current number of data sources and total columns available per segment.
Data is loaded on-demand by Indicium and Universal.

For instance, when the user logs in, Indicium will ensure the core model is loaded and the API model for this user is loaded. Universal will only load the active menu and the corresponding menu items. When the user clicks on a table, the table is loaded and the screen type for this table is loaded. If the screen type contains a form and a grid, form information and grid information is loaded for this table.

When a slice of UI information has been loaded once, it will be saved for later. If the user opens the same screen again, this slice of the model won’t have to load again from IAM. If two tables use the same tasks, opening the second table will be faster since the tasks are already loaded. This way, a model with thousands of entities can still boot within seconds.

Additionally, Universal doesn’t care about the order in which the model is loaded. When a screen is opened and the grid definition has been loaded, the grid will be shown while the form definition is still loading. Components will just wait to receive the model. Generally, this is loaded super fast (less than 1kb) and won’t be delayed very often, but it’s a robust way of dealing with shaky internet connections.

Further improvements will be done to pre-fetch slices of the model. For instance, when the application loads we can start loading offline objects, start objects, entities used often by the current user, etcetera. When a screen is opened, we might as well already start loading the model for the details.
Indicium loading speeds have also been vastly improved in 2018.3 because of these changes, but we’ll probably save this for another blog.

Other accomplishments this month

  • Displaying multiline data in the grid
  • Improved usability of the login screen
  • Active row change in the grid
  • Improvements of the documentation
  • Date and time visualization improvements
  • Sidebar technical improvements

On the next episode of Universal Development Update:

  • Filter and prefilter component
  • More form controls
  • Breakpoints
  • Lookups
  • Navigation to details in the form of detail tiles

0 replies

Be the first to reply!