Migrating from WM/CE to Android with Enterprise Browser
Audience
This blog is aimed at customers running applications within “Industrial browsers” on either Windows Mobile or CE devices and who are looking to upgrade to Zebra Android devices.
If you are looking for a higher-level view covering all scenarios from native apps to terminal emulation I would highly recommend starting with Zebra’s corporate white paper on migrating mobile apps: http://online.zebra.com/download-enterprise_app_modernisation, it manages to hit all the key points without the marketing jargon but this blog will only talk about Enterprise Browser.
Industrial Browsers?
For over a decade now there have been multiple industrial browsers released by Zebra, its competitors and Zebra’s ancestor companies. Industrial browsers as a product group generally provide access to specialized device hardware (e.g. barcode scanners) through HTML and JavaScript along with a highly configurable browser component.
For Windows Mobile and CE:
- Zebra and its ancestor companies have released 3 major versions of “PocketBrowser”, 3 major versions of the “Rho” product line and most recently, “Enterprise Browser” (EB).
- Ivanti and its ancestor companies have the CETerm product incorporating an industrial browser component (Naurtech).
- Honeywell and its ancestor companies have the HTML5 browser, the Intermec Browser and the “Enterprise Browser” (not to be confused with Zebra’s Enterprise Browser!)
If you are using any of these products and transitioning to Zebra Android hardware, then this blog aims to give you your options:
Options for upgrading to Enterprise Browser on Android:
Common considerations for all upgrade options
Keyboard
Often moving from WM/CE also involves moving from a device with a physical keyboard to a touchscreen only device; this can cause complications to your application workflow which would have been optimized assuming a user entering text or numbers with the device keyboard. Zebra and Enterprise Browser have a number of solutions to this challenge:
- Some of our hardware devices offer both WM/CE and Android variants. In this case, since both devices have physical keyboards there is no need to change your application workflow. Different generations of the same hardware may also offer both WM/CE and Android variants e.g. an application running on an MC9190 WM could be ported to an MC92 device running Android without change.
- If your end users are moving to a touch-only device, Zebra offers a utility called Swipe Assist which allows users to scan by tapping on the screen and provides integration with Enterprise Browser. This can help optimize one-handed workflows and prevents having to continually move away from the screen to scan.
- To help facilitate data input, Zebra offers a utility called Enterprise Keyboard which also offers integration with both Enterprise Browser and Swipe Assist. Confusingly, you will frequently see the keyboard referred to as the ‘SIP’ in Enterprise Browser documentation, a holdover from WM/CE this stands for ‘Soft Input Panel’.
Viewport
Depending on your use case, your rendering engine may have been based on IE and therefore would not have supported the viewport meta tag. In order to get your page to render at a sensible scale on Android it will likely be necessary to include a viewport tag within your application.
Note that Enterprise Browser offers ‘DOM injection’ which means you can ‘inject’ a
var viewPortTag=document.createElement('meta'); viewPortTag.id="viewport"; viewPortTag.name = "viewport"; viewPortTag.content = "width=device-width, initial-scale=1"; document.getElementsByTagName('head')[0].appendChild(viewPortTag);
Viewport handling on the Zebra HTML5 (Webkit) browser for WM/CE devices depends on values given in the Config.xml file, as explained here: http://techdocs.zebra.com/enterprise-browser/1-6/guide/viewport/. Do not get confused with the Android implementation where no special config.xml settings are required.
Deprecated settings and APIs
Whilst the goal for Enterprise Browser is 100% backwards compatibility, there will always be cases where this is not possible, perhaps because there is no equivalent to the functionality on Android or it is no longer technically possible to continue support.
Configuration settings which apply only to WM/CE are clearly labelled in the Enterprise Browser documentation. Examples include changing the caret width (there is no caret on Android) or specifying whether to display scrollbars (Android does not support scrollbars)
With few exceptions, you should find APIs are 100% backwardly compatible though for some older APIs a configuration setting is required which will be covered below. Keyboard APIs will be affected by the lack of physical keyboard along with similar APIs that depend on physical hardware not present on Android (e.g. keylight).
Legacy APIs
As explained in the official migration guide for Enterprise Browser, if you are making use of any APIs that have neither the Rho or EB namespaces then a special Javascript file is required: elements.js. This JavaScript file enables Enterprise Browser to understand the legacy APIs as well as the old ActiveX & NPAPI syntax used to create the pre-defined native browser objects in PocketBrowser and RhoElements, e.g. PocketBrowser.Generic.
To use APIs with the Rho namespace then the corresponding rhoapi-modules.js file is required.
Both elements.js and rhoapi-modules.js can be found in your Enterprise Browser installation under
Configuration file
For the most part, the configuration file format has remained consistent between all versions of Enterprise Browser, RhoElements and version 3 of PocketBrowser. Over time however new defaults and options were added and it is therefore not recommended to just copy a configuration file designed for one of these older products into Enterprise Browser without modification.
Zebra Industrial browsers on WM/CE:
Applications running in Enterprise Browser 1.x
Moving from Enterprise Browser on WM/CE to Enterprise Browser on Android really should be hassle free apart from the points mentioned under ‘common considerations’, above. On WM and CE Enterprise Browser supports both Internet Explorer (IE) and the WebKit (HTML5) rendering engines so if you are still running IE you might find it easier to upgrade in steps: firstly moving to the EB WebKit engine and secondly transitioning fully to Android. You can change the EB engine as follows:
The WebKit engine included in EB for WM/CE is a modern browser engine but due to the limitations of running on 5 to 10-year-old hardware it should not be compared with the webview on a modern Android device but is therefore a good stepping stone if required.
Applications running in the RhoElements 4.x Shared Runtime
RhoElements 4.x shared runtime was included in RhoMobile Suite 4.x and was the last version of Rho that supported the ‘Industrial Browser’ use case. RhoMobile Suite 4.x was a more comprehensive offering with support for building ‘native’ applications, ruby, backend synchronization and consumer platforms but for the purposes of this blog we are concerned solely with the shared runtime.
A brief migration guide from RhoElements 4.x to Enterprise Browser is available but really only covers the fact that backwards compatibility for the Rho namespace is offered by Enterprise Browser’s rhoapi-modules.js file. These Rho namespaced APIs represented a radical shift in how APIs were defined in the product, moving from the old fashioned and mismatched APIs exposed by RE2 to a more harmonized and modern set.
All the following advice and recommendations relating to the confg.xml file, meta tags and rendering detailed for the RhoElements 2.x shared runtime applies equally here.
Note that there was no RhoMobile Suite 3.x (for very similar reasons that there was never an Angular 3 for that project).
Applications running in the RhoElements 2.x Shared Runtime
RhoElements 2.x shared runtime was included in RhoMobile Suite 2.x and was the first version of RhoElements to bring together the power of PocketBrowser with the power of the Rho framework. As mentioned for RhoElements 4.x, RhoMobile Suite was a more comprehensive offering with “RhoElements 2.x shared runtime” forming the part of Rho that supported the ‘Industrial Browser’ use case. The nomenclature of ‘shared runtime’ can lead to confusion so please just consider it an industrial browser.
A comprehensive migration guide from the RhoElements 2.x shard runtime to Enterprise Browser is available.
Applications built for RhoElements 2.x would have used the RhoElements 2.x API set which did not use the Rho namespace, as such it is required to include elements.js into your application as explained in the migration guide.
SAP ITS-Mobile applications running in RhoElements
RhoElements was (and is still) fully compliant with SAP ITS-Mobile and was a very popular use for the software. Customers wishing to use Enterprise Browser with SAP ITS-Mobile should make use of the SAP guide which provides special configuration steps and considerations.
Most of the advice given in the SAP guide for Enterprise Browser would have already have been followed for the initial RhoElements deployment, for example the use of the KeyCapture APIs, optimizing performance by keeping the scanner enabled between page loads and not preloading unused modules.
Some advice will be new as you transition to Enterprise Browser however such as the use of
Between the releases of RhoElements and Enterprise Browser, Zebra engineers have been working closely with engineers at SAP to ensure the EB experience is best in class. It is recommended to thoroughly review the SAP usage guide when transitioning to Enterprise Browser
Applications running in RhoMobile Suite 5.x
For clarity, RhoMobile Suite 5.x did not include support for the industrial browser use case. The generation following RhoMobile Suite 4.x was split into two products:
- Enterprise Browser 1.x which catered for developers running industrial browser based applications.
- RhoMobile Suite 5.x which catered for developers building native applications targeting both Zebra and consumer devices.
Those customers developing ‘native’ rhoelements WM/CE applications with RhoMobile Suite 2.x or RhoMobile Suite 4.x have an upgrade path through RhoMobile Suite 5.x and the consequent open-sourcing of that product as detailed here.
For further clarity, a ‘native’ rhoelements application for WM/CE is distinct from the rhoelements 2.x shared runtime application for WM/CE. The former is built from source using the RhoMobile Suite framework: rake device:wm:production. The latter is a prebuilt application (industrial browser) delivered as a .cab file, installed on devices and configured via a config.xml file which defines the browser start page.
Applications running in RhoElements 1.x
If you are looking at the migration guides for Enterprise Browser you will not see a migration guide from RhoElements 1.x because the product did not introduce any changes to how APIs are handled.
Despite the name, RhoElements 1.x is conceptually similar to PocketBrowser 3.x with the following changes:
- Support for Android
- Inclusion of an HTML5 browser on Windows Mobile and CE.
The API set offered by RE1 was nearly identical to PB3.x with those APIs being copied over and re-implemented on Android, even down to mimicking support for the native PocketBrowser ActiveX objects in the Android browser.
To migrate your application to Enterprise Browser, please follow the instructions given for PocketBrowser 3.x. Since RhoElements 1.x also supports Android, you may be tempted to update stepwise, first from RE1 for WM/CE to RE1 for Android, then from RE1 for Android to Enterprise Browser; since RhoElements 1.x licenses are no longer available for sale however the upgrade to Enterprise Browser must be accomplished in a single step.
Applications running in PocketBrowser 3.x
There is an official migration guide for both PocketBrowser 2.x and 3.x to Enterprise Browser. Note however that the official guide largely assumes you are migrating from PocketBrowser on WM/CE to Enterprise Browser on WM/CE so you will only need to follow the ‘common steps’ and ‘Android’ sections; this is because PocketBrowser did not support Android devices.
Between PocketBrowser 3.x and PocketBrowser 2.x the API syntax was changed from EMML 1.0 to EMML 1.1 (there is a Wikipedia article on it). For this reason, the migration guide suggests adding
To your config.xml. Strictly this setting is only required if you are using EMML 1.0 syntax but it does not hurt to add it.
All of the PocketBrowser APIs are provided in Enterprise Browser through elements.js so make sure you include that backwards compatibility file in your application, either by modifying your application or by using DOM injection. META tag support will work in Enterprise Browser and you can even specify META tags as part of your DOM injection file to further customize your application without changing the underlying code.
Applications running in PocketBrowser 2.x
As mentioned above under PocketBrowser 3.x, there is a common, comprehensive migration guide that covers both PocketBrowser 2.x and 3.x.
Internally, PocketBrowser 2.x had a different architecture from PocketBrowser 3.x and fewer APIs available but for the purposes of this discussion, the steps to upgrade a PocketBrowser 2.x application to Enterprise Browser do not differ from the steps given for PocketBrowser 3.x.
PocketBrowser 2.x applications were written exclusively with EMML 1.0 therefore it is crucial to set UseRegularExpressions to ‘1’ in the configuration file.
SAP ITS-Mobile applications running in PocketBrowser
PocketBrowser was, at the time, fully compliant with SAP ITS-Mobile but as the two companies worked closer, RhoElements became the preferred industrial browser solution for SAP ITS-Mobile. If you are still using PocketBrowser to interface with SAP ITS-Mobile it is recommended you upgrade to Enterprise Browser and make use of the SAP guide which provides special configuration steps and considerations.
Please also see the above section on “SAP ITS-Mobile applications running in RhoElements” for additional information.
Applications running in PocketBrowser 1.x
The main issue with PocketBrowser 1.x is how much time has elapsed between now and its release back in 2004. I include PB1 here for completeness but in reality, I am not aware of any customer or internal testing that has been done on upgrading from PB1 to Enterprise Browser. In theory, it should work as all versions of PocketBrowser were backwardly compatible but in reality, we have seen all customers previously running PocketBrowser 1 have by now upgraded to at least PocketBrowser 2.x.
Browsers from competitor products on WM/CE:
Applications running in the Naurtech browser
Like PocketBrowser, the Naurtech browser (i.e. the browser portion of the CE term application package) has been around for a number of years and is the platform of choice for many legacy browser-based applications. Naurtech is currently owned by Ivanti (formally known as Wavelink) and again like PocketBrowser, Naurtech is a WM/CE only browser without Android support and the rendering engine being restricted to IE without access to an HTML5 compliant browser. Where Naurtech does differentiate itself is with device support: whereas PocketBrowser was locked to Zebra (& ancestor company) devices Naurtech will run on all WM/CE devices from all vendors which frequently gave it the edge with customers not wishing to tie themselves to Zebra with PocketBrowser.
Customers currently using Naurtech on WM/CE and wishing to upgrade to Android have two choices:
- Although Ivanti did not release an Android variant of the Naurtech browser, they did release an Android-only industrial browser known as ‘Velocity Browser’ which combined Terminal Emulation (TE) functionality into a single package and is branded ‘Velocity’. Velocity’s documentation details custom META tags and IDA commands whose functionality appears identical to the corresponding functionality in the Naurtech browser however there are no references to the CETerm ActiveX object used in Naurtech for additional JavaScript control. For full disclosure, my experience here is limited but from the documentation it appears applications targeting Naurtech will run mostly unchanged under Ivanti but may need modification to avoid the use of ActiveX controls and improve the look and feel as the application moves from IE on WM to an HTML5 browser on Android; this is confirmed in speaking with Ivanti's marketing team although I am not familiar with any real examples upgrading applications via this route.
- The Naurtech browser’s meta tag syntax is virtually identical to PocketBrowser 2, for example:
Actual excerpt example from Naurtech help file:
Actual excerpt example from PocketBrowser 2 help file:
It is left as an exercise to the reader to establish just how this amazing coincidence came about. Regardless, customers may find themselves in a situation where moving to Enterprise Browser will be relatively straight forward by following the migration guide for PocketBrowser 2 and potentially modifying the RegEx.xml file to accommodate for previous incarnations of the Naurtech browser prepending meta tags with ‘iBrowse’. The existing application may have about 70% of its functionality.
There will be additional work however, some meta tags in Naurtech have no equivalent in Enterprise Browser (e.g. ironically enough ZebraLabel) and there is no support for the CETerm ActiveX object in EB. It may be possible to work around these limitations with EB’s DOM injection therefore avoiding the need to modify the existing app.
Which upgrade path to Android you choose will depend on exactly how you are using the features of the Naurtech browser and your plans moving forward. Customers wishing to stay with Ivanti for their industrial browser are encouraged to contact Ivanti support to pursue this option (which of course works well on Zebra hardware); customers wishing to transition to Enterprise Browser can contact their sales representative with more specific questions or reach out to me and I can try to help.
Applications running in the Intermec browser
The Intermec browser was a popular browser offering from Intermec prior to its acquisition by Honeywell in 2013. This browser appears to now be integrated into Honeywell’s ‘Enterprise Browser’ product (yes, the names are the same, to avoid confusion here I will simply refer to this as ‘HEB’). There is another browser product from Honeywell known as ‘HTML5 Browser’ but looking at the documentation for both browser products only HEB appears to have the code and meta tags support to be compliant with applications previously written for the Intermec browser, although they are now marked as deprecated.
Critically for this blog post, Honeywell browsers only run on Honeywell (and Intermec) devices. If you are reading this, the assumption is you are moving from a Honeywell or Intermec device running HEB or IB and want to run your same application on Zebra devices. Given this scenario my advice would be as follows:
- Your existing application is by now quite old and the features are no longer supported even by the original browser supplier, it may be time to rewrite your application either targeting Enterprise Browser or some other technology like Xamarin or native Android.
- Continuing with your existing application and making use of both IB_* meta tags and automation objects may be possible (though has never been tried in practise to my knowledge). Many of the IB_* meta tags share a syntax with PocketBrowser 2, e.g. IB_ScannerNavigate and you can make use of regular expressions as detailed in the PB2 migration guide, only contrary to the warning in that guide you will need to modify the RegEx.xml file to remove the “IB_”. The ActiveX object ITCAXEdit is trickier but could likely be replicated using DOM Injection.
Again, for full disclosure, my experience here is limited.
Licensing
You should consider the different licensing models used by PocketBrowser, RhoElements and Enterprise Browser.
- Enterprise Browser will need a new license. You cannot use the same license you are currently using for PocketBrowser or the RhoElements shared runtime.
- The licensing paradigm has changed back and forth over the years, PocketBrowser licenses are per-device; RhoElements briefly offered per-device or per-application; RhoMobile suite offered per-developer licenses. Enterprise Browser only supports per-device licenses.
- The same license key is used for both WM/CE and Android and provided a sufficient quantity have been purchased, the license key can be deployed on multiple different devices using an enterprise mobility management (EMM) tool like Soti, Airwatch or any other supported EMM.
- You previously needed a new license when upgrading between major or minor versions of software but this was not consistent. The licensing upgrade model for Enterprise Browser is still TBD since it has not yet left version 1.x.
- You cannot have PocketBrowser, RhoElements shared runtime or Enterprise Browser on the same device and both licensed separately. The reason for this is technical (all products are reading the device license key from the same location). The licensing system will likely change at some point in the future to facilitate this.
- For further licensing questions including details of any promotional offers, please contact your support representative.
Internet Explorer on WM / CE vs. HTML5 and Beyond
The rendering engine used to display your application has constantly evolved over the years and it has been a continual challenge to keep a consistent look and feel for your application. With the move to HTML5 the challenge to keep your application looking & working the same on every device got easier but coincided with a proliferation of different screen resolutions and screen sizes that added additional complexity.
The challenges of dealing with different rendering engines should always be considered when creating and testing your applications and these challenges are not going away. As recently as Android Nougat the delivery mechanism for the webview rendering engine was changed from the 'Android System Webview' to now piggy backing off the the Chrome APK on the device. The popular alternative ‘CrossWalk’ project designed to address these specific problems and seen by some as a possible route forward for a consistent browser experience was recently announced to be end of life in March 2017.
| Platform | Browser | Notes |
|---|---|---|
| Windows Mobile 5, 6.1 | Internet Explorer (PIE) | Limited support for even some basic JavaScript like setTimeout or AJAX |
| CE 5 and earlier | CE Browser control | More advanced than PIE but most customers would target the lowest common denominator. |
| Windows Mobile 6.5 | IE6, PIE (PB will default to IE6) | IE6 was far more functional than PIE on its release but lagging far behind HTML5 functionality |
| CE6 / CE7 | CE Browser control | Updates to the browser control for a more modern experience at the time e.g. panning replaced scrollbars. |
|
Windows Mobile 6.5 CE6 CE7 |
HTML5 compliant browser (RhoElements only) | Capabilities of web pages now capped mostly be the capabilities of the host device (processor, RAM etc). HTML5 compliant browser required special porting effort for WM/CE so could lag behind consumer equivalents. Use of WebKit rendering engine differed from Blink which we saw most developers using for desktop prototyping (in Chrome) |
| Android JB (AOSP only) | Android Browser 4.1 | Only updatable with a full update to the device OS. |
| Android KK (AOSP or GMS) | Android Browser 4.4.x |
Only updatable with a full update to the device OS. Rendering engine from this point forward is Chromium but the Chrome app on GMS uses a different WebView from that used in EB. |
|
Android L (AOSP) Android M (AOSP) |
Android Browser | WebView only updatable with a full update to the device OS. |
|
Android L (GMS) Android M (GMS) |
Android Browser |
Updatable from Play Store as ‘Android System WebView’ supporting a more recent Chromium version. WebView on GMS and AOSP will almost always be different but at least you can have the latest or a consistent WebView across different hardware devices running GMS L or M. WebView used in EB will still differ from the Chrome APK. |
| Android N (GMS) | Chrome Browser |
Starting in Android 7.0 the Chrome APK is used to render Android System WebViews. Will benefit from the same managed configurations used to control Chrome. More difficult to ensure a consistent WebView across your organization with a mixture of N with L & M |
| Android O (GMS) | Chrome Browser | Enhancements & security improvements: Each WebView to run in its own process & optional opt out of HTTP traffic. |
Anonymous (not verified)
Replies