We use the Angular framework in our projects in an environment where you would never expect it – for infotainment systems in premium vehicles. The Angular application runs on a browser in the vehicle located on the central display, through which the driver can control functions such as navigation, telephone and so on. This has resulted not only in one of the – to our knowledge – largest Angular projects, but has also given rise to special requirements in this environment, especially with regard to runtime performance.

Here is a brief insight into what you can expect from our specialist Angular team.

A particular challenge is to achieve good runtime performance with smooth animations and fast system startup. Even though Angular has a lot to offer, there are many aspects that need to be taken into account during development. In the area of TypeScript, change detection is particularly important to avoid unnecessary screen updates. When defining the CSS, the properties are selected so that they can be hardware accelerated on the graphics processor. To achieve rapid system startup, we only load component as they are needed. During startup, we deploy staggered loading – first loading the components needed to display the start screen and only then loading the background services.

Code failing to build on the master branch is bad news. That is why we use a CI infrastructure with gated check-ins. This means that changes can only be introduced if code, tests and linter rules are successfully executed on the feature branch. On top of that, we use a tool for static code analysis, which is also automatically executed on the feature branches. Nevertheless, the check-in also includes a code review. Every change is reviewed with colleagues and comments are implemented before the code is transferred to our repository. This enables us both to detect errors and to better anchor consistent approaches in the team.

Code failing to build on the master branch is bad news. That is why we use a CI infrastructure with gated check-ins. This means that changes can only be introduced if code, tests and linter rules are successfully executed on the feature branch. On top of that, we use a tool for static code analysis, which is also automatically executed on the feature branches. Nevertheless, the check-in also includes a code review. Every change is reviewed with colleagues and comments are implemented before the code is transferred to our repository. This enables us both to detect errors and to better anchor consistent approaches in the team.