Using Vital Sensors in Mobile Healthcare Business Applications
Challenges, Examples, Lessons Learned
Johannes Schobel, Marc Schickler, R
udiger Pryss, Hans Nienhaus and Manfred Reichert
Institute of Databases and Information Systems, University of Ulm, James-Franck-Ring, Ulm, Germany
Sensor Framework, Android, Smart Mobile Device, Healthcare, Vital Signs, Mobile Business Application.
Today, sensors are increasingly used for data collection. In the medical domain, for example, vital signs (e.g.,
pulse or oxygen saturation) of patients can be measured with sensors and used for further processing. In this
paper, different types of applications will be discussed whether sensors might be used in the context of these
applications and their suitability for applying external sensors to them. Furthermore, a system architecture
for adding sensor technology to respective applications is presented. For this purpose, a real-world business
application scenario in the field of well-being and fitness is presented. In particular, we integrated two different
sensors in our fitness application. We report on the lessons learned from the implementation and use of this
application, e.g., in respect to connection and data structure. They mainly deal with problems relating to
the connection and communication between the smart mobile device and the external sensors, as well as the
selection of the appropriate type of application. Finally, a robust sensor framework, arising from this fitness
application is presented. This framework provides basic features for connecting sensors. Particularly, in the
medical domain, it is crucial to provide an easy to use toolset to relieve medical staff.
Today, mobile business applications, running on both
smartphones and tablet computers, become increas-
ingly important for the medical domain. This ranges
from schedule management applications to complex
process-oriented, mobile patient management sys-
tems (Pryss et al., 2010; Pryss et al., 2012). Since
these applications have evolved from administrative
(e.g., bed planning) to operational (e.g., measuring
blood pressure) tasks, it is necessary to support med-
ical staff in their daily routine. This can be supported
through the integration of external sensors, which are
not built in the smart mobile device, for monitoring
vital signs.
Due to heterogeneity of available external sensors,
it becomes necessary to classify these devices. This
can be done, for example, based on the type of vi-
tal signs a sensor can monitor (e.g., pulse or oxygen
saturation), or the type of connection (e.g., Bluetooth
or USB) the sensor supports. In addition to the di-
versity of mobile operating systems (e.g., Android or
iOS), various development aspects emerge that must
be addressed. This ranges from different types of
provided sensor data to the quality of gathered data
(e.g., real-time or bulk-load data). Furthermore, cop-
ing with connection problems (e.g., disconnections
between the participating devices) during mobile data
collection is challenging.
To evaluate these specific aspects, we present
our implemented mobile fitness application “XFitX-
treme” that communicates with external sensors.
Based on insights of this application, we want to cre-
ate a sensor framework, which allows for the provi-
sion of a variety of different vital signs to athletes or
patients using mobile applications with sensors.
The remainder of this paper is structured as fol-
lows: Section 2 discusses our application scenario. In
Section 3, basic concepts for developing a mobile fit-
ness application are introduced, and the designed sys-
tem architecture is presented. Section 4 discusses the
current status of our fitness application “XFitXtreme”
and presents particular issues emerging during the im-
plementation. Section 5 discusses related work, while
Section 6 gives a summary and a brief outlook for fur-
ther research questions.
To evaluate our approach of integrating sensors in mo-
bile business applications, we present a proper real-
Schobel J., Schickler M., Pryss R., Nienhaus H. and Reichert M..
Using Vital Sensors in Mobile Healthcare Business Applications - Challenges, Examples, Lessons Learned.
DOI: 10.5220/0004501205090518
In Proceedings of the 9th International Conference on Web Information Systems and Technologies (BA-2013), pages 509-518
ISBN: 978-989-8565-54-9
2013 SCITEPRESS (Science and Technology Publications, Lda.)
world scenario (cf. Section 2.1). For this purpose
we consider the fitness domain, in which we want to
use external sensors to support athletes in daily work-
out sessions. In particular, we want to show different
ways of developing such mobile business applications
integrating external sensors. These considerations are
the basis for the system architecture and sensor frame-
work in the further course of this paper.
2.1 Running Example
To evaluate respective issues presented in Section 1,
we implemented a realistic mobile business applica-
tion. It provides the basis how to use sensors for mon-
itoring vital signs within a mobile application.
We decided to develop a fitness application. Be-
sides standard requirements, such as robustness and
applicability, we focus on flexible real-time data col-
lection from external sensors. To give athletes more
options for collecting information about their vital
signs, we wanted to support a variety of vital sensors.
Specifically, in this application, we used two different
sensors measuring two vital signs (heart rate, and oxy-
gen saturation). Furthermore, both the processing and
the visualization of gathered data shall be adequately
supported by the application.
The “XFitXtreme” application is used to support
athletes on doing CrossFit. The goal of this type
of fitness workout is to practice on many different
methods, such as strength, speed, agility, or stamina.
Thus, a maximum fitness of the entire body shall be
achieved. A standard training session of CrossFit usu-
ally lasts 60 minutes. Consequently, recording data
of such a training results in a considerable amount of
data. In addition, athletes should be in constant con-
trol of their vital signs, to prevent any risk of injury.
These requirements of the fitness domain serve as a
proper application scenario for the first usage of ex-
ternal sensors within a mobile application.
2.2 Other Application Scenarios
Regarding sensor integration, we basically focus on
mobile healthcare applications. We present three sce-
narios from the medical domain, in which we revealed
by interviewing physicians that they could be dramat-
ically relieved in their daily routines. The healthcare
domain therefore has revealed different scenarios, in
which patients could benefit from the use of these de-
Medical Ward Rounds in Hospitals. In their
daily medical round, physicians have to deal with
unscheduled patient examinations (Pryss et al.,
2012), e.g., measure the blood pressure, or blood
sugar level. To collect this data more accurately,
mobile healthcare applications integrating exter-
nal sensors could be used. With the help of
such mobile applications, vital signs can be col-
lected and automatically stored in the electronic
patient record. In addition, certain procedures
could be automatically started, depending on the
current patient’s vital signs. Consider for ex-
ample, a doctor determines an increased blood
sugar level using his smart mobile device provid-
ing a blood sugar sensor. The information will
then be documented and archived in the patient’s
electronic record. The clinical decision support
system (Trowbridge and Weingarten, 2001) then
could suggest the procedure “schedule medication
for lowering blood sugar level”.
Rescue Service. Particularly in rescue services
it is important to ensure fast, reliable, and real-
time measurement of a patient’s vital signs. In
this case, patients could benefit by using sensors
that provide information about their health condi-
tion. For example, rescue staff checks the oxygen
level of a patient at accident site. With the help of
a smart mobile device and external sensors, it can
be easily checked, whether the patient is hyper-
ventilating. If oxygen level is above 98%, coun-
termeasures must be performed quickly to stabi-
lize the patient.
Aside from the mentioned scenarios, the domain of
clinical psychology provides other interesting possi-
bilities using sensor data in mobile applications.
Psychological Questionnaires. In other research
projects, we have already gathered experience re-
garding the development of mobile business ap-
plications for clinical psychology. This includes
for example the development of digital question-
naires for collecting patient data. In this con-
text demands emerged to integrate external sen-
sors. For example, the patient’s vital signs could
be monitored during data collection. Thus, an ex-
ceptional patient behaviour will be indicated by
his vital signs. Consider the following example:
A question “Do you take drugs?” is provided to a
patient. If the patient answers with “No”, and the
interviewer observes that the patient’s pulse rises
while giving the answer to this question, then she
has more indications to evaluate the quality of the
respective answer. Therefore, pulse data associ-
ated with this question is stored electronically and
can be used when evaluating the questionnaire.
The usage of external sensors, coupled with a mo-
bile business application could improve the quality of
medical healthcare procedures as presented above.
This Section will cover basic concepts, which have
to be carefully considered in the course of the de-
velopment of mobile business applications aiming at
the integration of external sensors. In Section 3.1,
we basically focus on the appropriate development
type of mobile applications (Web Application, Hybrid
Web, or Mixed Application, or Native Application).
We consider this discussion as a fundamental aspect
for mobile application development. Section 3.2 de-
scribes our implemented system architecture, whereas
Section 4 discusses important implementation details.
3.1 Different Ways of Developing
Mobile Business Applications
Before beginning the development of a mobile busi-
ness application, one has to consider the basic devel-
opment type for the application. It determines the
scope of provided features available in the applica-
tion. In addition to this, based on the chosen type
of application development, aspects like program-
ming language (e.g., Java or HTML5 and JavaScript)
or architectural design patterns (e.g., Model-View-
Controller) will be basically determined (Heitk
et al., 2013). In the following, we define four differ-
ent development types for mobile applications which
have to be distinguished.
Web Applications. This type of mobile business
application, e.g., jQuery Mobile Applications, is
implemented using HTML5, CSS, and JavaScript.
Usually, the application code is rendered within a
mobile web browser. According to this, these ap-
plications are independent of a platform and de-
vice. Compared to native applications, this is a
lightweight approach. In contrast to their minimal
implementation effort, such applications provide
the smallest set of functionality, because they rely
on the feature set of a web browser.
Hybrid Applications - Web. The application
code of this type of mobile business applications,
e.g., Adobe PhoneGap Applications (Adobe Sys-
tems Inc., 2013), consists of the same web tech-
nologies as for real Web Applications. However,
they run in a native application container (e.g.,
iOS WebView), which, in turn, can provide ad-
ditional functions.
Hybrid Applications - Mixed. These type of
Hybrid Applications, e.g., Appcelerator Titanium
Applications (Appcelerator Inc., 2013), provide a
core of mobile development APIs which will be
Figure 1: Different types of mobile business applications
according to (IBM Corporation, 2013).
normalized across platforms. These APIs can be
used like known web technologies (cf. Hybrid
Applications - Web). However, during the de-
ployment of the application a mapping between
elements of HTML5 and elements of the corre-
sponding native platform must be automatically
Native Applications. Native Applications, e.g.,
Android Applications, represent the way of im-
plementing mobile business applications using the
standard API. They are implemented using the
native programming language (e.g., Java for An-
droid), and therefore require more special knowl-
edge of device-specific development issues. They,
in turn, offer the most possible functionality
through direct use of respective platform provided
programming libraries and interfaces. In addition,
native applications show the best performance and
applicability for users.
Figure 1 illustrates the previously mentioned de-
velopment types of mobile applications pointing out
the differences related to application code.
Table 1 presents to advantages and disadvantages
of the different development types of applications.
Considering the fact that we need access to device
features like the Bluetooth communication stack, we
only can address the type of application that supports
this specific feature. In addition, we want to achieve a
high motivation using our fitness application. There-
fore, a robust retrieval of sensor data and finally visu-
alize the vital signs adequately will be crucial for the
overall user acceptance. Moreover, it should be possi-
ble to integrate vendor-specific software, like custom
drivers for sensors. All requirements have indicated
to us implementing the fitness application “XFitX-
treme” as native application. We decided to develop
on the Android platform, because of its full access to
the Bluetooth communication stack.
3.2 Architecture
We have discussed different development types of ap-
plications, and considered their advantages and disad-
vantages. Based on this, we present our architecture
applied to “XFitXtreme”. Figure 2 therefore shows
our architecture. In the further course of this Section,
we will discuss the different conceptualized layers of
the architecture in detail.
3.2.1 Android Application Framework
The Android Application Framework
passes a set of APIs enabling the development of na-
tive Android applications. Therefore it provides na-
tive libraries that are accessible through those APIs.
With these libraries, it is possible to access a database,
call webservices, or communicate via Bluetooth. An-
droid Applications (e.g., our “XFitXtreme” applica-
tion) directly interact with this application frame-
work, which manages basic functions of the smart
mobile device, such as automatical resource manage-
ment. Being a mobile business application developer,
this basic toolset enables for building your own appli-
3.2.2 XFitXtreme Application
The architecture of “XFitXtreme”
includes the fol-
lowing major components of a mobile application:
To ensure maximum flexibility and portability of
various components, the latter are strictly sepa-
rated. This means that user-interface components
Figure 2: General architecture of XFitXtreme.
, such as widgets or activities, can be easily re-
placed or adjusted without altering the specific ap-
plication logic.
The SQLite database
is a default feature of
Android and is used to store user data (e.g.,
such as training information), application settings
(e.g., such as language settings), and, for exam-
ple, recorded vital signs from external sensors.
Thus, it is basically possible to evaluate and visu-
alize them afterwards. Accessing a database has
been provided through an encapsulated manage-
ment component. The same applies to the local
file system
, which contains images or videos.
The “XFitXtreme Specific Components”
clude classes and interfaces for the various fea-
tures necessary in the fitness domain (e.g., admin-
istration of workout). Furthermore, visualizing
sensor data is implemented by the usage of the
Google Charts API (Google Inc, 2013). This al-
lows for a comfortable creation of charts based on
gathered data from external sensors.
The most important component of our “XFitX-
treme” Application is the sensor framework
(cf. Section 4.2.5). This framework enables us
to integrate new sensors easily, without reimple-
menting basic functions like the establishment of
a Bluetooth connection. Our mobile business ap-
plication “XFitXtreme” currently uses the Blue-
tooth component feature of the framework, since
external sensors in the fitness domain are usually
connected wireless.
3.2.3 Sensors
This Section introduces sensors
used in this project
for collecting vital signs of the CrossFit athlete. In ad-
dition to general information, we will present techni-
cal challenges of the device sensors. Currently, we
integrated two different sensors, namely the “Polar
Wearlink+ Heart Rate Monitor” (Polar Electro GmbH
Deutschland, 2013), and the “MedChoice Oxime-
Table 1: Advantages and disadvantages for the different development types of applications.
Feature Web App Hybrid App - Web Hybrid App - Mixed Native App
Execution within Web browser WebView within Native Environment Native Runtime
Native Shell within Native Shell Environment
Programming Language Web only Web only Native and Web Native only
Code Portability High High Medium None
Access Device Features None Low Medium High
Graphics and Animations Medium Medium High High
Party Libraries JavaScript JavaScript JavaScript and Native Native
User Experience Low Low Medium High
Performance Low Low Medium High
Figure 3: Sensors used in our mobile business application.
ter MD300C318T” (MedChoice, 2013), which are
shown in Figure 3.
The “Polar WearLink+ Heart Rate Monitor” is
one of only two Bluetooth athletic heart rate monitors
available for Android smart mobile devices. The sen-
sor itself is clipped to a soft textile belt and is worn
around the chest (i.e., directly below the chest mus-
cles). As soon as the belt is put on correctly and
paired with a device, it starts sending data packages
via Bluetooth (2,4GHz frequency band). For pairing,
no handshake is required, making it easy and straight-
forward to use this external sensor.
The “MedChoice Oximeter MD300C318T” not
only provides the heart rate, but also measures the
oxygen saturation of the blood. It was designed
for medical use and therefore offers more informa-
tion than the Polar belt. The sensor itself has an
OLED display which visualizes the retrieved vital
signs showing both plain values and corresponding
diagrams (e.g., a bar chart as amplitude of the pulse).
Compared to the Polar belt, this sensor needs a com-
plex pairing and synchronization protocol to send vi-
tal signs, but offers two different modes (e.g., real-
time mode and non-real-time mode). Due to the fact
that we want to support the athlete during his training
session, we have focused on the real-time mode.
In this Section, the developed mobile business ap-
plication “XFitXtreme”
is presented as a proof-of-
concept implementation. Section 4.1 describes the
implementation of the business application, while
Section 4.2 presents the lessons learned of this
4.1 The XFitXtreme Application
“XFitXtreme” is an application designed to display
the functionality offered by the developed sensor
framework. The framework establishes and manages
a Bluetooth connection to a sensor the training athlete
is wearing. The sensor used here is a chest belt with
an integrated heart rate monitor from the “Polar Wear-
Link+”. Other sensors have also been paired (e.g.,
“MedChoice MD300C318T”, see Figure 4). “XFitX-
treme” has the task of recording and graphically eval-
uating the vital parameter supplied by the framework.
Simultaneously, it is a tool satisfying all needs of the
athlete training CrossFit. The UI is held clean and
simple to ensure an adequate display of the necessary
data and guarantee a good usability. “XFitXtreme”
offers useful features described in the following.
The most important feature is supplying the indi-
vidual training plan of the day. This is done in two dif-
ferent ways. If internet access is available, the work-
out is parsed from CrossFit website (CrossFit, Inc.,
2013) using the “Workout of the Day” (WOD) fea-
ture. This website posts and updates the “WOD” on a
daily basis, which is a large advantage making train-
ing plan logic unnecessary. If no connection is avail-
able, the “Classix” feature offers a database, listing
many workouts held locally. These workouts are dis-
played in a list, offering the possibility to view the ex-
ercises included in the workout before selection. Af-
ter choosing or parsing a workout, the exercises build-
ing up the workout are displayed in a list. This list
can optionally be posted on Facebook. The exercises,
if not familiar, can be searched on YouTube by sim-
ply tapping on the element in the list. If all exercises
video available under
Figure 4: Dialog to connect to various external sensors.
are familiar, the play button leads to the final activity.
This activity displays the entire workout and shows all
relevant data, including the heart rate data offered by
the framework. The best time for the daily workout
is automatically loaded by a web service accessing an
online database. The sensor is connected automati-
cally via Bluetooth and, after that, starts transmitting
data. The beginning of the workout is signalized by
pressing the go button. The application takes the time
the athlete needs to complete the workout and starts
recording the heart rate data. Finishing the work-
out uploads the taken time, and the daily ranking is
displayed so the athlete can classify his performance.
The monitored data is visualized in a graph to give the
athlete a quick overview of his vital activities during
the workout (cf. Figure 5).
In addition to these main features, “XFitXtreme”
offers further features to support the athlete in his
training. The first is a timer, which combines a sim-
ple stopclock with a lap option and an interval timer.
The stopclock can take time and a random number of
laps, which are displayed in a list. The interval timer
offers the possibility to set up individual timers and
save these persistently. These timers are displayed by
name in a list after selecting this feature. Each timer
can be named, an arbitrary number of rounds can be
set and finally a random number of intervals can be
added. Each interval is characterized by a name, a
time, and a color. These attributes are displayed later
on while playing the timer, so the athlete knows which
interval is currently running. Selecting a timer from
the list plays the timer. Each interval added to the
timer is displayed in the order set before, counting
down the set time, displaying the name and the color
set as background color. That way, the change of
interval is not only signalized acoustically, but also
visually by a change in the background color. The
end of the workout is signalized by an applause. The
Figure 5: Visualization of vital signs during the workout.
timers can be deleted if no longer used.
CrossFit is unfortunately not too popular. De-
pending on the area, in which the athlete is training,
it can be difficult to find other people sharing their
passion for this sport. Therefore, “XFitXtreme” of-
fers an IRC chat. The latter is an open chat, in which
all users share a forum. This increases the chance of
athletes being online simultaneously, establishing an
online community. It is possible to send messages pri-
vately to other users as well. These messages are not
visible for the other users in the forum, and are dis-
played in a different color. That way both users know
these messages are private.
4.2 Lessons Learned
In this Section, we present aspects elicitated during
the development of this mobile business application
using the two mentioned external sensors.
4.2.1 Basic Development Types for Mobile
The market research company Gartner predicted in
early February 2013, that by 2016, 50% of all mo-
bile business applications are developed using hy-
brid technologies (Gartner, Inc., 2013). We re-
alized while designing and implementing “XFitX-
treme”, that none of the current available hybrid ap-
proaches (e.g., PhoneGap, Appcelerator) met the es-
sential requirements for our application. The same
applied to the implementation of pure web applica-
tions. We revealed unrestricted access to the Blue-
tooth API and full support of the specified Bluetooth
profiles (e.g., SPP profile) as the most important argu-
ments for developing our native mobile business ap-
plication “XFitXtreme”. These features are not avail-
able within a hybrid development framework, such as
Table 2: Bluetooth support for different development types
of business applications.
Bluetooth Support
Web App No Support
Hybrid App - Web Limited Support
Hybrid App - Mixed Limited Support
Native App Full Access
Figure 6: Different communication mechanisms for the ex-
ternal sensors.
PhoneGap or Appcelerator. Without this capability,
the integration of external and wireless sensors is not
Table 2 shows the Bluetooth support for the dif-
ferent development types of applications defined in
Section 3.1.
Furthermore, these hybrid development frame-
works did not fulfill our requirements regarding per-
formance of data processing, and a suitable as well
as interactive visualization (e.g., using animated dia-
4.2.2 Establishing a Connection
One challenging issue we encountered while using
external sensors was the handling of different types
of connections, such as Bluetooth, USB, Infrared,
or Wi-Fi. Depending on their characteristics, some
vendor-specific communication mechanisms have to
be used. For example, the “Polar WearLink+ Heart
Rate Monitor” belt (Bluetooth connection) requires,
after the successful pairing with the smartphone, no
further synchronization or handshake techniques to
obtain data. In contrast, the “MedChoice Oximeter
MD300C318T” (Bluetooth connection) sensor needs
extended synchronization and a test sequence before
data is available. Both sensors have in common that
data is actively and periodically transmitted to the
smart mobile device (cf. Figure 6).
4.2.3 Structure of the Sensor Data Packages
In this Section, insights regarding to the structure of
the data packages received by an external sensor are
Figure 7: Different structure of data of the implemented
shown. The most challenging aspect has been the
vendor-specific and proprietary exchange format. No
official documentation on the structure of data pack-
ages was found for the “Polar WearLink+ Heart Rate
Monitor”. This information must be gathered through
internet research, or even worse, through reverse en-
gineering of the data packages. In the case of “Med-
Choice Oximeter MD300C318T” we received an ex-
tensive documentation about the data packages after
sending a request to the producing company.
Figure 7 shows differences in the structure of the
data packages of our used sensors. They greatly dif-
fer not only in length of transmitted data packages,
but also in contained data. The “MedChoice Oxime-
ter MD300C318T” provides more information about
the vital signs than the “Polar WearLink+ Heart Rate
Monitor”, which results in a more complex data pack-
age structure (cf. Figure 7).
4.2.4 Connection Problems
We encountered a problem concerning connection is-
sues. Both Bluetooth and Wi-Fi (B and G standard)
transmit in the unlicensed ISM (Industrial, Scientific
and Medical) frequency band of 2.4 GHz (Lansford
et al., 2001). This means, it may cause interference
with a Wi-Fi network. This noise from other networks
possibly causes a connection loss between the smart
mobile device and the external sensor, or a complete
disconnection. In addition to this, Bluetooth has lim-
ited range, depending on the Bluetooth class. Table 3
shows the approximate range of different Bluetooth
classes (Bluetooth Developer Portal, 2013). Short
ranges as a characteristic property of Bluetooth can
be critical. Especially in the medical domain when
the physician moves too far from the patient and the
connection gets interrupted.
If the connection between the smart mobile de-
Table 3: Bluetooth classes and approximate range.
Bluetooth Class approx. Range
Class 1 approx. 100m
Class 2 approx. 20m
Class 3 approx. 10m
vice and the external sensor gets disconnected, the
question arises, how to suitably respond. One op-
tion would be that the smart mobile device should
try to initiate a reconnect periodically. Depending
on the scenario, it is important to interact with the
user and inform him about the disconnection. For
our presented fitness application “XFitXtreme”, it is
not important, because no critical information must
be exchanged. Nevertheless, in the medical domain,
it could be very important to tell a physician that cur-
rently there is no coupling between the devices (e.g.,
smartphone and heart rate monitor), and hence no
real-time information about the vital signs is avail-
On the one hand, some external sensors have a
small internal memory, where data can be cached in
case of a disconnection. Thus, it is possible to cope
with a short time of disconnection and provide cached
data in addition to the real-time values which have
been gathered in the meantime. On the other hand,
the smart mobile device has to deal with missing data.
In some cases, already recorded data needs to be dis-
carded, since the measurement is no longer valid.
In the context of a wireless connection between
the smart mobile device and external sensors, all these
questions need to be considered.
4.2.5 Sensor Framework
Reflecting on the previously described lessons, we
developed a basic mobile sensor framework which
can be easily integrated into existing Android appli-
cations. It shall encapsulate already mentioned het-
erogeneity of data structure of different sensors (cf.
Section 4.2.3) as well as the communication between
the external sensor and the smart mobile device (cf.
Section 4.2.2). In addition, connection problems (cf.
Section 4.2.4) should be handled. Furthermore, the
sensor framework should provide basic functionality,
such as establishing a connection to a sensor, or re-
ceiving data from a sensor. Finally, requirements,
such as the extensibility, maintainability, or scalabil-
ity have to be considered. Figure 8 shows the architec-
ture of our sensor framework. The individual applica-
tion layers are described in the following sections.
The Android Application Framework” serves as
the basis for our mobile business application. This
framework provides the fundamental functions and
Figure 8: Sensor framework architecture.
interfaces (e.g., for the Bluetooth or USB connection).
Our described sensor framework consists mainly
of three layer, namely the Administration Layer,
Communication Layer, and Specific Driver Layer.
The “Administration Layer” contains the “Frame-
work Manager”, which is responsible for the basic
communication with the framework. It provides ba-
sic methods which an application developer needs to
use external sensors in his mobile business applica-
tions. This includes methods concerning the connec-
tion (e.g., open or close a connection), receiving data
from a sensor, or configuring a sensor using special
messages. An application that implements the sensor
framework communicates only with this framework
The second layer, namely the “Communication
Layer”, provides all classes to manage the different
types of connections, like Bluetooth, WiFi, or USB.
These classes rely on the Android Application Frame-
work through the provided interfaces.
The third layer named as the “Specific Driver
Layer”, includes classes for the individual sensors.
These classes are derived directly from the associ-
ated communication layer class, and contain informa-
tion for setting up the connection. Consequently, only
methods for configuring the sensor, or receiving the
data, will have to be implemented.
The “Wired & Unwired Sensors” layer repre-
sents the external sensors connected to the mobile de-
vice. In our application scenario, these are the afore-
mentioned discussed sensors “Polar WearLink+ Heart
Rate Monitor” and “MedChoice Oximeter”, which
provide us with the gathering of vital signs.
In the following we will discuss related projects.
For this purpose, we distinguish these projects in
two categories, namely “Consumer” and “Research”
The most known example from the consumer do-
main is the mobile application “runtastic” (runtastic
GmbH, 2013), which is available on all major mobile
device platforms. This application offers the ability
to integrate different pulse sensors to the mobile de-
vice. The vital signs as well as the GPS position are
recorded in real-time. Finally, the gathered data can
be analyzed within the runtastic platform and shared
among friends. Runtastic offers an easy to use ap-
plication, with almost no installation or configuration
effort. Additionally, runtastic now offers its own hard-
ware shop, in which 100% compatible GPS and pulse
sensors can be bought.
Another well-known example of such an applica-
tion is “Nike+” (Nike Inc., 2013). However, there
is a small sensor inserted into the shoe, which will
then track all movements (GPS position, distance, or
stamina). This sensor is then connected to the smart
mobile device to visualize the collected information.
In addition, all “Polar WearLink+” sensors can be
used and coupled with the smart mobile device in or-
der to gather vital signs of the athlete.
Both consumer applications assume that the con-
nection between the external sensors and mobile de-
vice in the context of the fitness application is reliable.
Unfortunately, we were not able to adopt their com-
munication structure because of the proprietary phi-
losophy. In addition, they offer hitherto only the use
of pulse sensors.
Research projects like “Open Data Kit” (Open
Data Kit, 2013) address a suitable mobile data col-
lection. Open Data Kit aims at providing a self-
containing framework for data collection. The in-
tegration of external sensors in Android smart mo-
bile devices are discussed in (Brunette et al., 2012)
or (Chaudhri et al., 2012). Even though, we can not
adopt results directly for our goal. The reason is that
we can use “Open Data Kit Sensors” framework only
inside the “Open Data Kit” project, which would be to
complex. In addition to this, the applicability for our
future usage in the medical domain would be not suit-
able. Instead, we are trying to create a sensor frame-
work, which can be used as a standalone application.
Thus, we want to enable application developer to use
this framework in their own projects and applications.
In this paper we presented a real-world mobile busi-
ness application from the fitness domain. This ap-
plication was implemented to be used with external
sensors for gathering vital signs of athletes in order
to support them in their frequent training sessions.
To implement such a mobile application, we first had
to determine the appropriate development type of ap-
plication (e.g., Web Application or Native Applica-
tion). In case of the “XFitXtreme” application we
implemented a native application because of the lack
of Bluetooth functionality for the other basic devel-
opment types of mobile applications. Moreover, we
aim at real-time processing and visualization of gath-
ered vital signs and hence a challenging and realistic
application was a must. Additionally, we presented
a system architecture for business applications that
shall be used with external sensors and explained our
layered design. To strengthen our described archi-
tecture, the fitness application “XFitXtreme” using it
was shown. However, we set the main focus on the
lessons we have learned from this project. We there-
fore discussed different aspects related to the connec-
tion between the mobile device and the external sen-
sor as well as different structures of data packages
retrieved by the external sensors. Our experiences
resulted in developing a sensor framework, which is
currently used in a real-world fitness application. The
framework was discussed, and needed functions for
the CrossFit training were presented.
In the future, we plan to extend the sensor frame-
work described in this paper. We plan a feature to
add more sensors, and support different types of con-
nection standards as well, such as ANT, ANT+ (Dy-
nastream Innovations Inc, 2013), or ZigBee (ZigBee
Alliance, 2013). Furthermore, we want to implement
a mobile process engine to interact with the coupled
external sensors using our described sensor frame-
work. This would empower us to carry out the data
collection with sensors as a process. However, prob-
lems, like flexibility, should be carefully considered
(Reichert and Weber, 2012). Besides technical im-
provements, we want to add more features to visualize
gathered data from sensors. We therefore want to im-
plement the Google Charts Tools (Google Inc, 2013)
in our sensor framework to allow athletes to interac-
tively browse through their different vital signs. An-
other goal we pursue is to provide this sensor frame-
work on other mobile operating system, like Apples
iOS. This enables us for example to reveal insights
to the interplay between the iOS platform and exter-
nal sensors. Finally, we focus more on scenarios of
the medical domain using our framework to ease daily
work of medical staff.
Adobe Systems Inc. (2013). PhoneGap. http://
517 last visited: 22. February 2013.
Appcelerator Inc. (2013). Titanium Mobile App De-
velopment Platform.
platform/titanium-platform/. last visited: 22. Febru-
ary 2013.
Bluetooth Developer Portal (2013). Compare with
other Technologies. http://
TechnologyOverview/Pages/Compare.aspx. last vis-
ited: 22. February 2013.
Brunette, W., Sodt, R., Chaudhri, R., Goel, M., Falcone, M.,
Van Orden, J., and Borriello, G. (2012). Open data kit
sensors: a sensor integration framework for android at
the application-level. In Proceedings of the 10th inter-
national conference on Mobile systems, applications,
and services, pages 351–364. ACM.
Chaudhri, R., Brunette, W., Goel, M., Sodt, R., VanOr-
den, J., Falcone, M., and Borriello, G. (2012). Open
data kit sensors: mobile data collection with wired and
wireless sensors. In Proceedings of the 2nd ACM Sym-
posium on Computing for Development, page 9. ACM.
CrossFit, Inc. (2013). CrossFit - Forging Elite Fitness.
http:// last visited: 22. February
Dynastream Innovations Inc (2013). THIS IS ANT
- the Wireless Sensor Network Solution. http:// last visited: 22. February 2013.
Gartner, Inc. (2013). Gartner Says by 2016, More Than
50 Percent of Mobile Apps Deployed Will be Hy-
last visited: 22. February 2013.
Google Inc (2013). Google Chart Tools. https://developers. last visited: 22. February 2013.
otter, H., Hanschke, S., and Majchrzak, T. A. (2013).
Evaluating cross-platform development approaches
for mobile applications. In Web Information Systems
and Technologies, pages 120–138. Springer.
IBM Corporation (2013). IBM Worklight - Mobile ap-
plication platform.
mobile-solutions/worklight/. last visited: 22. Febru-
ary 2013.
Lansford, J., Stephens, A., and Nevo, R. (2001). Wi-fi
(802.11 b) and bluetooth: enabling coexistence. Net-
work, IEEE, 15(5):20–27.
MedChoice (2013). The MedChoice MD300C318T. http:// last vis-
ited: 22. February 2013.
Nike Inc. (2013). Nike+.
last visited: 22. February 2013.
Open Data Kit (2013). Open Data Kit - magnifying human
resources through technology.
last visited: 22. February 2013.
Polar Electro GmbH Deutschland (2013). Polar WearLink+
Sensor Bluetooth.
de/produkte/. last visited: 22. February 2013.
Pryss, R., Langer, D., Reichert, M., and Hallerbach, A.
(2012). Mobile task management for medical ward
rounds - the medo approach. In 1st Int’l Workshop
on Adaptive Case Management (ACM’12), BPM’12
Workshops, LNBIP. Springer.
Pryss, R., Tiedeken, J., Kreher, U., and Reichert, M. (2010).
Towards flexible process support on mobile devices.
In Proc. CAiSE’10 Forum - Information Systems Evo-
lution, number 72 in LNBIP, pages 150–165. Springer.
Reichert, M. and Weber, B. (2012). Enabling Flexibility
in Process-Aware Information Systems: Challenges,
Methods, Technologies. Springer, Berlin-Heidelberg.
runtastic GmbH (2013). runtastic - makes sports funtastic. last visited: 22. February
Trowbridge, R. and Weingarten, S. (2001). Clinical deci-
sion support systems. Making health care safer: a
critical analysis of patient safety practices. Evidence
Report/Technology Assessment, (43).
ZigBee Alliance (2013). ZigBee Alliance - Control your
world. last visited: 22. Febru-
ary 2013.