Embedded Restrictions #

Embedded development lead to some restriction that you should deal with because your app is sandboxed in an iframe meaning no direct access to the internet or public networks.

• No use of external resources which means (no CDN, no fetch() etc.).
• Your package must be standalone and use only relative URLs.
• Communication with the infotainment system must use event listening with Window.postMessage().
• The only way to access internet is by using MQTT.
• It’s best to keep HTML to a reasonable size and use assets, it helps to reduce the chances of the page not loading properly and thus prevent reloading big files due to the handover (handover is even more frequent than for a phone).
• GPU is deactivated in the infotainment system, this means heavy animations should not be used.
• The volume of data should be kept to a minimum, keep in mind that internet connection is limited to 3G speeds.

UI/UX Guidelines #

Here are the main criteria your app has to meet before deploying it on the WebPortal:

Best Practices #

WebPortal is based on web technologies however, there are some specificities that you need to consider in order to optimize your app. To make sure your App follow Stellantis requirements, this page give some good practices for development on WebPortal:

Using Cache #

To be able to deliver your content faster, you should cache files you will reuse multiple times. This cache limit is 20 MB.

What is more, the following API use a cache:

• Connectivity.GetInternetStatus()
• Device.GetSoftwareRelease()
• Device.GetSupplierId()
• System.Settings.Value()
• System.Settings.AllKeys()
• Device.GetHMIFocus()
• Car.Time.Hours()
• Car.Time.Minutes()
• Navigation.CurrentPosition.*
• Navigation.Destination.*
• Navigation.ManeuverInfo.*
• Navigation.JourneyInfo.*

Calls between each cached api should wait at least 50 milliseconds.

All other API should respect an interval of at least 500 milliseconds between each call.

Debug Console #

There is no native debug console within WebPortal therefore, you cannot access execution errors in your code. However, we advise setting up a debug console inside own your app during your development process.

This is an example of debug console that you can display inside your app:

HTML

1
2
<div id="debug-console">
</div>

JavaScript

1
2
3
4
5
6
7
try {
    // code you want to debug
} 
catch (error) {
  var debugConsole = document.getElementById('debug-console'); 
  debugConsole.innerHTML = error;
}

CSS

1
2
3
#debug-console {
  border: 1px solid red;
}

Doing so, errors will be displayed inside your app as HTML.

Testing Phase #

When testing your app, in order to know the version of the WebPortal you can check the first digit in the system parameters as it corresponds to the wave of the system.

To generate logs, you have to send the messages to your backend, as the logs generated on the device are the ones corresponding to the system.