Esper Web Apps

An Esper web app is an Android web application that users can upload to their Esper tenants. You might use this service rather than a traditional app or Google Web App if the website you want to base it on uses HTTP. Esper web apps also allow you to apply managed configurations which adds a layer of further customization. 

If you have GMS devices, you can use the Play Store to configure a Web App. 

If you have non-GMS devices, or for more customization, use this Esper Web App guide. 

In this article: 

• Getting Started
• Customizations
  • Basic Customization
  • Other Customizations
  • Managed Configurations 
• Installation and User Permissions 

Getting Started

To request an Esper Web App, create a support ticket and share the following details: 

• Target App Name
• URL 
• Icon (512 x 512 px PNG file)
• Display Mode

See Customizations for detailed information 

Customizations

Basic customization information is shared with our team in order to build the web app. Further customizations may be requested. This process typically involves working with a support agent to understand the requirements.

Basic Customization

Name 

Enter an app name that will appear on the device and in the Epser tenant. 

Target URL

Enter the URL of the website for the web app. 

Icon 

Upload a 512 x 512 px PNG file. 

Display Mode

Default 

In default mode, the app will show a status bar, the app title, a web page, and a navigation bar. 

Minimal 

In minimal mode, the app will show the status bar, web page, and navigation bar. 

Fullscreen 

In fullscreen mode, the app will show the web page. The system bars are hidden by default but can be revealed with gestures. 

Other Customizations

You may be requested to share other customization information after basic customizations are provided.

Clear App Data 

Once the app is moved to the background, all user data will be cleared. Use this option if the app is intended for one-time use by customers. For example, a check-in app in a healthcare setting.

Open a New Window in the Current View

By default, the app will only open links in the current window and not in a new tab or window. Set this setting to true to allow links to open in a new window. 

Show Toasts

A toast is a temporary error or warning message that sometimes appears. 

• Error: A red box with white text will appear. 
• Warning: An orange box with black text will appear. 

HTTP Allow Domains

By default, Esper web apps will not load domains beginning with http. 

You can allow multiple http domains by entering the web addresses in a comma-separated list. There is also an option to allow all HTTP domains. 

Managed Configurations 

Esper web apps allow you to manage many types of app configurations. Use the Esper console to apply managed configurations after installing the Esper web app on the device. 

Allowing and Blocking URLs

Expected Behavior

Let's go over some of the expected behavior for the app if allowed or blocked URLs are used. Some of the behavior may be exclusive to web apps. See Blocking URLs with JSON to learn how to use block lists for other types of apps. 

List Entries

• The wildcard character ("*") will try to match any character or sequence of characters up to that point if included in the entry
• Protocols (e.g. HTTP & HTTPS) will be ignored
• Blank entries will be ignored
• Entries will be trimmed of excess whitespace

URL Checking Process

• Protocols (e.g. HTTP & HTTPS) will be ignored
• If the wildcard is present in the Allow list then any site will be accessible
• If the wildcard is present in the Block list all sites, except those in the Allow list, will be blocked
• The loading site will first be compared to the Block list if that list has a standalone wildcard entry or if not explicitly blocked before being compared to the rest of the Blocked entries
• If the site is not blocked (either by an explicit entry or via wildcard) or explicitly stated in the Allow list, then the site will be allowed to load
• The crafting of your lists may require some tweaking and experimentation as your live service changes to ensure the behavior you want.

In the following examples, we break down the differences between the allow and block lists and how to use wildcards ('*') to indicate additional characters in a URL. 

Basic Example

Let's say that the user has defined the following for their lists:

 { "UrlBlockList": [ "twitter.com", "en.wikipedia.org*", ], "UrlAllowList":[ "en.wikipedia.org/wiki/Esper" ] }  

If the device user attempts to navigate to "twitter.com", then the attempt will be blocked. However, if they attempt to navigate to "twitter.com/esper" then the attempt will be allowed, since it is not explicitly blocked and no entries within the block list with wildcards match the URL.

If the user tries to access any English Wikipedia page, except the Esper Wiki page, they will be blocked. However, if the user tries to access any other language variant or even the mobile variant of a Wiki page then the site will be allowed to load.

Generic Wildcard Example

Let's take the following list:

{ "UrlBlockList": [ "*" ], "UrlAllowList": [ "mysite.com*" ] } 

In this case, if the device user tries to access any site that is not a subdomain of “mysite”, the attempt will be blocked.

However, this could mean that third-party services that might be used by the site, for example, an SSO login service, may be blocked and will need to be allowed to get the expected behavior.

In some cases, the site may try to redirect you to a different subdomain. For example, a mobile variant (e.g. “m.mysite.com” or “about.mysite.com”). With the rule defined above both of these domains will be blocked.

Installation and User Permissions 

Once the web app is available, you may install it on the device. On the device, the user will be asked to accept the following permissions: 

• Camera: For web pages that may make use of the device's camera (e.g., QR-code scanning, etc.). You may need to set the device's Camera App to the SHOW state in the device details section.
• Location: For web pages that may use the device's location (e.g., maps, etc.).
• Microphone: For web pages that may use the device's microphone.
• Storage: For uploading or saving files to the device (if allowed).

These permissions may be changed at any time via a template, blueprint, API, etc.