In the last years, context-aware applications have become a common practice for developing mobile applications. Foursquare, Facebook, Yelp are only a few examples of such applications, and many more continue to appear daily. In general, context-aware applications follow the following models.
Model 1: A unique Web application hosted on a Web server, accessible over the Internet via one or several URLs, connects to the application database and displays the data to various clients (usually a mobile or desktop Web browser). Rendering of the application's view is done on the Server and is only displayed on the client.
Model 2: A unique native application (mobile or desktop) running on the user's computing device connects to the application database over the Internet and displays the data to various clients. The rendering of the application is done on the client device; only data is retrieved over the Internet.
However, the existing approaches to attach context-aware digital content to physical objects suffer from various limitations.
First, in existing approaches (both Case 1 & 2) the content is always delivered via a unique application, which means the run-time “behavior” of the application is contained and constrained within the application at design-time, and the only run-time dynamic behavior is on-the-fly rendering of generic content within the application. In Case 1, context-aware Web applications usually are a simple Web site that can capture the current location of the user using HTML5's Geolocation API if supported by the client browser, and is sent along with the request the server to fetch and display various content is served depending on the user location. A common example is a user accessing a digital mapping service such as google maps (for example he uses his phone to browse to http://maps.google.com), which will always display a map centered around the current location of the user (or simply any address typed in by the user), with a list of nearby services, such as restaurants, shops, etc. Because of this, adding new location-dependent information is always done within the same application template (users can extend the application by adding various new points of interest to the map). This means even though the content displayed varies according to the location, the application itself remains the same (maps.google.com always displays “just” maps). This prevents people from creating custom applications individually that deliver various behaviors for the single entry point (the source URL). This limits the creation highly interactive and interactive applications that can entirely change adapt the content to your location with minimal user intervention.
As an example of Case 1, context-aware applications on the Web are accessed using a single entry-point (usually their URL, e.g. http://foursquare.com), which will launch always, the same unique Web application. The context-aware information is always sent to the same application, and is used only to display diverse information within a single, uniform view.
In this case, there is only one single application that is associated with a given entry point (the source URL: foursquare.com), and the entire experience and behavior is entirely controlled by that application. In such applications, users can only import context-dependent information (for example a bar in my neighborhood) that will be displayed by the application uniformly. The behavior the user sees is always hard-coded within one application, therefore it is very difficult to add new behaviors without modifying the entire application. In many other situations (Case 2), the location-aware application takes the form of a mobile application that must be downloaded, installed, and run on the device. This means that all the behavior available within the application is constrained by a unique and uniform application and must be entirely hard-wired within the application at run-time, which makes it impossible for people to develop and run entirely independent, self-contained, autonomous “bits” of that application that can be triggered by the context of the application.
Second, in case 2 because the behavior is a unique application, the server must hardcode and support the handling of various contextual information available from the client accessing the request, therefore it requires a high coupling between the client application and the server applications, therefore maintaining consistency between across is very difficult as any changes in the server applications, requires all the clients to be updated accordingly to keep working as is currently the case. This makes it difficult to develop robust applications that work across various mobile and desktop platforms.
Third, the context-aware behaviour is usually limited to the location of the user as derived from various positioning systems available on the mobile phone (GPS coordinates). Other types of contextual information, such as the user, the time of the day, or the type of the device can only be sent to one unique target application that can adapt its content. However, this contextual information cannot be used to launch or trigger various, independent applications. This is because the entry point of a Web application (its URL usually) always corresponds to only one given application at any given time (it can be updated). In other words, the current model of Web and mobile applications enforce any one URL to always correspond to only one unique Web application.
Fourth, when the bootstrap URL is encoded into an Auto-ID tag such as a QR code or an NFC tag, and is physically attached to an object, it is not possible to modify the information of the Tag afterwards. Therefore dynamic reconfiguration of the digital action associated with the Tag is not possible unless a level of redirection is used. To allow the action associated with a Tag to change, a redirection service may be used, for example bit.ly. This allows for the creation of a permanent short URL on an intermediary proxy server, where the redirection can be changed at a later point. However, this solution design always maps the short URL to a unique target URL without any support for the context of when the short URI is scanned or read by the end user. Anyone scanning the short URL as encoded in the Tag will be redirected to the exactly the same target URI. This materially limits the scope of application behavior that can be driven from the Tag.