Top 12 mistakes in creating cross-platform UIs, Part 1: Solution architecture

May 21, 2018

Santtu Ahonen-May 21, 2018

As today’s devices and their respective user interfaces become more advanced, so does the creation and production of today’s user interfaces as well. Creating a UI for a modern-day device is often complicated enough as it is. However, when you want to make the UI for a specific custom embedded device, it can be a totally different beast to tame.

We often see developers fall into various problem buckets, coming across the usual suspects of mistakes. In this short series, we dive into these problem areas and reveal the most common mistakes developers make when creating cross-platform UIs, starting in this article with 6 mistakes related to the application and solution architecture. 

Area 1: Application and Solution Architecture

Mistake #1: Misunderstanding memory consumption and memory use

When a developer loads into graphical memory, some things to consider are what items to cache, in what order to load elements and how to build out the overall UX. Performance issues (often the case in smaller devices) differentiate between actual and perceived performance. For example, for actions that take a lot of time (actual performance), developers can throw a preloaded image on the screen to make the user think that things are happening faster (perceived performance). Qt, for one, has very good tools in solving and understanding that. It requires technical competence and tools in place to address those issues.

Take, for example, an embedded Linux stack. Unpolished off the shelf, the underlying operating system alone can easily take 10 seconds to boot, and a vanilla Qt on top of it would take roughly a second (see Figure 1). Factoring in your application itself on top of that, and total bootup time sums up to ~15 seconds. With proper skills, tools and optimization, the bootup should only take a second or two.

Figure 1: Time duration of bootup sequences differs greatly between unoptimized and optimized software stacks (Source: The Qt Company).

When optimizing, developers need to slice down performance lags and understand where the real bottlenecks and time consumers are. This needs understanding and competence on how the memory is being used, in what order, and how to optimize that. If the solutions take a lot of time to boot, optimization hasn’t been done properly. It then shows businesses don’t value performance, which, I guess in the end is OK, since the customer bought it anyway?

Mistake #2: Developing on PC before deploying to target hardware.

This is the most common cardinal sin of embedded development. Designers and engineering teams spend way too long developing embedded solutions on PC only. They then deploy to target hardware too late in the project. This issue is often exacerbated further by the fact that the target hardware is typically new and not available for the teams in the early stages of the project.

The later the design flaws, performance bottlenecks, errors or issues are discovered in a project, the more exponentially costly they are to fix. When comparing a PC to an embedded device, there is almost an unlimited amount of resources, memory and power in use, among other underlying factors. You may not realize the features you add impact performance, if they run just fine on PC. This results in major issues of rearchitecting and redoing large areas of software. What runs perfectly on PC desktop does not always run nor manage properly on embedded devices. Neglecting this impacts time-to-market, cost of ownership and engineering and maintenance cost.

Is there a magic bullet? Yes, start deploying on target device from Day 1. Invest in tools that make this possible. Make sure the whole team, including designers, has access to the target hardware. If you don’t have the target device available, take something which is close to that and start with that from Day 1. Today, there is a good selection of off-the-shelf reference hardware that should get you close enough. If you must develop on PC only, then develop on PC, but plan for the consequences of rewriting and delays.

Continue reading on page two >>


< Previous
Page 1 of 2
Next >

Loading comments...