Architectural Guidelines and Tips

Managing scope creep and preparing a complex application

Read the embedded best practices guide for hardware related tips.

Generally, try to simplify data transfer, then reduce overheads through structure packing, better representation of your data, and selecting suitable polling (or push) rates for each stream of data.

How to plan an interface

Generally, structuring any software project is best done with at least a rough idea of your requirements. Building a user interface is no different!

• Write out what the UI needs to show or control,
• Decide if specific functionality is critical priority for users, and build your layout around that functionality,
• Consider sketching a mockup of the interface before writing code, it might help shortcut a few early rework passes,
• Decoupling layout from component logic helps when re-arranging a layout later.
• When building interfaces, make small modular components which layout responsively.

Use hooks wherever possible

Hooks are the preferred way of grabbing hardware state for use in a custom component, and correct usage allows React to only redraw parts of your UI when new data comes in.

If using hooks higher up in the UI layout, to procedurally drive layouts or enable/disable blocks of components, try to avoid updating the underlying data too often, as data change will cause all underlying content to re-render on change.

System Design Tips

Configure correct connections settings

While the default serial connection settings work well, look into configuring the finer details to suit your specific platform's requirements.

Confirm timeouts make sense for your application, reconnection behaviour is appropriate, and if you support parallel interfaces, the conditions which suggest a link change is sensible.

Filter for your devices as specifically as possible, which makes the first connections easier.

Register a VID with USB IF

If you are working on a commercial product, you need to aquire and embed a unique VID and PID into your product's USB interface. Third-party TTL-USB converter IC's commonly allow customisation with PC tooling, or provided on external memory.

A specific VID and PID allows the connections engine to filter specifically for your hardware, and future products, and is the most reliable detection method across all platforms which support USB communications.

For OSHW projects, look into requesting a PID from the pid.codes project.

Put message ID strings in a centralised store

If you need to change the identifying 'channel' or message ID on the embedded side, its easier to change it in one centralised file rather than throughout the application views.

Include rich version and build information

If possible, ensure your embedded device can provide the UI with as much identifying information as possible. This allows future versions of the UI to distinguish between hardware devices and provide backwards compatibility.

This also allows the UI to detect when devices are no longer compatible, and prompt for an update.

Support software updates from day 1

Supporting updates through Electric UI from the first version means you'll be able to centralise the user's interactions with their hardware. In most cases its undesirable to require separate update applications, and users don't want to hunt for an update file on your website.

Firmware updates

If the update procedure doesn't require software support, consider putting instructions or links to relevant documentation on the connections page.

If you do want to include firmware updating support from the application, we have a reference example bootloader which uses Electric UI as the firmware delivery and validation method. Contact us for details.

We are planning on adding components for Arduino, STM32 DFU, Atmel BOSSA in the future. Contact us and we'll help you add support for your platform's flashing process.

Performance Profile the UI

You should confirm the render performance of your UI to ensure consistent frame rate and smooth user experience.

If possible, test on hardware used by your target market. If the UI runs on the computer integrated with your electron microscope (for example), the hardware requirements are strictly defined. For consumer facing products targeting retirees, the average performance of computers might be less obvious.

Performance profiling basics are in the debugging article

Test production/release builds

Built applications are higher performance than production builds in some cases.

Check that debugger access and debug print values don't render, use flags to gate functionality to the development environment.