Overview

Location Glass is characterized by interrelating CG widgets with a location provided by some location technology. It means that when a widget is stored it is related with Glass Type which equals to a name of location technology such as GPS, Golocation, etc. and Glass Id is set to an identifier extracted from the location info. For example concatenation of latitude, longitude and proximity factor (such as 32.066158_34.777819_00.1).

Start Conditions of Location Glass

Starts conditions on Location Glass & derived implementation are a little bit different in concept than other glasses. On some glasses the start condition is a distinguishable and separated event. For example, on Website Glass we declare page loading as start condition for creating the Glass and fetching related widgets. 

In the case of Location Glass the situation is more complicated because starting a Glass and checking related widgets for any change in spatial coordinates is not practical. Accordingly the logic of start condition tends to be more sophisticated.

Navigation events: This is the simple case that assumes that the API for getting location info, is equipped with event mechanism that can be programmed to fire an event whenever a device is positioned in some location. Having an API that supports location based events, the system can start the Location Glass when application is started, read from Widgets storage module a list of all the widgets related with the Glass set for the current application, and program the Location based API to fire an event whenever a condition matches the location related with one of the Widgets in the loaded result set. Whenever an event is fired the Glass will then go and load the related Widget and render it.

Using pulling combined with app state:  In this case we assume that the Location based API is unable to receive events that can be programmed to fire in a given preset location that in result will cause CG API to request a related widget. In this case the application needs to check repeatedly for each location user state if widget is related with current location. Sending repeated requests to server in order to check if some widget matches the current location is a case of ‘pulling’ methodology. Generally speaking ‘pulling’ is when the client initiates repeated requests to server for checking if some information on the server exists for a given situation. The opposite is ‘pushing’ on which the server pushes information to client when information that matches a given state exists, and the client receives an event for the new incoming message.

Since we want to reduce the number of requests to the server, and optimize the pulling rate, we can and need to use (as much as possible) external conditions and applying heuristics.  For example an app may decide to restrict the area on which Widgets can be shared. So as long as we are not in this area we should not perform any request to the server for checking for match widgets. This however can be improved with the use of ‘Proximity Factor’ attached as part of Widget’s Glass Id. The term proximity factor is used here to define a distance from the original location with which the Widget has been related. One can think of proximity factor as the resolution of exposing a widget; for example if the proximity factor is 1KM the Widget can be exposed in a distance of up to 1KM before or after or near the original location. It means that instead of pulling freely the application can send request to the server each 1KM and still be capable of detecting Widgets.

A numerical example will clarify this: Assuming Widget has been shared on position: 50 latitude and 40.logitude (Not real location info but this will explain the point). And the proximity factor is 5 units. The question is how do we formulate Glass Id in order to optimize requests pulling (i.e. reduce the amount of requests to the server)?

If Glass Id will be formulated as fixed string: “50:40” then we can detect the widget as related only when having exact match with current location. It means that we will have to send requests for each change in 1 unit in the location info, and we will be able to detect the widget only if having exact match of latitude and longitude.  

If on the other hand the Glass Id will be formulated as an expression that assumes a proximity factor:  x[>=45 AND  <= 55],y[>=35 AND <=45] then detection of a Widget becomes much easier since we check a range  of +-5 around the original location where widget has been set. In this case we can send request to the server each 10 (+-5 range) units and still be capable of detecting widgets.       

Combining Location Glass request with Other Glass request: In some cases the most efficient way is to merge location based request together with a request generated by other Glass.  For example, merging the request performed by Website when a web page is loaded together with current location properties of the user in order to fetch widgets related with webpage and at the same time search for widgets related with current location. In these cases the glass can be some custom type (for example website_location) and the Glass Id will combine properties of location together with other glass properties (for example: [url]_[location])      

Examples

Example1: Clue Following Game:

Location Glass is used for the purpose of “Clue Following” game together with GPS based mapping application. A peers group is separated into two logical groups. One group sets the “clues” using Note Widget attached with location, and the other group follows the clues. The clues (widgets) are invoked whenever the “searching” group is in the location (+- 100m) where a clue widget has been left.

Glass Type: location

Glass Id: Expression made by location properties and proximity factor

Fetching method: pulling that starts when groups are in game area

Example2: Parking place reminder

The parking place reminder is intends for those who tend to forget where in the city they left their car. The idea is very simple: when parking the car user creates a LocationNote widget, that combines location properties together with free text/voice so user can add for example the street address where the car was parked and associates the Widget with the current location. The proximity factor (area radius) can be tuned based on need. When the person needs to return to the car he starts the application. The application start to send requests to the server with a rate based on the proximity factor (pulling). When the person gets in the area where the car was left the note is presented with the accurate street address where the car was left.   

Glass Type: location

Glass Id: Expression made by location properties and proximity factor

Fetching method: pulling