Custom Context Creation

In Listing B.1, it can be seen that the user’s NamedIndividual has a Sim-ple Context attribute, "InHome", set to false. This SimSim-ple Context was not built into CAMCS for this evaluation; it was implemented using the Defini-tion classes for developers. Behind the scenes, both the User LocaDefini-tion and User Activity contexts are built on with the Complex Context Definitions and Context Property Definition classes as well. These are constructed at start-up time within the Context Manager. To develop the "InHome" context, a sepa-rate project package and classes were created, rather than being built into the Context Manager. This package is scanned at start-up time, and has an ini-tialisation method that passes the Simple ContextD efinition for the "inHome"

context to the Context Manager, for insertion into the mapped collection of Context Defintions. The "InHome" context, being a SimpleContext, has one ContextProperty, called "Location", which is the Boolean true/false value seen in Listing B.1.

To go with this context, a custom Context Profile was created which is also added to the Profile Manager at start-up time, the "Home" profile (the in-built Home was removed profile for evaluation). The Home profile knows about the existence of the "InHome" context, and accesses it through the Context Man-ager. To determine the user’s home location, it looks at the historical location context for the previous week, between 12AM and 6AM, and uses the coor-dinates found for the majority of the location results returned (which should be the same if the user is at home in bed at these times, with the mobile de-vice left in the same place), and assumes this to be the home location coordi-nates. When a context location update is received from the CAMCS Client, the onUpdate() method of the profile is called, and it carries out this check

Figure 4.8: Twitter Traffic Task Result. Screenshot of traffic information pro-vided by Tweets for Cork City, Ireland, displayed on the CAMCS Client.

and compares with the coordinates received in the update, and sets the Con-textProperty value accordingly.

4.6.5 Discussion

The complexity and potential is in the ability to create services that the CPA can use with the gathered context. These services can be developed and de-ployed on clouds to work with existing web-based services exposed by ser-vice providers to complete work, or provide information, to the user, through their CPA. Such actions can occur as a result of a user requested task, or, as in the case of the tourist service, the CPA can undertake this work automatically without user intervention.

The use of web and cloud-based services is difficult, but there is great potential here when compared with other mobile cloud approaches. Existing services do not accept visits from the CPA, nor do they readily support the functionality.

Therefore, wrappers need to built around these existing services, for the pur-poses of contacting and utilising them. This is exactly what was done for the services created for the evaluation. They serve as wrappers for the developer to specify how the CPA should work with an existing cloud-based service. In

the past, this had to be carried out for any existing service. While it may seem like a disadvantage, it does allow the developer to implement custom func-tionality using the existing services, in the form of a mash-up. However, a more generic approach to working with mobile cloud services, without using wrappers, is the subject of Chapter 5.

The time commitment for developers required to create custom contexts and profiles is worthwhile, as this will deliver a high level of personalisation, bene-fitting the user experience aim of CAMCS. The development goal of providing the Context Definition and Context Property Definitions as demonstrated is to make this process as quick as possible, while developers still have the power to extend these classes as well for completely custom implementations. To gain relevant and useful functionality, the development of custom context profiles to go with custom contexts should be considered essential.

4.7 Conclusions

In this chapter, considerations for and the implementation of the Context Pro-cessor component of CAMCS was presented. This component will personalise the use of mobile cloud services with the context of the user, bridging the gap between them. As a result, service execution can vary with the user’s situation.

When a CPA wishes to complete a task for the user, it can query the Context Processor to get the context of the user, which may personalise the task execu-tion to his/her situaexecu-tion. This is aided by the use of Context Profiles, which can influence how the CPA operates with cloud services based on an active context profile and situation. It also allows the CPA to undertake work for the user without his/her intervention, based on the Context History, which is stored with the CPA.

Several requirements of the Context Processor were analysed to determine what kind of framework was required for context representation, under the areas of context representation, inference, and storage. An ontology-based ap-proach was chosen because of its storage capability, and the ability to use a reasoner for context inference. This is useful when the mobile device is discon-nected from the cloud and new context cannot be gathered. The architecture of the Context Processor, along with the structure of Context was presented, with Complex and Simple Contexts, as well as how current and historical context is

used within CAMCS. Mobile context is collected by the CAMCS Client, based on Google Play Services, and is sent to the CPA to be stored by the Context Processor. Experimental evaluation was also presented showing how collected context can be used by the CPA to work with mobile cloud services; two ex-perimental services were presented, a Tourism Places of Interest service (based on providing Location context to Foursquare), and a Twitter-based Traffic In-formation Service (using location and activity context data).

In the next chapter, a generic solution for CAMCS to discover and consume mobile cloud services for completing user tasks with CPAs is presented. A unique services description format is also presented, which features support for describing context data that can be used by a service during its execution.

The chapter also shows how context data can be used with service discovery.

This chapter was based on [99], with the following exceptions: Section 4.2, Section 4.5 which was heavily modified and extended, and Subsection 4.6.4.

Various modifications have been made to the text throughout the chapter, to fit with the flow of the thesis.