Bramastyo Harimukti

Scaling Large UI Development Projects and Managing their Complexities with Reference UI: Neptune 3

Published Monday February 18th, 2019
3 Comments on Scaling Large UI Development Projects and Managing their Complexities with Reference UI: Neptune 3
Posted in Automotive, Biz Circuit & Dev Loop, cross-platform, Embedded, Uncategorized

Complexity kills productivity. The larger a User Interface project scales, the more complex it becomes.

Take an In-Vehicle-Infotainment (IVI) system. The user only gets to interact with the graphic user interface on the screen inside the car. However, the code that connects to the simple and sleek design becomes increasingly complex with every new vehicle model.

To work seamlessly, the IVI needs to be consistent in design and functionality, remaining compatible with the different features of each model at the same time. Essentially this means best practices are necessary, which is what the Qt Automotive Suite provides in the form of Reference UI: Neptune.

Qt Automotive Suite Solution for Development in Complex Environments

Let’s face it: Integrating IVIs seamlessly into a real user interface (UI) is a huge pain. While UI developers are attached to the entire system of the vehicle, we have limited space to work on our component – the user interface – independently. Each action triggers a reaction, and those reactions need to be mapped out. A vehicle isn’t a mere collection of screws and gears anymore, it’s a complex computer system just like any smartphone or laptop.

Larger teams are needed to fulfill the specifications for such IVI system projects. Normally, software teams consist of UI developers and hardware specialists.

In almost every case, UI developers can’t start their work until the hardware teams are done with their part. Without a clear structure, the UI can easily be polluted by unnecessary backend and service dependencies. It is difficult to test each UI component independently without the presence of the backend and services. The hardware needs to sit alongside the UI developer – a clean architecture will help UI developers do their work more efficiently.

The New Architecture of Reference UI: Neptune

Reference UI: Neptune showcases the best practices for developing a scalable automotive UI and as a blueprint for modern digital cockpit development. It introduces a new architecture that allows the UI developer to work without the real target device. With Qt cross-platform capability, UI developers can use their own development platforms such as their own PC or Laptop.

Neptune 3 UI – Center Console

Neptune 3 UI – Center Console


Neptune 3 UI – Instrument Cluster

Neptune 3 UI – Instrument Cluster


Neptune 3 UI - HUD

Neptune 3 UI – HUD

The new architecture also introduces principles that mean the UI has a clear structure to isolate the dependencies on the backend services. The interfaces are separated from the UI, enabling the developer to test each component of the UI and simulate them. At the same time, the backend or hardware team can use the same API to test their part by simulating the signal that should be accessed from the UI. This way, a clear separation between software and hardware will help developers from both teams to work independently.

Qt Automotive Suite fully integrated into Luxoft Digital Cockpit Reference Platform

Qt Automotive Suite fully integrated into Luxoft Digital Cockpit Reference Platform

Nonetheless, integrated infotainment systems that deliver a number of entertainment and information features to users are becoming more essential in the automotive industry.

Enter the Qt Automotive Suite. It is a collection of software components and tools that enable the development of digital cockpits, including an embedded development environment with additional tools for rapid UI development – as well as application introspection and debugging. Qt Automotive Suite comes with libraries and ready-made components, and also boasts hardware adaptation APIs for creating full-featured IVI solutions.

Isolating the UI From the System: Neptune UI Enables Live-Reloading Development

To truly solve the problems mentioned above, we have introduced a new UI architecture in Neptune UI which decomposes the UI along with its backend dependencies, which are stored separately.

The architecture ensures that UI codes are not polluted by particular dependencies – enabling you to implement the UI Harness in Reference UI: Neptune. With this approach, you are able to isolate part of the UI from the rest of the system, allowing the developer to test every single part of the UI independently. The UI Harnesses also enables live-reloading development, so you see the changes as soon as we implement them – cutting the overall development process significantly.

In short, we can now integrate some simulation backends and get rid of service dependencies. Though some complex structures remain, we’re able to actually work with them. More than that, we can keep our output high, even if the code remains complex. With Reference UI: Neptune, complexity doesn’t kill productivity anymore – it amplifies it.

Read more about

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Automotive, Biz Circuit & Dev Loop, cross-platform, Embedded, Uncategorized


Roland says:

Hi Bram,
you are claiming nothing less than having solved the scalability problem QML was plagued with. Could you please elaborate also in technical terms?
How do you wire the GUI-Element with the underlying observable? Do you use Singletons and force the Business classes to be default constructed?
If you are using abstract interfaces, how do you inject the concrete C++ class into QML in a type safe manner?
Does the mentioned UI decomposition also permit an isolated instantiation of middle layers with leaf elements abstracted away or will the leafs always be tied to the branches?

Bramastyo Harimukti Bramastyo Harimukti says:

Hi Roland,

thanks for your comment and questions!
What we did in Neptune 3 is documented a bit here:
We also plan to release a digital guideline around this topic separately in the near future.

To answer your questions, we don’t do a real “Singleton” type as Qt has but create the “Store” (where all the business logics and backend API’s are stored) once in our “View” component (which normally the first child of Main.qml) and delegate particular values to the children. So each decomposed component will receive their desired value from their parent. Hence, you can test each of them independently.

Store has an abstract layer that define the APIs. And yes, the Abstract Interface of the Store has to have an agreement with the backend when defining the APIs. Then you inherit the Abstract Interface and fill those APIs with some values from the backend services or your dedicated simulation backend to support the development process. That explains why only the Store that has the dependencies and backend imports.

Once you have agreed with those APIs then both teams (software and hardware) can work with their part independently and test their own component separately.

Such UI decomposition doesn’t really care about isolated instantiation of middle layers, as long as they are imported correctly to the Store. UI parts won’t be affected anyway.

Hope that I have answered your questions 🙂


jason says:

We were just talking about live-reloading on the interest mailing list about live reloading being very desirable.
Can we use this Neptune 3 stuff on a phone?
Is there a demo of that?

Commenting closed.

Get started today with Qt Download now