The Glass is a software module that allows CG widgets to interrelate with some context based on identified states of the underlying context. In terms of programming one can think of Glass module as a container for running the other modules provided by CG client API. Therefore understanding Glass module life cycle is important for understanding the general workflow of Glass based application
Glass Module Create Procedure
Glass implementation is used as a container for loading other CG resources required for the operation of CG Client API on a certain client.
Bellow a flowchart showing the creation process of a glass instance
- Device Adapter that handles the interaction with device specific resources.
- Networks Adapter that handles the interaction with networks from where Personal identities are loaded.
- Storage Adapter: that handles the storing logic and interaction between local storage and remote storage.
- Widgets Adapter: on some Programming Language libraries it will be required to use a special adapter that mediates widgets operations. In those cases the Glass is responsible for starting Widgets Adapter resource.
- Views Adapter: on some PL libraries it will be required to use Views adapter that mediates views operations. In those cases the Glass is responsible for starting Views Adapter resource.
- Other required shared resources.
The Create procedure is initiated by either external software where the API is directly installed, CG tool of CG Add-On or Plugin.
As a container, the glass provides the top level interface for managing Widgets, as depicted schematically below. This includes functions for creating, deleting, saving and getting widgets. It means that external software (Direct Integration) or CG Tools interact with the Glass module in order to perform general purpose activities. Interacting directly with more specific modules is an advanced state of CG programming and allows more control, but may also require better knowledge of the API in order to prevent unwanted behavior.
The Glass provides the top level interface for starting and loading management views. For example, loading the Networks UI for signing-in to various networks for getting personal identities and friends contacts, is initiated from the Glass module, that in turn call the Views module for implementing the actual request, as depicted schematically below. This includes functions for showing and hiding widgets, and getting a view or a plurality (library) of views, for example in order to set some property for all views.
Glass module 310 is responsible for drawing Widgets in the scope of context identifiers. The Glass has access to storage where all the existing widgets are stored and access to the Widgets module, for creating new widgets, and these capabilities are combined for the purpose of rendering new and existing widgets on top of or in relation with the underlying Context for which Glass is implemented.
Content Class API includes implementations to be used with different programming languages and run on various devices with different Operating Systems. All implementations follow the same global CG spec, but may include specific implementations for accessing specific resources which are unique to the device. In the same manner, rendering technique of Widgets may vary between devices and programming languages.
As depicted schematicall, Glass mechanism includes a function for rendering a single widget 1010 and a function that iterates over widgets that need to be rendered and calls the single rendering function for each widget, thus rendering all widgets . In addition widgets can be cleared.
Glass module provides an interface for registering Event Listeners that may get notifications of the various lifecycle 1100 events of glass and/or widgets as depicted schematically below. This way both external software and internal modules may be notified regarding various events. For example, software may be interested to be notified when a network for personal entities has been connected or disconnected, or when a new widget has been created, or when rendering of widgets has completed etc.
Creating Custom Implementations
Since Glasses may interrelate with different Contexts, Glasses may have different implementations. All implementations share the same concepts but may interrelate with different contexts, and may be implemented with different programming languages (PL). To support this requirement the API provides an Abstract Class/Prototype of Glass that may be extended for the purpose of creating various implementations for various Glasses. This Abstract Class/Prototype is provided for various PL.
The Mechanism of relating content and Glass context
As depicted schematically below, the Glass concept always assumes that certain Context at a certain state is identifiable 1200. For example a URL (state) of Website (context) is given. Or a Condition (state) of Application (Context) is given.
Thus Glass, which is the layer intermediate Context and CG Content (Widgets) is created on some state of Website or in relation with a state of an application and is assigned with:
Glass Type: a parameter that represents the type of the Context
Glass Id: a parameter that represents the state of the Context
The Glass is a layer and container for managing the storage, creating and rendering CG Widgets. And since Glass was assigned with Glass Type and Glass Id it is possible to relate any managed Widget with these two parameters.
The relation of Widget and Context is handled in the Storage . When saving a Widget the records in database or storage node (depending on storage type), are set with Glass Type and Glass Id parameters. Accordingly, when fetching a widget in order to be presented on some Glass, it is loaded from records or nodes marked with Glass Type and Glass Id. This way Glass knows which widgets need to be fetched from storage for a given state of the underlying context.
Glass Type and Glass Id properties may not be part of the widget content. This design consideration helps to simplify various management operations that may be performed on a Widget during its lifecycle; for example, migration of widget across contexts or swapping widgets between two contexts (Content linkage operation).
The mechanism of fetching context related Widgets
The figure below presents a general flow for searching Widgets related with a given Glass Type and Glass Id. In a given Context state – Start Condition, a Glass is created with a given Glass Type and Glass Id properties and then the related Widgets are fetched from either local or remote storage.
For example, when a website page is loaded (Start Condition), and assuming CG client is integrated and connected 1310, a Glass is created with Glass Type=”website” and Glass Id = [Page URL].
The Glass then calls the Storage module 1360 in order to fetch all Widgets related with the given Glass Id and Type.