The PureWeb® platform provides powerful tools for building interactive and collaborative applications that deliver a seamless user experience in real time on web browsers and mobile devices.
This high-level, technical overview describes the key building blocks and concepts that come into play when you write, configure and deploy applications using the SDK.
The PureWeb SDK consists of service-side and client-side API libraries and a turnkey web server. The starting point for the solution is the application logic and rendering functionality (the "service"), which you develop in one of the supported service-side languages (C++, .Net, or Java). You then use the PureWeb service APIs to stream the rendered graphics and expose your service's functionality to remote clients. The remote clients are thin front-ends that you build to provide a native web or mobile interface for the end users (HTML5, iOS, or Android). You then use the PureWeb client APIs to access the functionality exposed by the service and display the streamed graphics. Both sides communicate with each other through the PureWeb server, which manages the connection workflow, handles the back-end application life cycle, and also provides web pages for configuration and other system administration tasks.
The approach is the same, whether you are using the PureWeb SDK while developing a new solution from the ground up, or to breathe new life into existing applications that were not originally designed for the mobile world.
The service-side and client-side APIs are really two sides of the same coin, for example:
Typically, when you work with the APIs, you work in the service and the client in parallel: on the service, you choose all or pieces of the application's functionality to make available in the client, then use the service APIs to hook it up to PureWeb; on the client, you develop lightweight handlers to expose this functionality using the client APIs.
When using the SDK, your focus is on exposing the functionality you care about; PureWeb does the heavy lifting for you under the hood: image compression, low-latency streaming, client-service synchronization, back-end application lifecycle, and real-time multi-user collaboration. It also takes care of implementing an input and output thread and managing the synchronization of application state.
PureWeb APIs have three central pillars: views, application state, and commands.
Views are the backbone of the client user interface. You use them to display visible portions of the service application as interactive images to the end users.
Views should not be confused with screen scraping. They are typically used to stream the 2D or 3D visualizations rendered by the service, but in a broader sense, views can be used to display any image data (bitmap) that you tell it to. You can also display several views on the screen at once:
The process for capturing images is relatively straightforward. The basic mechanics is as follows: on the service side, you register a view with a given name, populate a PureWeb-provided object with the bitmap image data to send, then pass this object as a parameter to the method responsible for streaming. On the client side, you create a container for the view, then instantiate the view with the name you provided on the service. That’s it.
Once the view is displayed in the client, mouse and keyboard events are automatically captured and delivered to the service, where you can decide what to do with them (touchscreen input can be mapped to mouse/keyboard events, or can be handled using commands; commands are discussed in the next section). Other API methods allow you to ensure views are updated with new images as needed, and to keep view sizes in sync (when users rotate their device, for example).
The images do not persist on the user's device after the session ends, ensuring that your data remains secure.
The SDK currently supports PNG, JPEG, Tiled JPEG, and H.264. The client APIs provide methods to configure image mime type and quality level. You can choose different configurations for different clients, and for different views within a client.
A command is a simple instruction sent from the client for the service to execute a given function, and may include an optional response sent from the service back to the client.
Commands are very useful for linking client-side interface elements to service-side functionality. For example, if your application has a search feature, you could create an input field in the client and use a command to trigger the search on the service when the user clicks the search button. In a similar fashion, you can use commands to handle touchscreen input, for example to clear the screen when the user shakes the device.
Commands are event-based. Implementing them is straightforward: you create a function in your client to send the command, and you create a handler in your service to respond to the command.
To connect a command on a client to a handler in your software, you register the handler with the service API using a unique ID. You use this ID when sending the command, which allows the API to manage the command call flow under the hood.
Application state is a hierarchical tree of properties and values which resides on both the service and the client. It serves two main purposes:
The application state tree is automatically created and initialized during startup.
The data structure behind application state is actually just an XML document consisting of nested tags and values. This document contains both internal PureWeb elements, and custom elements defined by the developer.
You may be wondering why the SDK provides both application state and commands for communicating between your client and service. One key difference lies in which component is doing the communicating, and it really matters in collaboration scenarios: if you have multiple clients collaborating with a single service, and one of those clients sends a command, only the sending client will receive a response. If, instead, that client sets a value in application state, the change will be seen by the service as well as all of the other collaboration participants.
You can imagine how combining commands and application state can help you build some really useful features. For example, you could use a command to tell the service to capture the screen, save it to the local file system, then tell the service API to generate a URI to the image; by storing the URI in application state, you would enable all of the collaborating clients to download the saved screenshot for later use.
The SDK supports collaboration, where several users can interact simultaneously with the same service session. For example, when collaboration is enabled, if one participant zooms in on a specific part of an image, the view will automatically change in each participant's screen to show the same zoomed-in section. This works even if participants are using different client platforms (an HTML5 client and an iOS client, for instance).
Getting basic collaboration working is as simple as calling into the PureWeb API to create a share URL for your session. You can then provide the URL to interested participants, who use it to join the collaboration session. Everything else is handled under the hood.
To enhance the collaboration experience, the SDK also provides acetate tools that you can use, for example, to display each participant's mouse cursor on all participants' screen, or to enable writing on an overlay on top of views.
The PureWeb server ties your clients to your software, and provides an interface to configure and manage your application. You can set up authentication and security, view logs, and change default values for many properties such as timeouts, ports and log retention period.
The PureWeb server manages the client-server-service connection workflow under the hood. There are two steps needed to make this work:
Once the PureWeb server knows where to find your application, it will automatically field communications with the remote clients, coordinate connections, handle the back-end application lifecycle process, and manage collaboration sessions.
Here’s the typical workflow of what happens when an end uses launches a client: