Skip navigation

Enterprise Browser 1.7 was released in July, and there's never been a better time to upgrade. The latest version adds a slew of new and updated APIs, including a series dedicated to creating customized button and key layouts. EB 1.7 supports four new Zebra devices, including the TC51HC--which was specifically designed for healthcare workers--and adds support for Lollipop and Marshmallow running in numerous devices shown below.

1. ButtonBar API

A new Android-only ButtonBar API permits a series of custom buttons or keys to be displayed on the screen and configured to launch an app, execute a JavaScript snippet or perform other operations available to the device. Several ButtonBar API guides have been created to help with setup and configuration.

img

 

2. Device Support

EB 1.7 now supports the following new devices and/or existing devices running Android 5.0 Lollipop and Android 6.0 Marshmallow:

  • TC51HC (HealthCare) Android Marshmallow
  • TC56 Android Marshmallow
  • DS3678 Ultra Rugged Scanner (when used with Android TC51/TC51HC Marshmallow)
  • CBL-NGWT-HDVBAP-01 External Vibrator (when used with WT6000 Lollipop)
  • ET50 Android Marshmallow
  • ET55 Android Marshmallow
  • MC32 Android Lollipop
  • TC75X Android Marshmallow
  • RS5000 Ring Scanner (when used with WT6000 Lollipop)
  • RS6000 Ring Scanner when used with:
    • TC51 Marshmallow
    • TC51HC Marshmallow
    • TC8000 Lollipop
  • See all supported devices

3. WebView Control (KitKat and higher)

Enterprise Browser 1.7 now permits many features of the Android WebView to be controlled through the Config.xml file, helping to simplify access to device- and web-related security capabilities and user-experience features. EB 1.7 also increases the methods and properties provided in the WebView API.

 

New WebView Config tags

  • <LayoutLeft> - Optionally sets the horizontal start position of an EB app
  • <LayoutTop> - Optionally sets the vertical start position of an EB app
  • <LayoutWidth> - Optionally sets the width (not to exceed device screen width)
  • <LayoutHeight> - Optionally sets the height (not to exceed device screen height)

 

Other New UI-related Tags

  • <customxmlfile> - specifies the location of the CustomScript.xml, an optional file containing custom JavaScript snippets to be called by custom on-screen buttons or other app functions.
  • <JSLibraries> - can be used to inject JavaScript API libraries (ebapi-modules.js and elements.js) into the DOM of every HTML page when it's not otherwise possible or convenient to edit the source.

4. Web Security

Web security is top-of-mind for many enterprises these days, and Zebra has answered the call with 18 new config tags to give EB apps better control over cache and cookie data are storage and erasure, JavaScript code execution, whitelisting and blacklisting apps and loading data from untrusted or insecure sites.

 

  • <ApplicationCacheEnabled> - allows an HTML5 app to be stored locally for off-line operation, improved speed and reduced server load.
  • <ApplicationCacheOnExit> - controls whether to erase a cached HTML5 app upon exiting it.
  • <SetCacheMode> - controls rules for loading pages from cache vs. loading from the server.
  • <DeleteCacheOnExit> - controls whether to erase contents of the browser cache when exiting an app.
  • <DomStorageEnabled> - controls whether application data is stored locally using HTML5 Web Storage.
  • <DatabaseEnabled> - controls whether to enable the WebSQL database.
  • <GeoLocationEnabled> - controls whether location data from the device can be consumed by the EB app.
  • <JavascriptEnabled> - permits JavaScript code execution within an EB app to be toggled on and off.
  • <SaveFormData> - determines whether an app will retain data entered by a user into forms, checkboxes and other input elements.
  • <BlockNetworkImage> - prevents the app from loading images over a network while allowing non-image resources to load.
  • <BlockNetworkLoads> - prevents the app from loading all network resources, including images.
  • <ClearWebData> - determines whether WebView data stored by the EB app will be retained when app returns to the foreground after the device HOME key is pressed.
  • <NavigateToHomePage> - causes an EB app to display its Start Page when the app returns to the foreground.
  • <MixedContentMode> - security feature that can prevent loading of content from insecure sites.
  • <WebFilteringEnabled> - controls whether web sites will be filtered by the addresses specified in the related tags (below).
  • <WhiteListingUrls> - explicitly allows one or more websites to be visited by an app.
  • <BlackListingUrls> - explicitly blocks one or more websites.
  • <DeleteCookiesOnExit> - automatically erases cookies stored by Enterprise Browser when exiting.

 

Zebra also has added the following features to enhance security of the Kiosk Mode on devices running Lollipop and higher:

  • <setHomeKeyDisable> - prevents the HOME key (or capacitive button) on the device from exiting the current app.
  • <setStatusBarDisable> - prevents the status bar from being displayed (either automatically or by dragging down from the top of the screen).
  • <setBackKeyDisable> - disables the BACK key (or capacitive button), which could otherwise exit the current app and invoke the previously active app or Launcher screen.
  • <setVolumeButonDisable> - prevents the user from controlling the speaker volume using device hardware keys.
  • <setRecentAppDisable> - prevents display of the Recent Apps list, which could otherwise allow the user exit the current app by selecting one from the "recents" list.

5. Updated APIs, Guides

In addition to the ButtonBar APIs, Enterprise Browser 1.7 provides significant updates to the following APIs, guides and variables: 

  • An updated WebView API provides programmatic control over the Android WebView using new clearApplicationCache, clearCache, clearHistory, clearCookies, resizeWebviewLayout and resetWebviewLayout methods, and blockNetworkImage, blockNetworkLoads and contentHeight properties.
  • An updated Device API - adds a reboot method for Android.
  • An updated SIP API - adds disableAIIIME and resetToDefault methods for Android.
  • An updated RemoteNotification API - introduces a cancelNotification method and isLEDSupported, isBeepSupported and isVibrateSupported properties for Android.
  • An updated Barcode API - gives Android devices new resetToDefault and isParamSupported methods and properties for aimType, timesAimDuration, sameSymbolTimeout, differentSymbolTimeout, picklistEx, decodeLEDtime, decodeLEDFeedback, decodeLEDFeedbackMode, OneDQuietZoneLevel and PoorQualityDecideZoneLevel.

 

New and Updated Guides

  • A new Web Page Capture guide covers diagnostic features introduced in EB 1.7 that can capture screenshots and source code files for all app pages.
  • The new Customization guide shows how to customize the on-screen buttons on a device and how to include custom JavaScript snippets for use by the buttons or apps.
  • An updated Security Overview guide includes the new security-related Config.xml-file tags.

 

New Substitution Variables

The following new substitution variables are now supported by Enterprise Browser for use in Config.xml parameters:

  • %PRIMARYDIR% - resolves to the root directory of internal device storage (i.e. /storage/sdcard0)
  • %SECONDARYDIR% - resolves to the root directory of external storage (i.e. /storage/sdcard1)
  • %PERSISTCONFDIR% - resolves to a directory that persists after an Enterprise Reset of the device (i.e. /enterprise/device/enterprisebrowser)

 

For more information, please visit Enterprise Browser 1.7 on TechDocs.

 

Download Enterprise Browser 1.7.

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 <Viewport…/> tag into the DOM without modifying your existing application:

 

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 <Install Dir>\JavaScriptFiles\BackwardCompatibility\Android\.

 

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.xeb logo.jpg

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:

 

 

<EngineInUse value=”WebKit”/>

 

 

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 Runtimere4.png

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 Runtimere2.png

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 <isWindowKey> to enable Android to mimic Windows F1-F12 keycodes or some of the intricacies of key handling.

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.xrho5.png

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.xre1.png

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.xpb3.png

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

 

 

<UseRegularExpressions value=’1’/>

 

 

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.xspb2.bmp

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.xspb1.png

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:

  1. 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.
  2. The Naurtech browser’s meta tag syntax is virtually identical to PocketBrowser 2, for example:

 

Actual excerpt example from Naurtech help file:

<meta http-equiv="ScannerNavigate" content="javascript:OnScan('%s', '%s', '%s', '%s', '%s');">

 

Actual excerpt example from PocketBrowser 2 help file:

<META HTTP-Equiv="scannernavigate" Content="javascript:doScan('%s', '%s', %s, '%s', %s);">

 

 

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.

 

PlatformBrowserNotes
Windows Mobile 5, 6.1Internet Explorer (PIE)Limited support for even some basic JavaScript like setTimeout or AJAX
CE 5 and earlierCE Browser controlMore advanced than PIE but most customers would target the lowest common denominator.
Windows Mobile 6.5IE6, PIE (PB will default to IE6)IE6 was far more functional than PIE on its release but lagging far behind HTML5 functionality
CE6 / CE7CE Browser controlUpdates 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.1Only 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 BrowserWebView 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 BrowserEnhancements & security improvements: Each WebView to run in its own process & optional opt out of HTTP traffic.

I recently came across validating Enterprise Browser for TLS mutual authentication on Zebra Android devices. Here I would like to share my experience about setting up the server and the device for establishing a secured connection (with self-signed certificates) where client validates the server certificate and server validates the client certificate during the TLS handshaking procedure.

 

How TLS Server validation done at Client?

 

During TLS handshake, server presents its certificate to the browser and browser validates that certificate against the internal certificate present inside the trusted certificate store of the device. It means server certificate should be installed on the device before trying to access the server url on the Enterprise Browser. Otherwise Enterprise Browser will not trust the certificate presented by the server and will redirect user to a badlink page with description as SSL_ERROR.

 

As part of TLS handshaking, once Enterprise Browser validates the certificate, it then creates a pre-master secret encrypted with the public key present in the server certificate and sends to the server. This pre-master key can be only decrypted by using the private-key which was used for generating the server certificate. Well this private-key will be only knowing to the server.

 

It means user should first create a private key file and then create a server certificate using the private-key file followed by configuring server for accessing these files. (certificate file will be used for presenting the certificate for client and the key file will be used for decrypting the pre-master key encrypted by the client).

 

Similarly, device should be installed with server certificate for validating the server by Enterprise Browser whenever server presents its certificate to client on accessing its https url.

On successful decryption of pre-master key, server will generate the master-key (session key) from the premaster and similarly Enterprise Browser will also generate the master-key from the pre-master and this symmetric key will be used for encrypting and decrypting the application data at both ends (client and server) throughout the session. This enables the secured communication between server and the client.

 

Configuring XAMPP server for HTTPS using OPENSSL?

 

I was using XAMPP server for hosting my test pages. Also, I preferred OPENSSL tool for generating self-signed certificates (openssl tools is packaged within XAMPP installer, so no need to install it separately). All my experiment was done on Windows 7 64-bit machine.

 

Generating Server certificate?

 

On command prompt, I did following instructions to generate server certificates.

 

Go to openssl.exe directory inside xampp and set the configuration file path as below

 

 

    cd C:\xampp\apache\bin

   set OPENSSL_CONF=C:\xampp\apache\conf\openssl.cnf

 

    generate private key file for the server certificate as below

    openssl genrsa -out server.key 2048

 

    use the private key file to generate the x509 certificate for the server

    openssl req -new -x509 -nodes -sha1 -days 1095 -key server.key -out server.crt

 

This will ask you few details that will go to the certificate. Don’t forget to set the Common Name as your fully qualified domain name. If you don’t have a domain name, set your server ip as your common name. Client will be validating the common name present inside the server certificate against the domain name in the url during TLS handshaking procedure.

This completes the process of generating private-key file and certificate file for the server side.

 

Setting up the device for accepting server certificate?

 

Take a copy of server.crt from C:\xampp\apache\bin and place into device sdcard and install it on to the device as given below.

 

Goto Settings->Security->Install from SD card

 

Browse to sdcard and click on server.crt and provide some alias for the certificate for distinguishing easily for maintenance purpose.

 

This process ensures that the device has the knowledge of the server certificate for a domain.

 

Setting up XAMPP for presenting server certificate for client?

 

Let us now configure the server for certificate and private-key files.

 

  • Copy server.crt file and place under C:\xampp\apache\conf\ssl.crt

 

  • Copy server.key file and place under C:\xampp\apache\conf\ssl.key

 

  • Open httpd-ssl.conf file of XAMPP server and search for string SSLCertificateFile and ensure path to certificate is given as conf/ssl.crt/server.crt

 

  • Search for string SSLCertificateKeyFile and ensure path to private-key file is set to conf/ssl.key/server.key.

 

One should modify SSLCertificateFile and SSLCertificateKeyFile with the proper path to the certificate and key files.

 

This completes the set up for typical https website where only server certificate validation is done by the client.

 

You can do a test by running XAMPP server and trying to connect to a page hosted on the server using https scheme. One can also try stock browser to ensure the setup is proper.

 

How About Client validation at Server Side?

 

TLS support mutual authentication and it allows server to ensure that the client is authorized to access the application data. During TLS handshaking, server ask for a client certificate (if configured for asking). When the request is received from the server, client present its certificate to the server along with that it also sends a packet that includes all TLS handshaking transactions that involved till the CertificateRequest encrypted with the client-private key file and ask server to do a CertificateVerify by decrypting the encrypted packet. This packet can be only decrypted using the public-key present inside the client-certificate that is known to the server.

 

After validating the client certificate at the server side, it decrypts the encrypted packet with the public key present inside the client-certificate and ensure the transactions listed by client is valid as per server transaction history and it proceeds further; else connection will be closed by the server.

 

It means, client should know the client certificate to be presented on  a CertificateRequest from the server and it should also know the private-key file to encrypt the data send during CertificateVerify request.

 

Similarly, server should know the client certificate file for validating the client and also to decrypt the packet sent by the client during CertificateVerify request.

 

Generating Client Certificate?

 

On command prompt, I did following instructions to generate server certificates.

 

Go to openssl.exe directory inside xampp and set the configuration file path as below

 

   cd C:\xampp\apache\bin

   set OPENSSL_CONF=C:\xampp\apache\conf\openssl.cnf

 

   generate private key file for the client certificate as below

    openssl genrsa -out client.key 2048

 

   use the private key file to generate the x509 certificate for the client

   openssl req -new -x509 -nodes -sha1 -days 1095 -key client.key -out client.crt

 

This will ask you few details that will go to the certificate. Don’t forget to set the Common Name as your fully qualified domain name. If you don’t have a domain name, set your server ip as your common name.

 

As I mentioned earlier client should know both private-key file and certificate file. Hence both should be available inside trusted store of the device. Android accepts client certificate in the form of pfx. PFX format is a binary format for storing the server certificate and the private key into a single encryptable file.

 

Let us merge the privte-key file data and certificate into a pfx file with the following command

 

   openssl pkcs12 -export -out client.pfx -inkey client.key -in client.crt

 

This will prompt for a password and remember password and it is needed for installing the pfx file on to the device. This completes the process of generating private-key file and certificate file for the server side.

 

Setting up the device for handling CertificateRequest from the server?

 

Take a copy of client.pfx from C:\xampp\apache\bin and place into device sdcard and install it on to the device as given below.

 

Goto Settings->Security->Install from SD card

Browse to sdcard and click on client.pfx and provide some alias for the certificate for distinguishing easily for maintenance purpose. It will prompt for a password and enter the password that you chose for creating client.pfx file.

 

This process ensures that the device has the knowledge of the client certificate and it private-key file for a domain.

 

Setting up XAMPP for validating client certificate?

 

Firstly, one should set up xampp server for requesting client certificate. This can be done by enabling  SSLVerifyClient require under httpd-ssl.conf file of xampp server.

 

Secondly, configure the certificate path as below

 

  • Copy client.crt file and place under C:\xampp\apache\conf\ssl.crt

 

  • Open httpd-ssl.conf file and search for string SSLCACertificateFile and ensure that path to client certificate is set as SSLCACertificateFile "conf/ssl.crt/client.crt".

 

This completes the process of configuring server to make a request for client certificate and to provide a copy of client certificate for validating client when client  present its certificate.

You can do a test by running XAMPP server and trying to connect to a page hosted on the server using https scheme. One can also try stock browser to ensure the setup is proper.

 

On Android, browser can remember the client certificate only during the life time of the application instance on both stock browser and Enterprise Browser. This can be avoided on Enterprise Browser with a configuration parameter that will be added in future release. Enterprise Browser is fully configurable unlike Stock for industrial need.

 

Conclusion

 

Android started supporting ClientCertificate request handler from Lollipop onward. Enterprise Browser will officially support this feature from Enterprise Browser version 1.7 onward. However already few customers are using Enterprise Browser version 1.6 with a patch on it.

 

There's a signpost up ahead for Zebra's cross-platform development environment. With the release this week of Enterprise Browser 1.6, the solution can now be used to build kiosk apps and other secure configurations. That's thanks to integration with Enterprise Home Screen, Zebra's free device lock-down solution for Android, which replaces the default Launcher. EHS provides a simple way to control access to apps and settings on a Zebra device without writing custom code.

 

Also new is an Enterprise Keyboard API, providing programmatic access to Zebra's software keyboard and many of its settings. New device support in EB 1.6 includes Zebra's ET50 and ET55 devices running Android 5.0 Lollipop, TC51 and TC75 units with Android 6.0 Marshmallow and the RS6000 Ring Scanner when attached to a TC75x Marshmallow. Also notable, Enterprise Browser will no longer support Android Jelly Bean beginning with v1.6.

 

Three APIs have been updated: The Barcode API now supports decode sound functions formerly available only to Windows Mobile/CE devices; the Scanner API adds support for the connectionListenerEvent on KitKat devices; and the Sensor API implements a property for setting the proximitySensorType and getting its current value. Also from the "formerly Windows-only" category, EB 1.6 implements scan-decode tags, including those for setting decode volume, frequency and duration, and one for playing .wav or .ogg sound files when a barcode is successfully decoded.

 

A new Security Guide summarizes the numerous security features dispersed throughout EB's interfaces and the DataWedge Guide now provides version-specific instructions tailored to the DataWedge version installed on a device.

 

You'll also notice an "Enterprise Browser Overview" video embedded on the About page. There are also some new icons in the tab bar next to the usual download and search icons; these place direct links to additional instructional videos and the EB discussion forum to make it easier to find help. And on the subject of getting help, techdocs now leverages the power of the Google search engine to deliver faster, more relevant search results to help customers find the answers they need for the product they're interested in. Try it now! 

By Sabir Valappil Thattath

 

The ITSmobile system from SAP plays various sound files to notify a user whether a server transaction was a failure or success. This is implemented by presenting the <bgsound> HTML tag to the browser. Though the <bgsound> element was once used for playing a sound in background, the tag is now obsolete and treated as a non-standard element; it is presently supported only by IE engines.

 

This creates a problem for SAP users when running existing SAP applications on standard HTML5 browsers. A recent customer interaction involved the need to run an application on a Windows Mobile/CE device with the webkit engine. As expected, the <bgsound> tag would not function on that HTML5 webkit engine, so we solved the problem by developing a workaround.

 

On devices running Android, there's a way to solve this problem without a special workaround and without modifying the SAP application. The answer come with DOM Injection and some JavaScript. Our solution parses the HTML document to replace the <bgsound> tag file with an HTML5-compatible audio tag. We put HTML element-replacing logic to a JavaScript file and included that JavaScript file in the CustomDOMElements list. For complete details, please refer the DOM Injection docs.

 

Below is the script that will be injected and executed once the DOM is ready on the webview:

 

function playBgSound()

{

//get list of bg sound tag, ideally any page will hold one sound file only :-)

  var bgs = document.getElementsByTagName('bgsound');

 

   for (var bgElementIndex=0; bgElementIndex<bgs.length; bgElementIndex++)

   {   

    

      //get the url of the sound file

        var bgSrc = bgs[bgElementIndex].getAttribute("src");    

      //create a audio HTML element supported by webview

       var audioTag = document.createElement("AUDIO");

      audioTag.setAttribute("src",bgSrc);//set sound file url

      audioTag.setAttribute("autoplay","true");//set autoplay to true  

      document.body.appendChild(audioTag);//insert to document body

   }

 

}

playBgSound();

 

Any custom JavaScript files to be injected to DOM have to be referenced inside the CustomDOMElements file (in our case, the file name is mytags.txt) as shown below:

 

<script type='text/javascript' src='http://10.17.121.52:9999/xampp/ebtest/bgsound/playBgSound.js' pages='*'/>

 

The above tag ensures that the script will executed on all pages of the application.

 

In addition, the CustomDOMElements file name also must be referenced in the app's config.xml as shown below:

 

<CustomDOMElements value="file://%INSTALLDIR%/mytags.txt"/>

 

The attached file ("bgsound.rar") contains a sample application that tests the solution described here.

 

Here's how to use it:

1. Extact the rar file and host the test app "test.html" on a server.

2. Place the "decode.wav" and "playBgSound.js" files in the same location as test.html.

3. Open the mytags.txt file and update the 'src' field so that the path to "playBgSound.js" is correct with respect to your server IP.

4. Open the Config.xml and update the 'startpage' attribute so that the path to test.html is correct with respect to your server IP.

5. Copy the mytags.txt and Config.xml files to the /com.symbol.enterprisebrowser folder in your android device.

 

Your Enterprise Browser is ready to play the sound.

 

Before that, let's examine the contents of test.html:

 

<!DOCTYPE html>

<html>

<head>

<title>HTML bgsound Tag Support on EB Android</title>

</head>

 

 

<body>

<bgsound src=".\decode.wav" />

 

 

 

 

<p>This doesn't create any result on the screen but it plays sound file in the background.</p>

 

 

</body>

</html>

 

This is a plain HTML page that has a <bgsound> tag. We are going to play the sound in background while loading the HTML page test.html (your start page in config.hml).

 

Launch EB to play the sound!!

 

Underneath, our script replaces the <bgsound> tag with an audiotag, but it doesn't matter because your SAP app is not aware of it. :-)

 

Sabir Valippil Thattath is a senior software engineer with Zebra Technologies.

By Sabir Valappil Thattath

 

Since the release of Enterprise Browser 1.5, I have been eager to write something about our cool new feature – Disk Caching. We have introduced disk caching functionality for webkit engines running on Windows Mobile/CE devices. This feature enables the browser to cache web resources locally on the device. This improves the page loading time and network bandwidth efficiency if user is trying to reload the same page.

 

Disk Caching Vs Memory Caching

Though Enterprise Browser supports memory caching, disk caching differs in its persistence behavior. In the case of memory caching, resources are stored in the application memory and will be lost once the instance is closed. Disk caching stores the resources into the physical memory (local file system) and makes them available even if you close and relaunch the Enterprise Browser application.

 

This enables faster loading of the pages if any pages were previously visited in the current or previous instance of the Enterprise Browser application.

 

As we are dealing with low-memory devices, there is always a concern about how much cache memory can be reserved for an application like Enterprise Browser. As we keep visiting pages, there is a good probability that memory cache can recycle its content once the upper cache limit is reached. When memory cache gets recycled, any previously visited pages look new to the browser, and it tries to fetch them from the server. This results in slower page loading and increased use of network bandwidth.

 

With Disk Cache in place, the browser first looks for the resource in the memory cache, and if not present, looks in the disk cache and finally to the server. As we have enough physical memory on the devices, we can overcome the recycling limitation of the memory caching feature.

 

It is very easy to enable disk caching. In Enterprise Browser app's config.xml file, look for the parameter:

<DiskCache  VALUE="5MB"/>

 

Enterprise Browser stores the cached resources under a directory named "cache" that is located at the installed directory. This can be easily modified by the user by setting the config.xml parameter for the path: 

<DiskCachePath  VALUE="file://%INSTALLDIR%\EnterpriseBrowser\" />

 

Resource Expiration

We know that the resource gets cached after the first fetch from the server, and on further requests, EB fetches it from the cache. How long should this resource should be treated as fresh? There is a logic behind this too. And you might have guessed, it can be controlled by the server response HEADER. One can configure the freshness of each resource using following response header:

  • Max-age (says how many seconds data should be treated as fresh by browser after caching)
  • Expires (the date/time after which the resource is considered stale by browser after caching)

 

Enterprise Browser stores the resource in the cache along with the expiration information received during its last fetch from the server. Whenever a resource is requested, EB looks to see whether it is available in the cache, if yes it then checks for the freshness using the header values described above. If the data is fresh, the resource gets loaded from the local cache. Otherwise EB issues an If-Modified-Since request to the server for the required resource with time and date as "last cached date."

 

The If-Modified-Since request HTTP header makes the request conditional: the server will send back the requested resource, with a 200status, only if it has been last modified after the given date. If the request has not been modified since, the response will be a 304without any body. If server returns a 304, browser loads the resource from the cache. Otherwise it loads the newly received resource from the server and it caches the same.

 

What happens if someone didn’t configure the Max-age or Expires attributes in the HTTP header response. Will it cache the resource? It depends. EB has its own logic to treat a cached resource as fresh even if the user has not configured a max-age or Expires attribute. In this case, if there is a "Last-Modified" header present, the EB uses a heuristic to calculate a freshness lifetime for the response. Below is the config.xml parameter that is used in the absence of headers described above but in the presence of a Last-Modified header:

<DiskCacheExpTimeFactor  VALUE="10" />

 

If Last-Modified time is "LMT" for a cached resource, and if the resource was cached at time "RCT," the resource is treated as fresh by the EB for a percentage of time RCT-LMT (by default EB set this to 10%).

 

DiskCacheTimeFactor = a percentage of RCT- LMT

 

In other words, at time (T), if EB needs a URL again and looks in the cache for it and has to use the DiskCacheTimeFactor, if T falls under the calculated DiskCacheTimeFactor time range, then the cached resource is used directly. Otherwise a conditional GET (If-Modified-Since) is used to determine whether or not the previous response may be reused.

 

Setting the DiskCacheTimeFactor to zero will cause the resource to be fetched from the server every time it's requested.

 

Test Result

I was validating webkit performance improvement in EB1.5 with respect to EB1.4. I created a sample app which reloads itself after four seconds. The page has three JavaScript resources: rhoapimodules, angularjs and jquery, respectively.

 

I could see around 50-60% improvement with EB1.5 in a scenario where page was cached in the previous instance.

cache_test.png

 

Sabir Valappil Thattath is a Senior Software Engineer with Zebra Technologies

By Sabir Valappil Thattath

 

In this discussion I would like to bring your attention to the DOM injection module in Enterprise Browser. This feature was introduced in Enterprise Browser (EB) version 1.4 and is supported on both Android and Windows Mobile/CE platforms. DOM Injection was introduced by taking into account that users may need to migrate their app to EB without modification. DOM Injection injects the lists of meta/script/css tags mentioned in a local file to the required pages (refer to DOM injection documentation for syntax). We had heard of a couple of scenarios where our customers could solve their needs using the DOM injection technique. I am taking one scenario as an example.

 

NativeTabbar methods let you use multiple instances of the webview in separate tabs. On Windows Mobile/CE there are no visible tabs as we see in the case of desktop browsers. Once tabs are created, one should programmatically switch between tabs. The API exposed for switching tab is EB.NativeTabbar.switchTab(nTabIndex) , refer NativeTabBar for more details.

 

One of our users wanted to use NativeTabBar for his app, however he was not willing to modify his existing application for the tab creation or for switching between tabs. Having a button/href link to switch to a different tab from each tab was looking awkward for the user. Moreover he was worried about modifying his application just for migrating to EB. This was the situation where our team could help the user with DOM injection technique.

 

DOM Injection has three initialization parts. Firstly a custom tag file placed locally on the device, secondly mentioning custom tag file path in config.xml element named CustomDOMElements, thirdly fill the custom tag file with required tag details (refer to the DOM injection module for more details). Once initialization part is completed your EB is ready to inject those tags to the specified pages.

 

The below example was validated on MC92 CE7 and should work for all devices:

 

Below is the CustomDOMElements path mentioned in my example. It says that custom tag file is placed under Application directory folder named EBKeyCaps:

<CustomDOMElements value="file://\Application\EBKeyCap\myTags.txt"/>

 

Below is custom tag file content. It says that the script files named ebapi-modules.js and KeyCap.js  should be injected to all pages navigated by EB:

<script type='text/javascript' src='http://192.168.1.5:80/xampp/ebtest/ebapi-modules.js' pages='*'/>
<script type='text/javascript' src='http://192.168.1.5:80/xampp/ebtest/KeyCap.js' pages='*'/>

 

Now let us look at tab creation part. Customer needed two tabs each tab has its own url:  www.google.co.in and www.yahoo.com, respectively. The startpage of the config.xml has been pointed to nativetabbar.html and the page content is as shown below:

 

<html>

  <head>

<title>STARTPage</title>

  <script type="text/javascript" charset="utf-8" src="ebapi-modules.js">   </script>

  <script type="text/javascript">

 

     function create_tabbar()

     {

           EB.NativeTabbar.create(

                          [

                          {

                              'label':'MainPage', 'action':'http://192.168.1.5:80/xampp/ebtest/nativetabbar.html', 'useCurrentViewForTab':true

                         },
                          {

                             label: "abc",

                             reload: false,

                             action: "https://www.google.co.in"

                          },

                         {

                              label: "abcd",

                              reload: false,

                              action: "http://www.yahoo.com"

                         }

                         ],

                         {createOnInit: "true"} ,tabbar_callback );

   }

 

  function tabbar_callback(params)

  {

     //alert(params)
  }

 

  var alreadyloaded = false;

  function loadEvent()

  {

      if(alreadyloaded == false)

      {

          alreadyloaded = true;

          create_tabbar();

          EB.NativeTabbar.switchTab(1); //this will give a feel to user that his start page is tab1 page contents.(google.co.in in this case)
      }

  }

  function removetabbar()

  {

      EB.NativeTabbar.remove();

  }

 

  window.addEventListener('DOMContentLoaded', loadEvent);

</script>

</head>

 

  <body onload="Javascript:loadEvent()" onunload="removetabbar()">

  <button onclick="EB.Application.quit()">Quit</button>

  </body>

</html>

 

Please note that startpage just creates three tabs tab0, tab1, tab2 respectively and where tab0 is the should be the page which created the tabs as per NativeTabBar documentation. Tab1 and Tab2 are the tabs where user is really interested in and where Tab1 is pointing to google and tab2 is pointing to Yahoo. As you can see, onload event tabs are getting created and we switch to tab1 directly. This gives a feeling to the customer that his start page is google (tab1).

 

How do we switch to tab2? Here comes the role of DOM injection module. When you switched to Tab1 after creating the tabs, there are two scripts injected to your tab1 (ebapi-modules.js and KeyCap.js, respectively without app developer knowledge). Let us see the contents of KeyCap.js:

(function() {

 

   // Poll for EB namespace to come into existence
   var checkReady = function(callback){

   if (window.Rho)

   {

      callback(Rho);

   }

  else

  {

      window.setTimeout(function() { checkReady(callback); }, 100); //check here
  }

  };

   // Start polling...
  checkReady(function(Rho) {

 

     EB.KeyCapture.captureKey(true, "ALL", keyCapCallback);   });

 

  })();

 

function keyCapCallback(result)

{

   if(result.keyValue==112) // F1
      EB.NativeTabbar.switchTab(1);//go to google
   if(result.keyValue==113)

      EB.NativeTabbar.switchTab(2);//go to yahoo
   if(result.keyValue==114)

   {

      EB.NativeTabbar.remove();//remove tabs
      EB.Application.quit();//quit app
   }

}

 

 

Notice that whenever KeyCap.js is loaded on to tab1 or tab2, an anonymous function is getting executed.

 

EB.KeyCapture.captureKey(true, "ALL", keyCapCallback);

The line of code above registers a keydown callback event on each tab. On pressing any key,  keyCapCallback will be called from EB. Based on the keyValue one can write the logic. On pressing F2 key EB view switches to yahoo.com. On pressing F1, EB view will switch back to google.com. On pressing F3 key, EB app will quit.

 

Ultimately the above example will give a feel to user that his start page is google.com. Upon pressing F2 key, his view switches to yahoo.com. On pressing F1, his view will switch back to google.com. On pressing F3, his app will quit. Note that keyboard layout is different on various Zebra devices. Hence keyvalue used here needs to be modified based on the user's device key mapping.

 

Thus DOM Injection helps user to do tabswitching on button press without modifying his application.

 

For more details on DOM injection, please refer to the EB DOM Injection Guide.

http://ebzebra.github.io/docs/1.4/index.html#guide-DOMinjection

 

Sabir Valappil Thattath is a Senior Software Engineer with Zebra Technologies

Download Enterprise Browser 1.5

Enterprise Browser is a powerful, next generation industrial browser enabling developers to build feature rich web applications that integrate seamlessly with the features in Symbol Technologies mobile computers and peripherals - such as barcode scanning, signature capture, printing and more.

 

Enterprise Browser applications leverage standard web technologies (HTML5, CSS3, and JavaScript) to run and integrate with virtually any Symbol Technologies devices running Microsoft© Windows Mobile, Windows© CE or Android. With support for the legacy Application Programming Interfaces (APIs) used in PocketBrowser and RhoElements Shared Runtime, Enterprise Browser is the ideal path forward for developers looking to migrate legacy applications to newer devices or to create applications with today’s highly-graphical and intuitive user interfaces.

 

Enterprise Browser features will speed up your application development time, reducing costs and making the transition to next generation devices and operating systems fast, easy and affordable - especially in high volume mobile environments.

Version 1.5.0.0(1.5.0.0):

  • New Zebra Device Support
  • Zebra WM/CE Device Support
    • WorkAbout Pro 4 Windows Embedded Handheld 6.5
    • VH10 CE 6.0
    • Omnii XT15 CE 6.0
    • Omnii XT15 Windows Embedded Handheld 6.5
  • Zebra Android Device Support
    • MC67 Android KitKat
    • TC70 Android Lollipop
    • TC75 Android Lollipop
    • WT6000 Android Lollipop
  • Ring Scanner Support on Android Platform
    • RS4000WT6000 Android Lollipop
    • RS507
    • RS6000WT6000 Android Lollipop
  • New Enterprise Browser APIs
  • New Configuration Tags
  • Android Configuration Tags
  • WM/CE Configuration Tags

 

 

Download Enterprise Browser 1.5

A lot of new features have been introduced in Enterprise Browser over the last two release including support for new Zebra Android Devices. Please see the list below.

 

 

Version 1.4

 

 

 

 

  • New Configuration Tags
    • <usedwforscanning> - Allows Datawedge to be used for scanning in EnterpriseBrowser. Refer to DataWedge Usage and Compatibility documentation for more details. Applicable to Android platform only.
    • <LogTrace> - Controls the logging of TRACE messages generated by the Enterprise Browser. If set to 1, enables Trace, Info, Warning and Error logging. Applicable to Windows & Android devices.
    • <KeepAlive> - Controls whether HTTP connections will be maintained between requests. When disabled, connection is closed when its request is complete. Applicable to Windows Webkit Engine only.

 

Version 1.3

 

 

    • DOM Injection
      • Provides ability to include/inject JavaScript, META Tags, CSS into the DOM at runtime for applications running on Enterprise Browser. This allows application behaviour to be changed at runtime without modifying actual application source.

 

 

 

 

 

 

    • On Device Configuration
      • Carry out Key Enterprise Browser configuration in Real time/on-demand within the device without connecting it to desktop.

 

 

 

    • New WiFi and Battery Indicators for High Resolution Zebra Android Devices.

 

    • New UI Graphics for Control/Debug Buttons.

 

 

    • New Configuration Tags
      • Splash Screen Configuration
        • <SplashScreenPath> - Used for specifying the fully qualified path of an image to be displayed at device start-up. Applicable to Windows & Android devices.
        • <SplashScreenDuration> - Used for specifying the length of time (in milliseconds) to display the image. Applicable to Android devices only.
      • Shortcut Creation Configuration
        • <ShortcutCreationEnabled> - Used for controlling automatic creation of multiple shortcut. Applicable to Windows & Android devices.
      • DOM Injection Configuration
        • <CustomDOMElements> - Used for specifying the path of a device-resident file containing data for injected DOM elements. Applicable to Windows & Android devices.
      • Settings - On Device Configuration
        • <SettingsButtonEnabled> - When enabled, places a settings button at the bottom right corner of all screens that routes to the settings page. Applicable to Windows & Android devices.
        • <SettingsPageProtectionEnabled> - When enabled, prompts for a password before allowing access to the Settings page. Applicable to Windows & Android devices.
        • <SettingsPagePassword> - Contains the password for accessing the Settings page when password function is enabled using the SettingsPageProtectionEnabled tag. Applicable to Windows & Android devices.
      • Exit Password Prompt Configuration
        • <ExitPasswordEnabled> - When enabled, prompts for a password when quitting an Enterprise Browser application. Applicable to Windows & Android devices.
        • <ExitPasswordValue> - Contains the password for quitting Enterprise Browser when function is enabled using the ExitPasswordEnabled tag. Applicable to Windows & Android devices.
      • Intent Configuration Option.
        • <EnableReceiver> - When enabled, the application can be called upon by other apps to perform Actions. Applicable to Android devices only.
        • <IntentAction> - Specifies the Action for which the receiver is to be registered. Applicable to Android devices only.
        • <IntentCategory> - Specifies the Category under which the receiver is to be registered. Applicable to Android devices only.
        • For more information about Intent, please refer to the Android Developer Forum

 

Checkout the latest Enterprise Browser 1.2 with new device/platform support and new APIs:

 

What's New:

  • SAP ITS Mobile Compliance
  • New Device Support
    • WorkAbout Pro 4 CE 6.0
    • MC18 Android KitKat
  • New APIs
  • New Feature Demo Application.
  • New configuration tags
    • <ZoomInKey> & <ZoomOutKey> - To ease the usage of Applications running on Enterprise Browser, users can now configure Hardware Function Keys to perform ZoomIn and ZoomOut operations without having to make changes to the application. Applicable to Windows devices only
    • <DisableScannerInApp> – This tag has been introduced to disable barcode scanning abilities for legacy Scanner API. This setting will not effect the behavior of barcode scanning in the License dialogue. Applicable to Windows devices only
    • <isWindowsKey> – This tag has been introduced to mimic Windows Mobile key codes for the device's hardware keys. If enabled then the application will get the Windows Mobile function key code value for F1 to F12 keys instead of what Android would send normally. This can be useful to support both types of devices with one codebase. Applicable to Android devices only which consists of hardware keys.

Introducing : Enterprise Browser

Enterprise Browser is a powerful, next generation industrial browser enabling developers to build feature rich web applications that integrate seamlessly with the features in Symbol Technologies mobile computers and peripherals - such as barcode scanning, signature capture, printing and more. Enterprise Browser applications leverage standard web technologies (HTML5, CSS3, and JavaScript) to run and integrate with virtually any Symbol Technologies devices running Microsoft © Windows Mobile, Windows © CE or Android. With support for the legacy Application Programming Interfaces (APIs) used in PocketBrowser and RhoElements Shared Runtime, Enterprise Browser is the ideal path forward for developers looking to migrate legacy applications to newer devices or to create applications with todays highly-graphical and intuitive user interfaces. Enterprise Browser features will speed up your application development time, reducing costs and making the transition to next generation devices and operating systems fast, easy and affordable - especially in high volume mobile environments.

 

 

Key Features

 

Enterprise Browser: An application development toolkit for mobile cross-platform enterprise apps

* Supports all enterprise devices: mobile computers, tablets, kiosks, wearables and vehicle mount

* Supports multiple operating systems: Windows © Embedded Handheld, Windows © CE, Windows © Mobile and Android ©

 

Build apps using HTML5, CSS and JavaScript

* Use web skills to create beautiful applications

* Based on open source and standard technologies, not proprietary toolkits

* Access the world's largest developer community

 

Common APIs across all enterprise devices

* Single code base; does not require different APIs for different OSs to create a true write once, run anywhere experience

* Easily access device capabilities with JavaScript APIs

 

Backward compatible with PocketBrowser

* Enterprise Browser is compatible with legacy PocketBrowser APIs, enabling a clear path forward for legacy applications

* EMML (Meta Tag) support extended to Android

 

Backward compatible with RhoElements

* Enterprise Browser is compatible with legacy RhoElements JavaScript APIs enabling a clear path forward for "RhoElements Shared Runtime" users

 

Unparalleled access to device capabilities

* Access all device features, including bar code scanning, signature capture, printing, RFID and much more.

 

Thin client architecture

* Simplifies device deployment and management by enabling instant application updates on devices; ensures version consistency.

 

Operating system "lock out"

* Hides access to distractions, such as web-browsing and games; simplifies user interface and eliminates risk of unauthorized changes to device settings.

 

Full screen display

* Maximizes available display space for a richer, more effective user interface; hides command bar and Start menu

 

Download Version 1.0 Today

Filter Blog

By date:
By tag: