Data management

After setting Glass state user can share new widgets or see widgets that was previously shared in relation with current state. This chapter explain in more details the internal mechanism of managing shared data. You may find us repeat some details covered already by other chapters but from another angle.  

Setting Glass state 

Before data can be shared it is required by app to set the glass in a state that data is refer to. This application is very abstract and does not refer to some specific object, but to objects in the world generally. Real applications you will create will probably refer to the state of some specific object or context. This can be for example a code that represent product, number that represent some physical measurement, details of location, text that represent book, some String that represent a state of application, URL that represent website and more. As long as you can represents states of objects in the world you can use Content Glass to share various widgets in relation with those states. This is what Content Glass is all about. But before you can share widgets and before previously shared widgets are exposed, the state of the glass need to be determine.  In our app we refer the user to TextStateIdWizard where user can set some text, and we assume that this text is the code that represent a state of something. You will note that once state is set an options menu become available with various options related with the started Glass. 

Creating Widget

Once Glass state was set you can use the options menu to create new widget. In out application we are using simple text widget. But what happen to the widget from now on? 

After widget is created it is managed by the storage mechanism of content glass. The storage mechanism combines local storage and remote storage which are cooperate in order to hold widgets info and share those widgets with peers group. Note that what we explain here is entirely handled by Content Glass and you should not write any code or do something else.  Yet it is good idea to understand those concept, so you can have as developer a broader perspective of the Content Glass system.   

Local Storage

The local storage is a storage managed on device.  When widgets are created they are put in a module of Content Glass call Storage-Model. The storage model holds registers for various states of widgets. New widgets are stored in the "Pending" storage register. Widget in the Pending storage are visible by the user that created the widgets but are not shared yet with anyone else. The information is stored locally. Some special settings can be shared so that local storage will be shared across different apps. This mode however is not used by this application. Anyway widgets are stored into internal files. If you close and open the application the widgets will still be there. And of course in order to expose the widgets you need to set the state of the application to the same state as being used for creating the widgets. For example in the supermarket ref app, widgets are shared in relation with bar-code of products. To expose widgets the user need to scan the bar-code that put the Glass in a state for this specific product. Widgets that has previously shared in relation with the product can now be viewed.

Setting Peers Group

In order for widgets to be shared with other users it is required to set the peers group corrsponding with the widget. In some app patterns the peers group is set by users. In other apps (see for example the Supermarket Space Glass ref app) the group is dynamically controlled by the app itself. In this sample app user can set the peers by clicking the "Edit Peers Group" in the context menu of a widget. This will open the Peers Group Editor  where user can add one or more peers. Peers are added from user's accounts on various social networks and Email services (e.g Google, Yahoo, Facebook etc'). This way user can set the group with whom the widget is shared. It means that if referring users uses the same app and get into same state, the widgets will be exposed to them.

Remote Storage 

When widget is set with peers group, and one or more social accounts is being connected, the widget is stored on Conten Glass remote service. This is handled by internal operation that sync between local storage registeres and remote storage. The sync operation save "pending" widgets on the remote storage and also if there are other widgets that has benig previously loaded from remote and was modified, the modification is saved to remote storage. Again, this is an internal process and usually you should not call it programatically. After widget is being set in the remote storage it can be shared with other peers.

Loading Shared Widgets

The second operation that deals with the remote storage (beside the "sync local and remote" operation) is the operation for loding shared widget. This operation is being invoked internally once Glass is started and its purpose is to load from remote storage widgets that has been shared with current user. Since user may be connect with more then one social account (e.g. Google and Facefook) the operation uses a concatenation of user's identities on connected networks, in order to search for shared wigets. So that shared widgets are loaded in corresponding with Glass state and user's connected identities.