No part of this publication may be reproduced or used in any form, or by any electrical or mechanical means,
without permission in writing from Zebra. This includes electronic or mechanical means, such as photocopying,
recording, or information storage and retrieval systems. The material in this ma nual is subject to change
without notice.
The software is provided strictly on an “as i s” basis. All sof twar e, including firmware, furnished to the user is on
a licensed basis. Zebra grants to the user a non-transferable and non-exclusive license to use each software
and firmware program delivered hereunder (licensed program). Except as noted below, such license may not
be assigned, sublicensed, or otherwise transferred by the user without prior written consent of Zebra. No right
to copy a licensed program in whole or in part is granted, except as permitted under copyright law. The user
shall not modify, merge, or incorporate any form or portion of a licensed program with other program material,
create a derivative work from a licensed program, or use a licensed program in a network without written
permission from Zebra. The user agrees to maintain Zebras copyri ght notice on the licensed programs
delivered hereunder, and to include the same on any authorized copies it makes, in whole or in part. The user
agrees not to decompile, disassemble, decode, or reverse engineer any licensed program delivered to the user
or any portion thereof.
Zebra reserves the right to make changes to any software or product to improve reliability, function, or design.
Zebra does not assume any product liability arising out of, or in connection with, the application or use of any
product, circuit, or application described herein.
No license is granted, either expressly or by implication, estoppel, or otherwise under any ZebraTechnologies
Corporation, intellectual property rights. An implied license only exists for equipment, circuits, and subsystems
contained in Zebra products.
Revision History
Changes to the original guide are listed below:
ChangeDateDescription
-01 Rev. A1/10/2013Initial release.
-02 Rev A7/15/2014Add description for Wait/Quit behavior.
-03 Rev A2/28/2015SB1 RevC Features
Add description for hour glass.
Add details for additional configura
Add keyboard APIs an
Rev B.5 changes.
d samples.
iii
tions introduced in config.js.
ivSB1 Programmer’s Guide
TABLE OF CONTENTS
Revision History.............................................................................................................................. iii
Using Mobility Services Platform 4.0, p/n 72E-128802-05
About This Guide xxxvii
For the latest version of this guide and all guides, go to: http://www.zebra.com/support
xxxviii SB1 Programmer’s Guide
CHAPTER 1INTRODUCTION
This guide provides the starting point for developing applications for the SB1 Shell environment. It provides
basic information about the system environment, what types of applications can run in this env iro nm e nt ,
system libraries and how to access device capabilities.
The SB1 Shell is a multi-instance, multi-tasking application which enables RhoElements “hybrid”
(HTML/JavaScript) applications to run concurrently, interact with each other and share device and system
resources. The Shell runs within RhoElements and uses the Webkit engine. This means that most rules and
specific attributes that can be found in Webkit are available in the SB1 Shell.
SB1 System Applications/Shell UI Services
These applications are:
•
Home - the starting point of the SB1 Shell and gives access to all its functions and applications.
•
AppLauncher - responsible for listing and managing client applications. Also includes a Task Manager
enabling users to observe running apps as well as quitting them.
•
Settings - provides UI for managing device capabilities and SB1 Shell settings. Settings is split into
different sections.
• Main settings - Provides basic UI for observing battery and wireless status as well as volume and
beeper control.
• More settings - Provides control points for PTT Express, Screen calibration, Beeper settings and
Advanced Settings. This menu item can be protected by PIN.
• Advanced settings - Provides control points for Device Manager Settings, RD Client, Wireless and
Date and time settings, Software Version etc., This menu item can be protected by PIN code.
•
Lock - Lock screen is a web page which will be displayed when user configurable inactivity time reached.
This lock screen can be configurable in config.js or and API can be used to set custom lock screen.
1 - 2SB1 Programmer’s Guide
Figure 1-1
•
Figure 1-2
•
•
Lock Screen
Badge - Badge screen is a web page which displays when user device moved to upside down and
configurable delay time reached. This badge screen can be configurable in config.js or and API can be
used to set cuctom badge screen.
Badge Screen
Notifications - gives access to the notificat ion s re ce iv ed fro m th e different server applications, from
other devices and the system itself.
Profile - provides the user a way to customize their SB1 by setting their name and title as well as signing
out or switching device.
Introduction1 - 3
Settings PageApp Launcher
Profile PageHome page with Wireless
and PTT Shortcuts
Home Page
Badge ScreenLock ScreenNotification List
Figure 1-3
Namespaces
This section provides information on the JavaScript objects namespaces, e.g. each layer in the Structure
section is encapsulated by a JavaScript object (namespace):
•
•
•
All of the modules described are provided with their namespaces.
System Applications
Application Shared Library - asl
Shell UI Services - sui
Shell System Library - sys
1 - 4SB1 Programmer’s Guide
Figure 1-4
Structure Diagram
SB1 Client Applications
The SB1 Shell is designed to run custom built web based client applications. They are required to meet the
following technical specifications:
Backend
Web applications can implement some specific logic based on the workflow required. The implementation can
be made in various technologies and programming languages (C#.NET, RoR, PHP, etc.). The SB1 Shell does
not interact with the application backend. A pplica tio ns wr it te n in an y clien t- s e rver en vir on m en t ha s to be
hosted on a server and need to be accessible through a network. The SB1 Shell should be configured to know
the address of an application provided as an application URL. SB1 Shell then will create an application icon
and will allow application to be started and running into their own application pool implemented as an iframe.
Frontend
The SB1 Shell runs in in RhoElements web browser that has support for HTML 5. SB1 Shell applications are
HTML page that can be implemented using HTML5, CSS3 and Javascript. This allows application designers to
take advantage of the latest improvements as markup elements, web databases, browser local and session
storages and browser caches.
CSS
The SB1 Shell supports the CSS 3 official specification with webkit extensions.
JavaScript
The SB1 Shell supports the JavaScript ECMAScript 3 with some extensions from ECMAScript 5. Refer to
RhoElements documentation for more information.
Quick Start Guide
Once device open from package box users need to place the device on cra dle to reboot the device an d charge.
After charging the device, now device is ready to configure.
Develop First SB1 Application
Develop any thin client web application and deploy on any remote server or develop any HTML 5 based app
and deploy on device.
1.Connect the SB1 to a host computer using a USB cable. In a file explorer application, the Logs folder and
Fusion data folder display as shown.
Figure 1-5
2.Copy the apps folder and the config folder from host computer to the UserDrive folder on the SB1.
Logs and Fusion Folders
Introduction1 - 7
Host ComputerHost SB1
3.Reboot the SB1.
4.Go to Applauncher and find the Hello application .
Figure 1-6
5.Select the Hello application.
Figure 1-7
Applauncher
Hello SB1 Application
Deployment using RDT Solo for Many Devices
If customers deploy their web applications on any remote server, the proper app URL to be configured in
apps.json.
You can use the Zebra RDT Solo application to upgrade to latest OS, WLAN Profile and application
configurations.
1 - 8SB1 Programmer’s Guide
View the videos on using RDT Solo to deploy applications:
•
Using RDT to stage the SB1 on a WLAN network
•
How to Perform an OS Update on the SB1 Device using RDT
CHAPTER 2APPLICATION INTEGRATION
Each client application that meets the technical specifications can be integrated and installed on the SB1. In
order to create SB1 Shell applications developers should follow specific requirements that are listed below:
•
create HTML5 compliant web application
•
integrate SB1 Shell shared library
This document doesn't aim providing help or res ourc es on cre at ing HTM L 5 com p lian t applications.
Integration with SB1 Shell
System Integration
NOTE If the client application page is to be served from a remote location, it must refer to a copy of the asl.js
library from the same location. This is due to Web Security Standards which will not allow a remote page
to load JavaScript from a local address.
Every HTML page within an SB1 application must include a special library called asl.js. This library provides
the following services in the SB1 multi-instance environment:
•
application services
•
notification services
•
keyboard services
•
shared UI services
•
resource services
•
messaging services
•
authentication services
•
window services.
The following code shows an example of how to include asl.js within an HTML page:
NOTE The asl.js file must be the first JavaScript file included in the client application document. asl is always
the first library that access the document model and document events. This is required because the
application system library needs to setup a connection with the SB1 Shell to initialize the device profile.
Client application logic implementation should never override the asl namespace. Application developers
should never use statements in JavaScript that override the application shared library object - asl.
It is recommended that asl.js is linked to the local SB1 web server on
http://127.0.0.1:83/Application/www/sapp/src/asl.js. This will preve nt applications from dealing with asl
library versions and they will be always using the latest asl file for the current Shell instance.
Visual Integration
The SB1 Shell includes a style sheet file that overrides the default styling of the web document. It is
recommended that client applications running on the SB1 use these styles in order to achieve consistent
application look and user experience. The style sheet can be included in HTML documents by adding the link
tag that is shown in the following example:
Once an application is prepared to communicate with the SB1 Shell by linking asl.js, it has to be installedon the
SB1 instance that will be running it. This can be done by adding the application in the SB1 SHell installation file
apps.json. Depending on the configuration scheme, this file can be found on different locations.
SB1 Shell default configuration file is located on the following location:/Application/www/config/config.js Third
party application providers can override the default con fig uration file by uploading their custom configurations
on /UserDrive/config/config.js. This file is called user configuration file for SB1.
Application Integration2 - 3
One of the settings that user configuration file contains is called config.app s.src which holds the addr ess to the
application list that will be installed.
In general, the SB1 has two primary configuration files:
•
config.js
•
apps.json
config.js File
The config.js file, in the config folder, is the general configuration file for SB1. One of the values it contains
is called config.apps.src which holds the address to the application list that will be installed. By default, the
value is:
config.apps.src = ‘‘/UserDrive/config/apps.json;
NOTE The apps.jason file can be located at a remote location. For example:
Once a remote location is set for this file, the system downloads it to a device location, configured in
config.apps and then fetches the listed applications from this file.
See Chapter 4, Configuration for more information.
NOTE The apps.json file can be made variable based on the logged-in user. If Single Sign-On authentication
is configured, the authentication server can send a different
system loads the user applications once the user logs in successfully. See Authentication Services on
page 3-27 for more information.
apps.json file depending on the user. The
apps.json File
The apps.json file, in the config folder, contains the list of the applications that are installed once the SB1
Shell is configured. It is formatted in JSON, a JavaScript native format. To add an application to this list, create
a list element and insert it before or after any other list el ement in the
file is manual. Take caution in editing. Be sure to include the proper synt ax (i.e., qu otes, commas and slashes).
Modifications to the
apps.json file will not take effect unless the SB1 is rebooted.
name = name of the application. This pa rameter is mandatory and must be unique for an apps.json file,
otherwise the application will not be recognized by the system.
•
url = address where the application can be found. This parameter is mandatory.
•
icon = a path to the icon to be shown in the Applications application on the SB1. This parameter should
be an absolute path. For example: http://example.com/images/icon.png. Relative paths will not work:
/images/icon.png.
•
Applications need a permission to overwrite custom badge. canOverwriteBadge = true can be configured
to overwrite badge.
Table 2-1
S NOConfigurationDescription
1{
Sample app configuration with necessary permissions.
name: "MWM",Name of the app
url: "http:// <SERVER IP >/MWM/TSD",application URL. The application URL may be
either local or remote depends on application
deployment.
canOverwriteBadge: true,Permission for a app to overwrite default
canClearNotifications : true,Permission for a app to clear notifications
canOverwriteProfile : true,Permission for a app to set the profile.
canAddApplications : true,Permission for a app to add dynamically
Icon to be displayed on app launcher
Badge. Applications can set custom badge
using asl.badge()
Depends on user locale shell will be reloaded
in case of localization.
another app
disableKeyboard : trueEnable/Disable a SIP keyboard for the app.
Apps can use their own keyboard.
isProcessApp: false,Permission for a process app. Process app
will not be displayed in applauncher. Add true
for process app and add false for all normal
apps.
canCloseApp: true,Permission for app to close.
canCloseApplications: truePermission for a app to close another App
}
Once configured, the application is accessible from the SB1 Application screen.
Application Integration2 - 5
Figure 2-1
Applications Screen
NOTE The position of the application icon in the Applications screen depends on the position of the
configuration element in the
apps.json file.
Remote apps.json file
The apps.json file can be placed on a remote location and SB1 Shell can be instructed to load the remote
apps.json file by default. This configuration brings a specific behavior on device reboot. Once the device
reboots and SB1 Shell starts, The Shell will try to find the remote apps.json file, to download it and load the
application configuration. In some occasions after reboot the wireless connection is not availabl e at the time of
Shell resource loading e.g. downloading the apps.json file. If the shell detects that the wireless is not active and
file is not downloadable, it will wait until the signal NPAPI object returns a successful status for the wireless
connection and then it will reinstantiate the procedure of downloading and installing applications. A side effect
of this scenario is that users may see the Application Launcher empty until a valid wireless signal is available
and the apps.json file is downloaded.
Starting Applications
When users starts an application, the SB1 Shell will create an application pool (iframe) and will start loading
the application home page. During page loading, the SB1 Shell will display an hourglass icon to indicate SB1
that there is an ongoing process. The SB1 Shell loading cycle includes the following steps:
•
assign an application pool (iframe) for the started application
•
set the application home page as source of the iframe
•
show hourglass to indicate users that application is loading
•
start a timeout function that waits for the application load and handshake process
•
assign an onload event of the application iframe
•
once the onload event of the application iframe occurs, Shell st arts a handshake process which includes
sending system information to the application via HTML 5 postMessage
•
SB1 Shell waits for a response from the application and if it receives it, it will automatically destroy the
timeout and send back to the application an asl onloaded event
If the SB1 Shell does not receive the iframe onload event or a handshake confirmation from the application, in
a configured interval of time it will prompt the user with a notification that informs them that the current
application is busy or not loaded from the server.
2 - 6SB1 Programmer’s Guide
Figure 2-2
Figure 2-3
SB1 Shell Notification - Wait or Quit Application Due to Slow Loading
SB1 Shell Notification - Reload or Quit Application Due to Slow Loading
Figure 2-4
The Shell tries to reload the last requested page automatically once th e network is restored. Once the ne twork
is connected, the device IP address will display at the bottom of the no network image.
Not Connected to Network
NOTE Application handshake process is handled by the asl library. If this library is not included or not accessible
in the application iframe, applications will not be able to work in the Shell environment and users might
consistently get the Wait/Quit notification.
Developer Content
All developer content can only be placed in the \UserDrive folder of the SB1. Basic configuration of an SB1
should have a folder structure similar to:
Loading...
+ 92 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.