Expert Systems with Applications 39 (2012) 9686–9694

Contents lists available at SciVerse ScienceDirect

Expert Systems with Applications

journal homepage: www.elsevier .com/locate /eswa

Extensible architecture for context-aware mobile web applications

Jordán Pascual Espada ⇑, Rubén González Crespo, Oscar Sanjuán Martínez, B. Cristina Pelayo G-Bustelo,Juan Manuel Cueva LovelleDepartment of Computer Science, University of Oviedo, c/Calvo Sotelo s/n, 33007 Oviedo, Asturias, Spain

a r t i c l e i n f o a b s t r a c t

Keywords:Web browserContext informationWeb servicesMobile devices

0957-4174/$ - see front matter � 2012 Elsevier Ltd. Adoi:10.1016/j.eswa.2012.02.151

⇑ Corresponding author.E-mail address: jordansoy@gmail.com (J.P. Espada

Over the years web browsers have gone from being used only on personal computers to a wide range ofdevices such as music players, video game consoles and mobile phones. Today people commonly usenative applications and web applications on their mobile phones. There are many technical differencesbetween native applications and web applications. One of these differences is that native applicationscan use the device hardware components that capture and manage context information, such as GPS, sen-sors, camera, etc. The differences between mobile phones require that in most cases it is necessary todevelop a native application for each specific platform (iOS, Android, WebOS, Windows Phone, Symbian,etc), which is really expensive, so many developers and companies choose to develop web applicationsthat can be used on any device with a web browser. The use of context information has proved very use-ful in many native applications, but web applications cannot use this type of information. This paperdescribes a proposal that allows web applications to access context information in a simple and fast.The proposed system consists of a modular web browser context aware and a set of specific XML tags thatcan be used on web applications.

� 2012 Elsevier Ltd. All rights reserved.

1. Introduction

Throughout recent history the web had a huge acceptance. Atfirst web browsers were only used on personal computers. Nowa-days good acceptance and growth of the web have meant thatmany electronic devices including web browsers, such as videogame consoles, TV, music players, and mobile phones.

Mobile phones (smart phones) are positioned as one of the mostpopular devices for access to online applications and web applica-tions. A significant percentage of accesses to web sites are madefrom mobile phones, nearly six billion mobile phones are con-nected to the internet worldwide, with a fast growing trend in re-cent years (ITU, 2011). Several factors have been increased thistrend, the low cost of mobile devices, high-speed wireless net-works, and ‘‘unlimited-data’’ pricing plans and so on.

Commonly mobile phones run native applications. These appli-cations are specially designed for the device or a group of specificdevices. Currently there are a big variety of mobile phone modelswith different specifications: screen size, memory, processingcapacity and operating systems (iOS, Android, WebOS, WindowsPhone, Symbian, etc.). This heterogeneity between mobile devicescauses the development of a valid application for different plat-forms are very expensive for developers; it requires deploying to

ll rights reserved.

).

multiple programming languages and using the APIs and platform-specific technologies. There are several frameworks that providetechnologies to develop mobile applications that can be exported todifferent platforms and can run on several different types of devices(PhoneGap, 2011).

To reduce the overhead caused by having to develop and main-tain the same application on different mobile platforms, manydevelopers have decided to develop web applications rather thannative applications. This measure not only save development costsalso ensure that their applications can be used by as many users aspossible since most of the mobile phones of today include a webbrowser (Hernandez, 2009).

Web applications and native applications are very differenttechnically. Native applications running over the device’s operat-ing system, web applications run over an external server that sendsvarious types of files (HTML, scripting languages, CSS, etc.) to themobile web browser, so that it can interpret. Depending on theobjectives and functionality of the application can be developedas a web application, native or either. There are some limitations,native applications have several features that are difficult to ‘‘imi-tate’’ by web applications, such as complex 3D graphics, the man-agement of device hardware components such as sensors, GPS,camera, and so on (Gossweiler, McDonough, Lin, & Want, 2011).

There are various definitions about what is the ‘‘context infor-mation’’ (Schmidt, 1999). We usually refer to the context informa-tion to information about the real world captured by electronic

J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694 9687

devices, such as location, the light level, the device orientation,temperature, etc. This information is usually obtained by a groupof sensors and others hardware elements.

Mobile phones are very conducive to the collection of contextinformation; these devices include various types of sensors, micro-phones, cameras, etc. The number of mobile applications that usecontext information has grown considerably in recent years. Todaythere are many applications that use real-world information tocomplete its functionality (Kim, Lee, Oh, & Choi, 2009; Lahtiet al., 2006) such as: the GPS for location, the camera to read barcodes, the speakers to capture voice commands, position sensorsto interact with the interfaces, and so on. The context informationcan be a key aspect of how people interact with electronic devices,the integration of physical and digital world can develop applica-tions that were previously difficult or not possible (Chua, Balkunje,& Dion Hoe-Lian, 2011).

The ability to capture the context information is one of theweaknesses of web applications compared to native mobile appli-cations. The traditional mobile web browsers (Chrome, Opera Mini,Firefox, Safari, etc.) do not have any mechanism that allows webapplication using the device sensors to capture context informa-tion and send this information to the web server. The introductionof the context information in web applications provides new pos-sibilities for development, giving the possibility to implementsome features that were previously exclusive to native applications(Gossweiler et al., 2011).

There are several proposals that introduce the use of some typesof context information in web browsers and web applications(Coppola et al., 2010; Noltes, 2008). Many of these proposals focusonly on few types of context information, such as location; thelocation is perhaps one of the context information types most use-ful, but certainly not the only one (Schmidt, 1999). Another featurecommon to most proposals is the use of context information in theuser background, the web browser and the web application ex-change context information without the user perceives it, this ap-proach is commonly used to provide context-sensitive content orservices, recommendation systems, etc.

This proposal raises a system for web applications can accessthe greatest number of context information types, according tothe technical possibilities of the device (GPS, camera, sensors,etc.). This approach is based on the context information shouldbe managed by the application user, in this proposal, sending con-text information to a web application is conceptually similar to thesending of any other information on the web; text in an input form,upload a file, select an option in a checkbox, etc. This approachaims to provide a simple system for the context information canbe used by the business logic process of the web application, notonly as an element of personalization services and contentconsumption.

This proposal would consist of two elements:

� A group of XML tags that any web applications can use in pre-sentation layer to request the user context information.� Context aware web browser architecture, designed to use

device sensors to capture context information and to send thatinformation to the web application.

The structure of the paper is as follows. Section 2 presents andanalyzes some proposals that establish a relationship between webbrowsers and the context information. Section 3 provides adescription of the proposed architecture. Section 4 present a proto-type of a web application developed using the proposal. Section 5presents and analyzes the results obtained from testing the webapplication developed using the proposal. Finally Sections 6 And7 presents the conclusions and future work.

2. Related works

2.1. Context aware applications

More than 15 years ago, the advantages of using context infor-mation in software applications began to be visible (Schilit &Theimer, 1994). From then until today, there were many proposalsthat included the use of context information in the computer area.Many proposals are specific applications or systems that use in anyway some type of context information. These proposals usuallyadapt the management of context information to specific scenar-ios, such as social networks IYOUIT (Boehm et al., 2008) CenceMe(Miluzzo et al., 2008) and tourism (Lamsfus, Alzua-Sorzabal,Martin, & Lopez de Ipiña, 2010).

Other proposals are aimed at developing applications that usecontext information. Most of these proposals are mainly frame-works or architectures that support the development of context-aware native applications (Biegel & Cahill, 2004; Johnson, 2007;Raento, Oulasvirta, Petit, & Toivonen, 2005). Some proposed frame-works combine the management of context information with rea-soning elements (De & Moessner, 2009). In most cases the nativeapplications are developed in different types of mobile computingdevices (PDAs, smart phones, etc.). These devices have adequatetechnical features to capture context information (Chua et al.,2011).

Some frameworks provide supports to simplify the develop-ment tasks and some aspects of application functionality. Forexample the Context Toolkit (Dey, Abowd, & Salber, 2001) offersone solution for supporting context-aware application prototyping.Its design separates context acquisition from use and supports con-text interpretation, distributed communication, constant contextavailability, context storage, and resource discovery. Several ofthese proposed frameworks include interesting features like rapiddevelopment and reusability. Most of the proposals are useful fordeveloping context aware native applications, but these frame-works have not been conceived specifically for developing webapplications based on existing web technologies.

2.2. Context aware web applications and context-aware web browsers

Some authors propose to include the use of different types ofcontext information in web applications, some of these proposalsmodify the traditional web browsers to make it context-aware(Challiol, Fortier, Gordillo, & Rossi, 2007), other proposals are basedon the use of additional applications or plugins to complete theprocess of managing the context information (Noltes, 2008). Inte-gration with the context information is useful not only inweb applications, also in other web technologies such as webservices (Ennai & Bose, 2008), sometimes the context-aware webservices can be used to build web applications (Kapitsaki, Kateros,& Venieris, 2008).

SENSE-SATION system (Shirazi, Winkler, & Schmidt, 2010),which facilitates the development of web applications based on acommunity of mobile phones. The system consists of a runtimeenvironment that is installed on the phone and a web based appli-cation platform. It is an extensible platform for integration thatprovides means to collect and manage information available onphones and makes it accessible. Context aware web browser(Coppola et al., 2010) use the information provided by the sur-rounding environment in order to carry out a more refined searchof web contents.

A different approach to exchange context information with webapplications is the use of specific protocols. These protocols allowthe management of few types of context information, mainly the

Fig. 1. (1) The context-aware web browser makes a request to a web server. (2) Theweb server responds a html page that contains context information XML tags. (3)The context-aware web browser processes the page and executes the correspond-ing context tasks. (4) The context task result is sent to the server using a webservice.

9688 J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694

location. Several protocols have been specifically designed to pro-mote the exchange of context information between web applica-tions and web browsers. Some of these protocols are: SecureUser Plane location (Goze, Bayrak, Barut, and Sunay, 2008), MobileLocation Protocol (Mobile, 2002), Presence Information Data For-mat (Sugano et al., 2004) and HTTP Enabled Location Delivery(Barnes, 2008).

Web-Centric Application platforms are related in some respectswith context-aware web applications (Gossweiler et al., 2011).These platforms have expanded since the advent of HTML5 (Hick-son, 2011) and WebKit (WebKit, 2011), like PhoneGap (PhoneGap,2011) that allows developing applications using web technologiesand specific libraries that access the device hardware API that canbe used to capture context information. Applications developedwith this platform are exported to various mobile systems: iOS,Android, WebOS, Windows Phone, and Symbian.

Most of the analyzed systems that supported the development ofcontext-aware web applications are very useful for developingapplications in specific scenarios, such as context-sensitive searches,recommendation systems, social networks, tourism, etc. But thesesystems are not designed to provide normalized and simple mecha-nisms that allow web applications to request any type of contextinformation that can be captured by the device.

Many of the proposed systems only manage a small set of con-text information types, such as location. To promote the integrationof context information and the independence of web applicationsthat use it, the use of context information should not be condi-tioned by specific libraries, components, or web technologies.

3. Proposed system

3.1. Considerations and design decisions

The proposal must allow web applications to use any type ofcontext information that the device is able to capture. The userhas to approve the communication context of context informationto the application.

The architecture of context-aware web browser must be inde-pendent to be able to be applied to any platform (iOS, Android,WebOS, Windows Phone, and Symbian, etc.). The implementationof some architecture elements that has access to the hardware APIswill have to be partially dependent on the platform.

Context information types that devices can capture may in-crease in the near future; the proposal must have a structure thatallows adding support for new context information types.

Web applications that want to introduce the user context infor-mation should be able to include the appropriate mechanisms in anormalized and easily, without having to use a particular webtechnology or include libraries and specific components.

The management of the context information must be controlledby the user, in the same way that the user controls the other infor-mation entered on the web, such as enter text into a input form, se-lect an option in a combo box, upload a file, etc.

3.2. Model

On the one hand, the proposal defines an open group of contextinformation XML tags that define the context information required.These tags can be included in the presentation layer of webapplications.

On the other hand is the context-aware web browser is respon-sible for processing the context information XML tags and notifiesthe user that requires a specific type of context information. If theuser gives permission to send the context information the browserruns the context information scheduled task linked to the active

context information XML tag, this task captures the context infor-mation, processes it and sends it to the web application (Fig. 1).

3.3. Web applications: context information XML tags

The XML tags are included in the presentation layer of the webapplication, for example in the HTML code. The use of these tags isfully compatible with traditional web browsers that do not imple-ment this specification, that web browsers simply ignore the un-known tags. Each XML tag notifies the context-aware webbrowser to request a specific type of context information. Some-times a context information type can be captured in different ways,so some XML tags define several optional attributes that customizethe behavior of the task that captures and sends the context infor-mation requested.

This proposal defines an open group of XML tags that corre-spond to many of the different types of context information thatcurrent mobile devices can capture. This group is open becausethe number of XML tags can grow in the future. Not all mobile de-vices can provide support for all defined XML tags. Therefore, notall XML tags are compatible with all devices; the context-awareweb browser is responsible for communicating to the user if thereis any incompatibility with the context information XML tagprocessed.

Some of the context information XML tags are defined asfollows:

Sensors:

� <lightSensor/> gets the device light sensor value.� <compass/> get the current value of the compass.� <orientation/> get the device orientation, expressed in coordi-

nates x, y and z.� <location/> get the device current location. By default this tag

request the current position once, but supports an optionalattribute (timeInterval=<int>Seconds) to define the frequency ofsending the device’s position. Another optional attribute is thesource from which it obtains the location: GPS or Wi-Fi.� <audioCapture/> activate the device microphone to capture the

audio. By default, the audio recording ends when the userpresses the button again. This XML tag may contain optionalattributes to specify the recording time and the audio fileformat.� <camera/> take a photo using the camera. This tag can option-

ally contain an attribute to specify the quality of the image.

When the web application user press a button corresponding toa context information XML tag, the browser sends context informa-

Fig. 2. Diagram of the context-aware web browser architecture. The context-awareweb browser is composed by tree layers, (1) standard web browser, (2) context tagmanager and (3) the context information scheduled task manager.

J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694 9689

tion to the web application, this information is usually plain text ora file. The sending of the context information is done using RESTful(Fielding, 2000; Yong & Connelly, 2008) web services, so the webapplication must implement a web service (or page that receivesa POST request) to receive the context information requested.

All context information XML tags have an associated defaultweb service URL, for example <location/> with baseUrl/location,but the default web service URL can be changed using the attri-bute receiver=’’url’’. Context information xml tags can be com-bined with several attributes to obtain the required functionality;here are some examples of these combinations.

<location/>

<!-- Get location with default parameters--><location method=‘‘Wifi’’

receiver= ‘‘domain/saveLocation.php’’ />

<!-- Get Wifi location and direct the response to

‘domain/saveLocation.php’--><location timeInterval= ‘‘60’’

id=‘‘location1’’ />

<!-- Get location every 60s with Id=location1--><camera/>

<!-- Get camera picture with default parameters--><camera id=‘‘camera1’’

quality=‘‘medium’’/>

<!-- Get camera picture with medium quality and

Id=camera1--><camera receiver=‘‘domain/servletPicture’’/>

<!-- Get camera picture and direct the response to

‘domain/servletPicture’--><orientation timeInterval=‘‘60’’ />

<!-- Get device orientation every 60s-->

When a web application includes more than one tag of the sametype may include the optional attribute Id=String, used to identifywhich specific XML tag corresponds the information that the webservice receives.

The application includes context information XML tags to re-quest context information, to receive this information implement-ing RESTful web services or a page that receives a POST request.

3.4. Context aware web browser

The context aware web browser functions are:

� Interpret the web pages based on web standards and conven-tional languages. In the same way as other classic webbrowsers.� Notify user requests for context information, if a website con-

tains a context information XML tag the browser should displaya specific button that lets the user decide whether to send thatcontext information. The buttons associated with context infor-mation XML tags must also indicate the status of the request;not available, ready, processing, completed and error.� When the user gives permission to share the context informa-

tion, the web browser must run the corresponding contextinformation scheduled task. These tasks are independent codemodules contained in the context-aware web browser that cap-ture context information using the operating system device API.Depending on the context information XML tag the captureddata can be processed before being sent to the application.The information that the context-aware web browser sends tothe web application is completed by the headers: session deviceand context information XML tag Id.

The architecture of proposed context aware web browser iscomposed of three layers (Fig. 2) (1) standard web browser, (2)context tag manager and (3) the context information scheduledtask manager.

Standard web browser. The objective of the first layer is tointerpret and visualize the web standards code. This layer hasthe same functionality as a conventional mobile web browser, suchas: Dolphin HD, Opera Mini, Mozilla Fennec, and Safari.

Context tag manager. The second layer is responsible for themanagement of context information XML tags. First, the browserparses the web response looking for XML tags that correspond tothe context information XML tags that the device can process. Ifthe device has technical resources to capture the context informa-tion the context-aware web browser adds a new button in a graph-ical layer above the HTML. Each context information XML tag isrepresented by button that has a different icon depending on itscategory or function. All mobile devices do not include the samesensors; some buttons may be disabled if the device does not in-clude the necessary hardware to capture the context informationdefined in the context information XML tag.

The structure of this layer has been designed so that the numberof context information XML tags to increase. The context-awareweb browser contains a group of context information XML tags,attributes that can be associated with each tag and the id of theassociated context information scheduled task.

Context information scheduled task manager. This layer con-tains and manages the context information scheduled tasks. Gen-erally this task capture context information using sensors or

Fig. 3. Context information task state diagram. All context information task havethe same states independently of its functionality.

Fig. 4. Conceptual diagram of the association between context information XMLtags and context information scheduled tasks.

Fig. 5. Photo upload form. Buttons notify the user request for context information.

9690 J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694

other hardware element, depending on the task. The informationobtained is encapsulated in a POST request and send it to the de-fault RESTfull web service URL or the URL defined (using the ‘‘recei-ver’’ attribute). The POST request header contains two parameters:the session identifier of the device (DSK) and the identifier of theXML tag, only if the tag includes the ‘‘Id’’ attribute (ID).

The context information scheduled tasks have four commonstates: (1) ready, (2) processing, (3) completed and (4) error (Fig. 3).When tasks change their state they will notify to context tag man-ager layer.

The task receives as input parameters the context informationXML tag attributes. The attributes define important properties ofthe task behavior (Fig. 4). Depending on the attributes values, thetask may be finish automatically after sending the context infor-mation to the web application, unless it has been defined as loopusing the ‘‘timeInterval’’ attribute, in this case the task will be run-ning until the user decides to finish it or close the web application.

4. Prototype: web application photo gallery

This section details a web application that uses context infor-mation XML tags. This proposal allows developing web applica-tions with features that would be very difficult to imitate usingclassic web technologies. There are many different web applica-tions that could be developed to illustrate the use of this proposal.As a prototype application, we decided to implement a simplephoto gallery, where users can upload and view pictures. To uploada new picture the user must send the picture file, the current loca-tion and an identifying name for the image. The functionality ofthis application could be developed in a similar way without usingthis proposal. The main reason for selecting this prototype is to

compare objectively an application developed using the proposalwith another application that has the same functionality and hasbeen developed using common web technologies.

The web application included on page index.php two contextinformation XML tags. The first tag request the location of the de-vice, the second tag requested a camera picture, in both cases usedthe simplest versions of these tags, ie not including any configura-tion attribute.

The <camera/> tag requires to take a picture with the devicethat will be sent to the default web service, since no other web ser-vice URL is specified using ‘‘receiver’’ attribute. The <location/> tagrequires to send once the device position to default web serviceURL. Context information XML tags are included in the HTML syn-tax in the same way as other tags. Below is the snippet of code thatdefines the data entry form:

<div id=’’stylized’’ class=’’myform’’>

<form id=’’form’’ name=’’form’’

method=’’post’’ action=’’insert.php’’>

<h2>HTML form + XML Context Tags</h2>

<p>

Please take a photo and send

it with your current location.

</p>

<label>Name:</label>

<input type=’’text’’

name=’’name’’ id=’’name’’ />

<label>Location:</label>

<location/>

<label>File:</label>

<camera/>

<button type=’’submit’’>Send</button>

</form>

</div>

To interpret this context-aware web application we have devel-oped a context-aware web browser by following the proposedspecification, the context-aware web browser has been developedon the Android platform and contains the implementation of sev-eral context information scheduler tasks, including those associ-ated with the <camera/> and <location/> context informationXML tags.

The context-aware web browser represents the context infor-mation XML tags as buttons (Fig. 5). These tags will not be visible

Fig. 6. Photo upload form. Location button indicates that the task has beencompleted successfully.

Fig. 7. Web services use the DSK header to identify the request.

Fig. 8. Photo upload form. Location and Camera button indicate that the task havebeen completed successfully.

Fig. 9. The page shows the name of the picture, the picture and the current location.

J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694 9691

in a common web browser. When the user clicks on a button thebrowser will start executing the associated context informationscheduler task.

When the user click on the location button, the phone uses theGPS to get the current location, and then sends the coordinatesencapsulated in a POST request to the default web service base-URL/location. After sending the coordinates of the location but-ton status changed to ‘‘completed’’. The button style changes tonotify that the task has been completed successfully (Fig. 6).

The web application will have to implement the ‘‘location’’ webservice, in this prototype we have implemented a PHP service thatgets the GPS coordinates sent in the in the POST request and storedin a database. The DSK header can be used for similar purposes tothe session ID, in one session the device will always have the sameDSK (Fig. 7).

By clicking on the camera button, the browser runs the associ-ated task; opens the camera view. This task requires the user inter-action, when the user takes a picture the web browser will displaythe web application again. The picture was sent in a POST requestto the default web service baseURL/camera. We have implementedthis service on the web application using PHP, the service store thereceived file. As in the case of the location, use the DSK parameterto identify the device and the session.

While the photo is being sent to the web service, the buttonchanges its state to ‘‘processing’’, this state shall be common inthose some tasks that take a long time, in this case if the picture

is large it may take several seconds. The buttons will show the‘‘processing’’ state while the task is not complete. When the pictureis sent, the button icon changes to indicate that task has been com-pleted successfully (Fig. 8).

Once all context information has been sent to the web applica-tion, the user can press the button to send the form with the pic-ture name. By submitting the form the web application redirectsto ‘‘insert.php’’ page, this page shows the information that hadbeen previously submitted using context information XML tagsand the standard HTML form (Fig. 9).

5. Prototype evaluation

This section presents a performance evaluation of web applica-tion developing using context information XML tags. The applica-tion will be evaluated has been developed in the previoussection, a photo gallery where users can upload geolocated photos.The web application has been built using context tags will be com-pared with two other applications with the same functionality andhave been developed using common web technologies.

Fig. 10. (1) The web application that only use HTML. (2) The web application thatincludes context information XML tags.

Fig. 11. Graphic representation of system memory usage during the execution ofevaluated applications.

Fig. 12. Graphic representation of CPU usage during the execution of evaluatedapplications.

Fig. 13. Graphic representation of network traffic received during the execution ofevaluated applications.

9692 J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694

The three applications that have been used in the simulationsare:

1. HTML: A simple application that uses a standard HTML form.The user enters text in a component name, text field in anotherlocation coordinates and select a picture file.

2. Context Information XML Tags: This application has the samefunctionality as described above; the difference is that it usescontext information XML tags instead of input elements in theHTML form. The context information XML tags will be used tocollect and send the location coordinates and image file (Fig. 10).

3. HTML and GMAPs: This application is based on the first, with adifference, uses the Google Maps API for the user to select theirlocation on the map. When the user opens the map to select thecurrent location the map is centered very close to the currentlocation, this action prevents the user to navigate around themap too and increase network traffic.

Devices used for testing have been a HTC Aria Smartphoneswith the following features: Processor 600 MHz 384 MB RAM,512 MB ROM, WiFi, Android OS 2.3. For obtaining performanceparameters in the simulations have been used three analysis tools:Traffic Monitor, Advance Task Manager, and TrafficStarts App/TaskManager.

These web applications receives picture files, to eliminate thepicture file size variable factor we plugged the device camera, thus

the pictures are all black and the file always has the same size, thepicture attached in the form (applications 1 and 3) is also com-pletely black. The simulation process has involved the followingsteps: the user enters a name for the picture, set a location and at-taches a picture file. This process was done with each of the threeapplications 25 times.

In the simulations measurements were obtained importantparameters for the Smartphones performance: system memoryusage (Fig. 11), CPU usage (Fig. 12), network traffic; receiver data(Figs. 13 and 14) send data (Fig. 15).

The device performance expressed in memory usage and CPUseconds, gives similar values in applications (1) and (2), but in allcases the application (2) that uses context information XML tagsobtained slightly better values. This difference may be becausethe commercial web browser is somewhat more complex thanthe context-aware web browser. The android web browser hassome more features; favorites, personalization, etc.

The result set obtained show that the network traffic between abasic HTML and web application that uses context informationXML tags are very similar, obtaining in all cases slightly better val-ues in the application (2) that uses context information XML tags.As expected the application that use GMAPs record much morenetwork traffic than the other two applications.

Comparing the result obtained in the simulations, we can con-clude that the in the scenario evaluated web applications thatuse XML tags are as efficient as traditional web applications.

The use of context information in web applications can improvethe user experience in many scenarios. In general, mobile devices

Fig. 14. Graphic representation of network traffic received data during the executionof (1) HTML and (2) ContextTag applications.

Fig. 15. Graphic representation of network traffic sent during the execution ofevaluated applications.

J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694 9693

have several limitations in their interfaces: digital keyboard, smallscreens, needs to scroll to center the view on the page elements,etc. All the information can be sent to the web application simplywithout forcing the user to interact with the device interface is astep towards improving the user experience. The functionality ofthe application developed in Section 6 may also have implementedwithout the use of this proposal, but context information XML tagssignificantly reduce the number of user interactions with the de-vice’s interface. Therefore the application can be handled morequickly, decreasing the chances that the user causes errors andincreasing the usability.

6. Conclusions

We have proposed a system that allows web applications to re-quest many types of context information.

This proposal includes a normalized and extensible mechanismfor current applications can use most of the context informationthat the devices are capable of capturing. This proposal is aimedprimarily mobile phones devices, but can be applied to other de-vices such as personal computers, and embedded systems.

The system has been designed to future modifications and exten-sions, including new types of context information XML tags whichwill allow web applications to request other context informationtypes. To extend the system is only necessary to define a newcontext information XML tag and develop the associated contextinformation scheduler task.

One of the most important objectives that have been taken intoaccount when raising this system is that the mechanism to requestcontext information could be easily integrated into web applica-tions already developed, without altering the application structureor conditioning their development using specific technologies, li-braries, plugins or other components.

The system gives the user control over their context informa-tion. In this proposal, sending context information to a webapplication is conceptually similar to the sending of any otherinformation on a website; text in an input form, upload a file, selectan option in a checkbox, etc. When an application requests contextinformation the user must decide whether to accept the request.

The use of context information XML tags can be combined withtraditional controls such as HTML forms, allowing the user tochoose between using context-aware controls or traditional con-trols. Users who are using a context aware web browser can seethe context-sensitive controls. A traditional web browser ignoresthe context information XML tags, but users can use the applica-tion with alternative HTML controls.

This proposal has some aspects that could improve. The devel-opment of web applications can be complicated if they use manytypes of context information, as it will be necessary to implementa web service for collecting each of the context information types.In general the implementation of these web services should not bevery expensive for the developer but it depends largely on the pro-gramming language being used to develop the web application.

7. Future work

Future investigation is divided into the following areas:

� Development tools for the automatic creation of web ser-vices responsible for receiving context information.� Integration of mobile augmented reality (Feiner, 1995; Feiner,

MacIntyre, Hollerer, & Webster, 1997) techniques in web appli-cations. Researching new context information scheduler taskthat use the captured context information to create augmentedreality environments.� Optimize the user experience.� Designing new context information XML tags and context infor-

mation scheduler tasks that use other types of contextinformation.� The proposal uses POST request to communicate context infor-

mation to the web applications in the future will investigateother synchronization and communication mechanisms.� Provide web applications access to hardware communication

elements, such as: wireless, bluetooth, etc. To ensure that webapplications can be synchronized with physical electronicdevices. Thus, web applications could communicate with smartobjects (Kortuem, Kawsar, Fitton, & Sundramoorthy, 2010), orother internet of things systems.

References

Barnes, M. (2008). HTTP enabled location delivery (HELD). <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08/>.

Biegel, G., & Cahill, V. (2004). A framework for developing mobile, context-awareapplications. In Paper presented at the proceedings of the second IEEE annualconference on pervasive computing and communications, PerCom 2004.

9694 J.P. Espada et al. / Expert Systems with Applications 39 (2012) 9686–9694

Boehm, S., Koolwaaij, J., Luther, M., Souville, B., Wagner, M., & Wibbels, M. (2008).Introducing IYOUIT. In A. Sheth, S. Staab, M. Dean, M. Paolucci, D. Maynard, T.Finin, et al. (Eds.), The Semantic Web – ISWC 2008 (Vol. 5318, pp. 804–817).Berlin/Heidelberg: Springer.

Challiol, C., Fortier, A., Gordillo, S., & Rossi, G. (2007). A flexible architecture forcontext-aware physical hypermedia. In Paper presented at the 18th internationalworkshop on database and expert systems applications, DEXA ‘07. .

Chua, A. Y. K., Balkunje, R. S., & Dion Hoe-Lian, G. (2011). The influence of user-context on mobile information needs. In Paper presented at the IEEE workshops ofinternational conference on advanced information networking and applications(WAINA).

Coppola, P., Della Mea, V., Di Gaspero, L., Menegon, D., Mischis, D., Mizzaro, S., et al.(2010). The context-aware browser. Intelligent Systems, IEEE, 25(1), 38–47.

De, S., & Moessner, K. (2009). A framework for mobile, context-aware applications.In Paper presented at the international conference on ICT ‘09 telecommunications,. .

Dey, A. K., Abowd, G. D., & Salber, D. (2001). A conceptual framework and a toolkitfor supporting the rapid prototyping of context-aware applications. Human–Computer Interaction, 16(2), 97–166.

Ennai, A., & Bose, S. (2008). MobileSOA: A service oriented web 2.0 framework forcontext-aware, lightweight and flexible mobile applications. In Paper presentedat the enterprise distributed object computing conference workshops.

Feiner, S. (1995). KARMA. <http://www.cs.colum-bia.edu/graphics/projects/karma/>.Feiner, S., MacIntyre, B., Hollerer, T., & Webster, A. (1997). A touring machine:

Prototyping 3D mobile augmented reality systems for exploring the urbanenvironment. In Paper presented at first international symposium on the wearablecomputers. Digest of papers. .

Gossweiler, R., McDonough, C., Lin, J., & Want, R. (2011). Argos: Building a web-centric application platform on top of android. Pervasive Computing, IEEE, 10(4),10–14.

Goze, T., Bayrak, O., Barut, M., & Sunay, M. O. (2008). Secure user-plane location(SUPL) architecture for assisted GPS (A-GPS). In Paper presented at the advancedsatellite mobile systems, ASMS 2008, 4th.

Hernandez, E. A. (2009). War of the mobile browsers. Pervasive Computing, IEEE,8(1), 82–85.

Hickson, I. (2011). HTML 5 W3C working draft. <http://www.w3.org/TR/html5/>.ITU (2011). The world in 2011 ITC Facts and figures. <http://www.itu.int/ITU-D/ict/

facts/2011/material/ICTFactsFigures 2011.pdf/>.Johnson, S. (2007). A framework for mobile context-aware applications. BT

Technology Journal, 25(2), 106–111.Kapitsaki, G. M., Kateros, D. A., & Venieris, I. S. (2008). Architecture for provision of

context-aware web applications based on web services. In Paper presented atIEEE 19th international symposium on the personal, indoor and mobile radiocommunications, PIMRC 2008.

Kim, N., Lee, H. S., Oh, K. J., & Choi, J. Y. (2009). Context-aware mobile service forrouting the fastest subway path. Expert Systems with Applications, 36(2, Part 2),3319–3326.

Kortuem, G., Kawsar, F., Fitton, D., & Sundramoorthy, V. (2010). Smart objects asbuilding blocks for the Internet of things. Internet Computing, IEEE, 14(1), 44–51.

Yong, L., & Connelly, K. (2008). Realizing an open ubiquitous environment in aRESTful way. In Paper presented at IEEE international conference on ICWS ’08 theweb Services. .

Lahti, J., Palola, M., Korva, J., Westermann, U., Pentikousis, K., & Pietarila, P. (2006). Amobile phone-based context-aware video management application. In R.Creutzburg, J.H. Takala, C.W. Chen (Eds.), Paper presented at the proceedings ofthe SPIE on multimedia on mobile devices II. (Vol. 6074, pp. 204–215).

Lamsfus, C., Alzua-Sorzabal, A., Martin, D., & Lopez de Ipiña, D. (2010). Digitalbroadcasting for context-aware services in tourism. In Paper presented at secondIEEE region 8 conference on the history of the telecommunications conference(HISTELCON).

Miluzzo, E., Lane, N. D., Fodor, K., Peterson, R., Lu, H., Musolesi, M., et al. (2008).Sensing meets mobile social networks: The design, implementation andevaluation of the CenceMe application. In Paper presented at the proceedings ofthe 6th ACM conference on embedded network sensor systems.

Mobile, (2002). Mobile location protocol specification. <http://www.openmobilealliance.org/tech/affiliates/lif/lifindex.html/>.

Noltes, J. (2008). An architecture for context-aware mobile web browsing 9thTSCONIT. University of Twente.

PhoneGap (2011). <http://phonegap.com/>.Fielding, R. (2000). Architectural styles and the design of network-based software

architectures. Dissertation for Doctor of Philosophy, University of CaliforniaIrvine, <http://www.ics.uci.edu/’fielding/pubs/dissertation/top.htm/>.

Raento, M., Oulasvirta, A., Petit, R., & Toivonen, H. (2005). ContextPhone: Aprototyping platform for context-aware mobile applications. PervasiveComputing, IEEE, 4(2), 51–59.

Schilit, B. N., & Theimer, M. M. (1994). Disseminating active map information tomobile hosts. Network, IEEE, 8(5), 22–32.

Schmidt, A. (1999). There is more to context than location. Computers & Graphics,23(6), 893–901.

Shirazi, A. S., Winkler, C., & Schmidt, A. (2010). SENSE-SATION: An extensibleplatform for integration of phones into the Web. Internet of Things IOT, 2010,1–8.

Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., & Peterson, J. (2004).Presence information data format (PIDF). Internet Engineering Task Force.

Webkit (2011) <http://www.webkit.org/>.