Context Directory: A Context-Aware Service for Mobile ...

Context Directory: A Context-Aware Service for Mobile Context-Aware Computing Applications by the Example of Google Android

Ralph Löwe, Peter Mandl

Michael Weber

CC Information Systems and Management Munich University of Applied Sciences Munich, Germany e-mail: [email protected], [email protected]

Institute of Media Informatics University of Ulm Ulm, Germany e-mail: [email protected]

Abstract—To enable context-awareness for many distributed mobile applications, an architecture is needed that supports the collecting of disseminated context attributes. After the structuring and storing of context, the interpretation and adaptation with reference to the current context and changes of context must be applied. These tasks are common to a large set of context-aware applications and can be centralized in a context-aware middleware. This article shows the approach called Context Directory, which helps mobile applications to achieve context-awareness. The software architecture and as a proof of concept four categories of context-aware features are described. Context-aware services; context-aware applications; contextaware software development

I.

INTRODUCTION

In 1993 Mark Weiser published his vision of ubiquitous computing [1]. Now, 18 years later, we are discovering a world that gets closer to his vision every day. Driven by the changing market of smartphones and tablets we find two of his three classes of devices in regular use. The next generation of television and smartboards will complete the hardware part of Weiser's vision to his proposed three classes. These appliances hold a growing variety of sensors. Many electronic devices contain and use sensors to enhance the human-machine interaction. New technologies like Near Field Communication (NFC) enable hard- and software to better perceive and interact with the environment. Contrary to the universality of the hardware, the mobile software is very specific to the task which should be performed. Therefore mobile applications mostly support a specific domain and/or task. This concept is supported by Norman, who describes specialized devices [2]. These information appliances are optimized for one purpose. Although Norman defines the information appliance as a hardware part, we herein find the concept in the form of specialized mobile applications. The next step to reach Weiser's vision is more and more becoming a challenge of the underlying software layer. It mirrors the conflicts and ambiguities in human interaction. When humans interact with each other, they use context to

underline what they mean. Computer interactions on the other hand rely mostly on clear communication. If the computing environment utilizes context to better understand the user's intention, then, for example, graphical user interfaces could become less complex. In 2010, a study by Pettey and Stevens emphasized the importance of context [3]. They forecast, that, by 2012, the relationships with provider of context will increase and “by 2015 context will be as influential in mobile services and relationships as search engines are to the web now” . This requires developers to be able to use context more easily and context information to be ubiquitous. II. PROBLEM Efforts have been made to utilize the context of the user and other entities to enhance the interaction. The field of context-aware computing researches the use of context to improve software. This research field evolves driven by the technological improvements. The term context is very complex, which leads to different definitions. One largely accepted definition was created by Dey and Abowd: “Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves.” - [4] This broad definition of context is a good basis for further research. It encloses many cases of context usage. But if one uses this definition he will not be able to meet every aspect of it. Therefore we redefine context as a smaller aspect of this definition and extend the focus in following

Figure 1: Context. Based on [19] and [4].

projects. In our opinion the core of context is any information that can be used to characterize the situation of the user. This information is considered relevant to the interaction between the user and an application. This restricted definition concentrates context on the main target of improving the human-computer interaction. Therefore our definition of context centers on the advantages for the user interaction. The term context-aware computing describes the discipline to create applications that utilize context to improve it in any way. Dey and Abowd define that “a system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task” [4]. Herein the use cases are providing relevant information or services. These two fields are not specific enough. Therefore categories of contextaware applications have been defined. A problem is that these categories overlap partially. Schilit et al. defined four categories of context-aware applications [5]. These four categories have overlapped with the categories defined by Pascoe [6] and frame the following five categories of context-aware applications: Contextual information (also called proximate selection or contextual sensing) describes the supply of context-aware content by an application. Basically this is a form of matching or rating of information by context. For example many applications currently contain a history of terms entered into control elements. That history could be analyzed in combination with the current context. On the other hand contextual commands are a category of applications that change their presentation or execution flow based on the context. One example is a graphical user interface that adapts oneself to the context of the user. For example commonly used buttons could be bigger or elements of the display could stay hidden. An application that performs automatic contextual reconfiguration exchanges parts of the software based on the context. The example mentioned the most is a driver of a printer that will be installed when the printer is in near range. The parts could be drivers, code fragments or whole applications. A possible concept to implement behavior like this is context-oriented programming [20]. Context-triggered actions enable a new form of communication. If you remove input (see Fig. 1) from the model, you can execute whole applications solely based on the context. For instance, user behavior can be analyzed and a context-aware system is able to deduce what kind of application is often used in a certain context. Based on that information the user can be offered certain applications. Similar mechanisms are employed in recommendation engines used by online shopping systems. Applications, which are in the last category contextual augmentation, enhance the perspective on the environment. Additional information is added to the reality and increases the perception of the user. What all these categories have in common is, that they depend on context and context processing. While implementing single research projects some tasks are specific for context-aware applications and are repeated. This

proves that a common middleware for context-aware applications can simplify the implementation and improve the research of context and context-awareness. If we take a step back to the early developments of context-aware computing, we discover the field of locationbased services. Here we find a component called geographic information system (GIS). Hence, if we define that context is more than only location [7], but at the same time context definitely contains location, we will need a context information system that, at least when it comes to location, fulfills the function of the GIS. To acquire the context of a user it is possible that many single computing units need to collect attributes of the context. On the other hand not every context-aware application needs every context element. Therefore a big advantage could be created by centralizing these services in one software component. Based on this principle some research has been made in the field of context-aware middleware. Such software supports context-aware applications with context services, which are interchangeable between applications. Pascoe mentions a context information service which fulfills the main tasks of modeling, monitoring and relating context. Furthermore the middleware needs to address the challenges of context-awareness which Malik and Mahmud [8] identified: Context acquisition is needed to collect the items of the context. Sensors are built in distributed computing units and deliver the data to the context-aware system. A contextaware middleware could centralize the context data. A context representation provides means to efficiently structure and retrieve context. There are many different approaches [9]. A context middleware could support different structuring of context. The history of context and the context changes are important, because the actions of the user could be predicted by such means. Some important research of context transitions has been done by Zimmerman et al [10]. A correctly represented context can be structurized and persistently saved in a context storage. Is the context structurized, a means of context interpretation can be applied. Here we can find different strategies and fields of research such as machine learning or complex event processing to enable the context-awareness. After the context is interpreted the system can perform context adaptation. Information, Services or Actions can be executed or messages could be sent to the computing units to react in a context-aware way.

Figure 2: Context-aware challenges (simplified) [8].

The five challenges and their place in the context-aware process are shown in figure 2. The categories include the three that Pascoe mentioned for a general software component called Context information service [6]. His modeling is very similar to the representation of context, monitoring includes the storage and some further administrative tasks, which are unspecific for contextawareness. Additionally we find the relating of context at the challenge of adaptation. III. RELATED WORK A common problem is that these research projects are mostly single solutions to single problem domains. In the context of research projects some approaches for the realization of a context-aware middleware were generated. Dey et. al published the context toolkit [11], to enable context-aware features for a variety of applications. Other comparable insight can mainly be found in the work of Ailisto et al. [12] or Indulska and Sutton [13]. Among concrete approaches are the Java Context-Awareness Framework (JCAF) by Bardram [14] and the CAPNET middleware by Davidyuk et al. [15]. Other similar approaches include Rossano et al. [16] or da Silva et al. [17]. However the implementation of generic middleware architecture proves to be difficult. On one hand it is not easy to depict the complexity of context within software; on the other hand the middleware´s interfaces have to be easily learnable for developers. Research in the area of contextaware middleware has not been completed yet, therefore there is not enough concrete experience when it comes to the development of context-aware applications based on contextaware middleware. Past context-aware frameworks tried to develop components to model context and context-awareness. For example the context toolkit [11] provides context-widgets, generators, an interpreter as well as a server. It enables a developer to model and construct a context-aware system. The toolkit provides components for the development and a surrounding system and therefore helps to disseminate a context aware application.

approach distributes the parts of the context-aware system in the source code. To meet the requirements of the application developer and the mobile environment, we designed the context directory architecture. The framework focuses on being an optional feature to a mobile application. This assumption is based on the experience, that context-awareness is mostly added after the basic functionality of an application is created. This can be justified by two arguments. On the one hand context-awareness is not yet strongly established in the field of mobile computing. On the other hand context-aware features require a deeper domain knowledge, which mostly does not become clear until the mobile application is actively used. The goal for the context directory architecture is to create a reasonable set of context models, interpretation methods and adaptation possibilities. One aspect is to make the development of context-aware features as simple as possible. A developer, who has no background in context-awareness, should be able to create context-aware applications more easily. Furthermore it focuses on centralizing the usage of one context-aware feature in as few places in the source code as possible. Therefore the danger of losing track of the core functionality is reduced. Because mobile applications must have low battery consumption and should only use the network connection if necessary, we have chosen the client/server architecture over the peer-to-peer architecture. The server fulfils computationally intensive parts of the representation, storage, interpretation and adaptation show in figure 2. The client is therefore reduced to acquisition, representation and finally adaptation and works as a proxy for multiple applications.

IV. CONTEXT DIRECTORY In 2010 we began to implement a service to provide context-aware applications in a more direct way. We chose to implement new software, because the underlying technologies of old approaches use technologies which are now obsolete. For example the context toolkit uses the idea of context widgets to encapsulate the logic but additional widgets are needed to implement a specific logic. Another aspect is the communication between the components. Since it uses host, port and the widget identifier to communicate, many connections must be maintained and opened. In a mobile environment this could lead to much undirected network traffic. The means of context interpretation in the context toolkit are present, but limited to rule-like condition constructs, which can hold complex algorithms, but are per se not intended to. Additionally the implementation of a context-aware system is easier, but the component-based

Figure 3: Architecture of context directory. A coarsely-grained architecture of the context directory architecture and its components is shown in figure 3. In this example two mobile devices have an installed context client. Additionally a context-aware application is installed on Mobile Device A. It uses the context-aware application programming interface (API), which provides devicespecific, context-aware enhancements. Both context clients are each connected to a different context directory. It is not mandatory that each client has one directory. This only shows that context directories could be interconnected and form a context directory network. This holds the advantage that directories can be distributed at different locations. For example mission-critical context information can be saved and processed in a context

directory in the intranet and there is no need to use unsecured connections. The context client is the only part, which communicates with the sensors of the mobile devices. It collects the context attributes and creates the context representation. For the collection of the attributes, we choose the key/value model, because of its simplicity [9]. Many context clients could collect the attributes for different mobile devices and then merge the context in the context directories. We designed the context client as an active part, because it could be instantiated as a context collector only. It assures that a mobile context-aware application works even without a network connection. To save power and mobile network traffic the context client is the only part, which uses a single network connection and supports asynchronous communication going both ways. Another important responsibility of the context client is the registration of available context-aware applications. We discovered that to perform a sufficient adaptation in a mobile application based on context, a construct which describes the possibilities and context semantics of the application is needed. Therefore the context client needs to communicate the application model to the context directory and receives the resulting context adaptation from the context directory. The context-aware API simplifies the development of context-aware applications for a specific mobile platform. For example the components of the graphical user interface are enhanced to support contextual commands. Interfaces for context-triggered actions or contextual information are defined here. A context-aware application could be developed solely based on this interface. If a developer requires more control over the sensitivity of context he could instead communicate directly with the context client. To complete the architecture one or more context directories are needed. The communication between the directory and the client and between the different directories each other is handled by the context directory protocol. Since the directory provides the server part, it needs to listen on a port. Once a context client is connected, the directory can receive the initial context and context updates. It is important to distinguish between these two cases of context collection, because in the case of a context update the performance of the context interpretation can be enhanced. Here collected context attributes from all clients are consolidated and can be stored especially for interpretation based on historical data. Another advantage, which is provided by the context directory, is the possibility to transform the basic context model into other context models needed by the target application. For example the context could be transformed into advanced formats like ontologies for the use in ontology-based applications. For these cases a means to and the semantics for the transformation need to be implemented by the developer. For the functioning of a simple contextaware application, which is based on the key/value model, it is not necessary. Once the context is collected and consolidated, a means of interpretation can be performed. A wide variety of algorithms are researched for the usability in the case of context-aware scenarios [21, 22, 23]. Additionally the

combination of these methods as hybrid solutions is possible. The utilization needs a very deep knowledge of the domain problem and is often too complex for the user to handle. The context directory supports the implementation of complex algorithms, but for single context-aware features we propose simple, comprehensible interpretation methods. Examples could vary from “preselect the option used most in this context” via “if the user enters the building, automatically contact the nearest customer” to “select the most common screen in this room for my presentation”. A developer could then describe the context-aware behavior by using the criteria. In this example the criteria are historic analysis of the context storage, as well as finding the closest location and analysis of the collaborative context. This approach provides the advantage of reusability of the criteria. Many criteria could be weighted and combined to perform a single complex context-adaptation [18]. The definition of which context-aware feature uses which criterion is performed by the developer of the context-aware application. The information is content of the application model which is sent to the context directory. The results of the interpretation are the instructions needed in order to change the context-aware application which resides on the mobile device. These instructions must be communicated to the context-client instance, which is responsible for the context-aware application. The described components represent a complete contextaware system in respect to the model defined by Malik and Mahmud [8]. This demonstrates that context directories are comparable to other context-aware frameworks. V. PROOF OF CONCEPT For demonstrational purposes we implemented a context client for mobile, Google-Android-based, context-aware applications. Since the configuration of context-awareness is performed by the mobile application developer, we designed the context-aware API similar to the standard mobile computing API. We used derived classes of customary components, which can be enhanced to support context-aware behaviour. To minimize unintended network traffic and power consumption, we used piggybacking and made the update frequency configurable. To emphasize the possibility of performing the correct operations of a context-aware system, we describe examples of context-aware features in the following. Since contextaware features must be each handled differently, we distinguish the features based on the groups of context-aware applications defined by Schilit et al. [5] and Pascoe [6]. We use the term feature instead of application, because from a developer’s point of view context-awareness is a nonfunctional requirement like security, performance or efficiency. Therefore the developer can decide how much context-awareness is needed for a specific task. The most obvious features for context-aware applications are contextual commands. They describe the adaptation of user interfaces and the behavior of the executed commands based on the context. For this project we focused on the

graphical user interfaces first, because they are easy to describe and therefore comprehensible. An example of a contextual command is a context-aware combo box. In Google Android such a component is called Spinner. We derived the class ContextualSpinner and implemented the context-awareness via the context client. To function properly, additional source code is required. For every selection element the developer can define a set of constant context attributes that are assigned to the selection. For example a combo box that makes the selection of a city possible, can be extended with context attributes which are the coordinates of the cities. A context-aware system is then able to compare the current context with the possible selections and change the selection automatically. The context interpretation can be applied by selecting the element nearest to the current context. The example is shown using pseudo code in Listing 1. Another example could be to change the visibility and therefore simplify a form. cacombo = new ContextualCombo(combo); cacombo.addChoice(1, “London”, new ContextAttribute(“WGS84Loc”, “51,0”)); cacombo.addChoice(2, “Lausanne”, new ContextAttribute(“WGS84Loc”,”46,6”)); ... cacombo.setAdaptation(Criterion.Nearest);

Listing 1: Source code of contextual command . Under critical appraisal a context directory is not needed for this simple case. But if we anticipate the scenario of ubiquitous computing which allows the contextual command to be executed on a board and the location sensed on a tab, the advantage of this approach becomes visible. As an extended example one can imagine the possibility of multiple combined criteria, which have assigned weights. A more concrete exemplary of the adaptation criteria could be a configuration of a reinforcement learning strategy and the nearest criterion with different weightings.

relevancy for current or past context. The context directory needs to be aware of the information and must derive context attributes. In this case a contextual information plug-in for the context directory for this specific type of information is needed. The downside is that the developer needs to implement an additional plug-in for the server that can contain very specific details for the context-aware application. This only leads to long-term advantages, because the information could be relevant for other applications. The upside is that already implemented algorithms for the context interpretation in the directory can be used directly in the plug-ins. The use of the sorted or filtered contextual information can be handled in the context-aware application and can vary per media type. Mainly the goal of this feature is to increase the relevancy of the information shown. In the past such an approach has been implemented in a similar project [18]. Automatic contextual reconfiguration represents a challenge, because the programming language must be possible to change code fragments at runtime. This is prohibited in many platforms, because it holds security risks. To implement this feature on the Google Android platform it is possible to use the reflection mechanism of the Davlik Virtual Machine. The configuration of such a mechanism is complex in proportion. A future simplification and a way to make this process more secure will be the generating of stubs and helper classes at build time. We discovered that this task is very platform specific. Context-triggered actions can be implemented on many levels. It is supposed to execute parts of applications or whole applications. Both mechanisms require an interface for the context client to call the action. In the case of Google Android we found a tricky way for the context client to install and, if properly installed, start mobile applications. In order to work, the application model including the possible actions must be registered in the context directory (see fig. 5). This can be performed while registering the client. If we now track the context and application use, the need for a specific context-aware mobile application can be guessed.

Figure 4: Sequence diagram of contextual command. The process of the involved components is shown in fig. 4. First the context-aware command must be registered via the context client in the context directory. If a context change occurs the responsible context client sends a context update to the directory. The server can then notify the relevant clients about the change (which is not shown) and perform a context interpretation. The results of the interpretation are sent back via the context client to the affected context-aware components and the adaptation is applied. The combo box selects “Lausanne”. Contextual information can be implemented by a context matching module, which sorts information based on

Figure 5: Sequence diagram of context-triggered actions. Based on the context-history in association with the application invocation a usable application can be instantiated and the user can be informed. Another approach would be to define the action as part of an application and allow it to be accessed that way. In the case of Google Android the action could be an Activity or an Intent.

VI. CONCLUSIONS AND FUTURE WORK One overall insight of the research project is that the impact of context-aware computing is still small in the mobile computing industry. The potential on the other hand grows with every sensor that is added to mobile devices. In this field context-aware middleware supports the development of mobile applications. We discovered that a feature-based approach for context-aware mobile applications promises more advantages than a componentbased one. Another insight was, that generic context-aware middleware needs structural information on the application to make it context-aware. We gave insight into context-aware development and especially into the idea of the project context directory as part of a context-aware middleware. Demands as well as architectural approaches were outlined and the coarse functionality and application of a context directory was described. Fields of usage of context-awareness have been described in association with the project. The remaining feature of context augmentation is very specific and we have not been able to identify common building blocks yet. Next steps and future research include the future development of the software components and a release of a demonstrative prototype of the whole system. REFERENCES

[10]

A. Zimmermann, A. Lorenz, and R. Oppermann, “An operational definition of context,” in Proceedings of the 6th international and interdisciplinary conference on Modeling and using context, 2007, pp. 558-571.

[11]

D. Salber, A. K. Dey, and G. D. Abowd, “The Context Toolkit: Aiding the Development of Context-Enabled Applications,” in Proceedings of the SIGCHI conference on Human factors in computing systems the CHI is the limit - CHI ’99, 1999.

[12]

H. Ailisto, P. Alahuhta, V. Haataja, V. Kyllönen, and M. Lindholm, “Structuring Context Aware Applications : FiveLayer Model and Example Case,” Proceedings of the Workshop on Concepts and Models for Ubiquitous Computing, pp. 1-5, 2002.

[13]

J. Indulska and P. Sutton, “Location Management in Pervasive Systems,” Conferences in Research and Practice in Information Technology Series, vol. 34, pp. 143-151, 2003.

[14]

J. E. Bardram, “The Java Context Awareness Framework (JCAF) – A Service Infrastructure and Programming Framework for Context-Aware Applications,” in PERVASIVE 2005, 2005.

[15]

O. Davidyuk, J. Riekki, V.-M. Rautio, and J. Sun, “Contextaware middleware for mobile multimedia applications,” in Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia - MUM ’04, 2004, pp. 213-220.

[16]

R. P. Pinto, E. Cardozo, P. R. S. L. Coelho, and E. G. Guimarães, “A domain-independent middleware framework for contextaware applications,” Proceedings of the 6th international workshop on Adaptive and reflective middleware held at the ACM/IFIP/USENIX International Middleware Conference - ARM ’07, pp. 1-6, 2007.

[1]

M. Weiser, “The computer for the 21st Century,” IEEE Pervasive Computing, vol. 99, no. 1, pp. 19-25, Jan. 1991.

[2]

D. A. Norman, The invisible computer. Cambridge, Massachusetts, USA: MIT PRESS, 1998.

[17]

[3]

C. Pettey and H. Stevens, “Gartner Says Context-Aware Computing Will Provide Significant Competitive Advantage,” Gartner Press Releases, 2010. [Online]. Available: http://www.gartner.com/it/page.jsp?id=1190313. [Accessed: 12Jan-2012].

L. O. Bonino da Silva Santos, R. P. van Wijnen, and P. Vink, “A service-oriented middleware for context-aware applications,” in Proceedings of the 5th international workshop on Middleware for pervasive and ad-hoc computing held at the ACM/IFIP/USENIX 8th International Middleware Conference - MPAC ’07, 2007.

[18]

R. Löwe and P. Mandl, “Mobile, kontextbasierte Informationsbewertung und -versorgung am Beispiel von MEC +,” PIK Praxis der Informationsverarbeitung und Kommunikation, vol. 34, pp. 3-10, 2011.

[19]

H. Lieberman and T. Selker, “Out of context: Computer systems that adapt to, and learn from, context,” IBM Systems Journal, vol. 39, no. 3-4, pp. 617-632, 2000.

[20]

M. Appeltauer, R. Hirschfeld, M. Haupt, J. Lincke, and M. Perscheid, “A comparison of context-oriented programming languages,” in International Workshop on Context-Oriented Programming - COP ’09, 2009, pp. 1-6.

[21]

A. A. Economides, “Adaptive context-aware pervasive and ubiquitous learning,” International Journal of Technology Enhanced Learning, vol. 1, no. 3, p. 169, 2009.

[22]

P. Nurmi and P. Floréen, “Reasoning in context-aware systems,” University of Helsinki - Department of Computer Science, Helsinki, 2004.

[23]

T.-H. Teng and A.-H. Tan, “Cognitive Agents Integrating Rules and Reinforcement Learning for Context-Aware Decision Support,” 2008 IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology, Dec. 2008.

[4]

A. K. Dey and G. D. Abowd, “Towards a better understanding of context and context-awareness,” in CHI 2000 workshop on the what, who, where, when, and how of context-awareness, 2000.

[5]

B. N. Schilit, N. Adams, and R. Want, “Context-aware computing applications,” in Workshop on Mobile Computing Systems and Applications, 1994, pp. 85-90.

[6]

J. Pascoe, “Adding generic contextual capabilities to wearable computers,” in Digest of Papers. Second International Symposium on Wearable Computers (Cat. No.98EX215), 1998, vol. 44, no. 0, pp. 92-99.

[7]

A. Schmidt, M. Beigl, and H.-W. Gellersen, “There is more to context than location,” Computers & Graphics, vol. 23, no. 6, pp. 893-901, Dec. 1999.

[8]

N. Malik and U. Mahmud, “Future challenges in context-aware computing,” Proceedings of the IADIS, pp. 306-310, 2007.

[9]

T. Strang and C. Linnhoff-popien, “A Context Modeling Survey,” in Proceedings of UbiComp: 1st International Workshop on Advanced Context Modelling, Reasoning and Management, 2004.