Migration Process

With the announcement of the M400, many developers are wondering how existing M300XL and M300 applications can be ported to run on the M400, or how they can develop new applications specifically for the M400 before the M400 is generally available. Migrating applications to M400 is usually very straightforward, as described below. The ease of porting applications between these devices makes the M300XL and M300 excellent platforms for developing new applications intended to run on the M400.

​

The primary task to port existing Android applications to the M400 is to deal with the unique Interaction Methods and UI Design Best Practices that were initially introduced on the M300 and continued on the M300XL. Applications that follow those guidelines properly will already have the majority of the M400 porting work complete.

​
​

The M400 supports the same display resolutions and orientations as the M300XL and M300. Any screens and layouts will display identically on the M400.

​

The M400 has the same physical buttons as the M300XL and M300. Any button-based navigation will behave identically on the M400.

The M400 has a touchpad that provides all the features of the M300XL and M300. Whether your application handled touchpad input as trackball input or KeyEvent input, any touchpad-based navigation will work identically on the M400.
​

An application being developed specifically for the M400 can also handle multi-finger gestures that are not available on the M300XL and M300. Those multi-finger inputs were introduced for the Blade and documented here. These inputs can be tested on the M300XL or M300 by simulating the input keys instead of using the device touchpad. You can use use a Bluetooth keyboard, or you can use a software interface such as Vuzix View to generate the required key inputs.

​

The M400 uses the same Vuzix Speech SDK as the M300XL, M300, and Blade. All custom vocabulary and speech recognizer controls will behave identically on the M400.

The M300XL and M300 initially used an Add-On SDK to implement the device-specific features. This required the application to target the specific Vuzix API 23. The M300XL and M300 SDK have since been migrated to use a Maven repository for distribution of individual libraries. Changing from the Add-On SDK to use the Maven libraries requires changing the project structure in Android Studio for any existing application. You should target any of the standard APIs revision 23 or earlier, and add the references to obtain the Vuzix SDK libraries from Maven. More information is available in the documentation for the Speech SDK.

​

The M400 version 1.1.0 and higher supports the same Vuzix Barcode SDK as the M300XL and M300. All barcode scanning functionality including scanning by intent, by embedding the barcode engine, and evaluating captured images behave identically on the M400.

Additionally, the underlying barcode engine has been replaced. This allows all supported barcode formats to be made available to third-party applications with no additional licensing fees. There is currently no need to transmit a custom license key to the M400 barcode engine, as required by the M300XL and M300. However, if an M300XL license key is provided, it is simply ignored by the M400, so no code changes are necessary to port M300XL barcode behavior to the M400.

The Vuzix Barcode SDK is distributed via Maven, similarly to the Vuzix Speech SDK.

​

Many third-party libraries will work on M400, M300XL, and M300. The M300XL and M300 have a 32-bit x86 processor. The M400 has a 64-bit ARM processor. So be sure to choose third-party libraries that support both architectures, and configure your project with the necessary build flavors to accommodate both.

​

The M400 and and M4000 camera provides auto-focus and optical image stabilization similar to the M300XL and M300. It also enables higher resolutions. The 1408x792 center-crop resolution is the same on both products. So camera applications should work similarly on the M400 and M4000.

It is always suggested to query the appropriate Camera APIs for the capabilities and properties of the camera, rather than expecting certain behaviors to be present. If this is done, the differences between devices can be minimized.

​

The M400 and M4000 use three microphones to support enhanced audio processing features compared to the M300XL and M300 which had only two microphones. Since the processing is done by the chip, the microphones behavior visible to the programmer appears similar on both. Any application using microphones should work without modification on the M400.

The M400 and M4000 also have a single speaker very similar to the M300XL and M300. Any application that uses the speaker should behave the same on the M400 and M4000.

The M400 and M4000 also support Bluetooth audio devices. All devices supported by the M300XL and M300 should work identically on the M400 and M4000.

​

The M400 and M4000 have a significantly more powerful CPU and graphics engine than the M300XL and M300. Any processing-intensive or graphics-intensive application written on the M300XL or M300 will perform better on the M400 and M4000. Because of this, it is not possible to simulate the final behavior of the M400 or M4000 using an older device.

​

The similarities between the M400 and M4000, M300XL, and M300 allow the M300XL and M300 to be used to develop new applications intended to run on the M400 or M4000. Many applications will run unchanged on all three devices. When minor changes are required to accommodate the different devices, the changes can be made appropriately so the majority of the code base can be still be shared.