|
|
1
|
\section{Example Use Cases}
|
|
|
2
3
|
\label{sec-usage}
|
|
|
4
|
The \texttt{maybe} system is inspired by our frustrations building smartphone
|
|
|
5
6
7
|
apps that confront the uncertainties inherent to mobile systems programming.
In this section we describe several examples of how to use the \texttt{maybe}
statement drawn from our own experiences.
|
|
|
8
|
|
|
|
9
|
\subsection{PocketParker App}
|
|
|
10
|
|
|
|
11
12
13
14
15
16
17
18
19
20
21
22
|
PocketParker~\cite{ubicomp14-pocketparker} estimates parking lot availability
by using the smartphone's accelerometer to detect users entering and leaving
parking spots. To do this is an energy-efficient manner, we initially
developed a custom activity recognition algorithm that duty-cycled the
accelerometer to conserve energy. Towards the end of our development, Google
released their own activity recognition API as a part of their Google Play
Services framework. Based on several small-scale tests there was no clear
winner when comparing the two algorithms, and so we decided to use Google's
implementation to offload the maintenance burden. Supporting both algorithms,
switching between them at runtime, and assessing the resulting impact on a
larger user population would have required a significant amount of
development effort.
|
|
|
23
24
|
Such runtime decisions fit naturally into the \texttt{maybe} framework.
|
|
|
25
26
27
28
29
30
31
32
33
34
|
Instead of having to choose based on small-scale local testing, the
\texttt{maybe} system can manage the transition from a mature but
app-specific and expensive to maintain algorithm to a potentially-immature
but canonical library implementation. As the library implementation improves
and begins to out-perform the hand-tuned alternative, the \texttt{maybe}
system can conduct repeated testing and move more users over to the library
implementation. For some users or on some devices, the library implementation
may never outperform the app-specific algorithm, in which cases
\texttt{maybe} allows both alternatives to coexist safely while ensuring that
each user enjoys whichever approach is most effective for them.
|
|
|
35
|
|
|
|
36
37
|
\newpage
|
|
|
38
39
|
\subsection{\texttt{\large PhoneLab} Conductor}
|
|
|
40
|
\PhoneLab{} is a large scale smartphone platform testbed at the University at
|
|
|
41
42
43
|
Buffalo~\cite{phonelab-sensemine13}. We leverage the Android \texttt{logcat}
subsystem as a data collection mechanism---experiments log their data into a
system-wide log buffer and we collect and upload this data on their behalf.
|
|
|
44
|
|
|
|
45
46
47
48
49
50
51
|
We developed an app called the \PhoneLab{} Conductor for this purpose which
provides a good example of custom \texttt{maybe} evaluation logic. The goal
of our app is to collect data reliably while minimizing energy consumption,
storage usage, and metered data usage. With the \texttt{maybe} statement
branching between multiple policies for uploading data---such as always
waiting until the user reaches a plug, or always initiating an upload once
the storage allocated is 50\% full---the evaluation logic would provide the
|
|
|
52
|
worst possible score if data had been lost, or otherwise a score combining
|
|
|
53
54
55
|
the multiple attributes the app is trying to minimize.
Due to the uncertainties we faced during development, we implemented a
|
|
|
56
|
configuration interface that periodically retrieves parameters from our
|
|
|
57
58
59
|
server and uses them to reconfigure variable components of the app. This
allows us to control aspects of program behavior such as the amount of
storage space we use on each device for logs, how often we check for updates,
|
|
|
60
61
|
and how to decide whether to upload data. Several of these features have
proven essential after deployment---for example, when an upload policy that
|
|
|
62
|
worked previously abruptly stopped working on a newer Android version.
|
|
|
63
64
|
Development of this app would have been considerably easier using
\texttt{maybe}, which could automate the process of pushing policies to
|
|
|
65
|
clients in an energy-efficient way, and enabling per-user goal-driven
|
|
|
66
|
adaptation.
|
|
|
67
|
|
|
|
68
|
|
|
|
69
|
\subsection{Navjack Sensing Platform}
|
|
|
70
71
|
The Navjack project is exploring hijacking in-car navigation devices built
|
|
|
72
|
from recycled smartphones~\cite{sustain-hotmobile14} and deployed in
|
|
|
73
|
personal vehicles to enable city-scale sensing. Volunteers install a device
|
|
|
74
|
that acts as a dedicated navigation aid and car performance monitor but
|
|
|
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
also continuously collects sensor data, utilizing the car's battery for
power, the car's driver for maintenance, and inexpensive machine-to-machine
(M2M) data plans for telemetry.
Navjack's goal is to produce high-quality data in response to queries while
minimizing cellular data usage and car battery energy consumption. Many
uncertainties specific to this app complicate the process. Some car cigarette
lighters and USB charging docks provide power while the vehicle is off, while
some do not. Users drive their vehicles for different durations and at
different frequencies. Cellular coverage varies, altering the energy-per-bit
required to offload data. All of these factors complicate post-deployment
adaptation.
\texttt{maybe} statements in Navjack can be used to control the sampling
rate, the set of sensors that are used, and the conditions under which
uploads are attempted. This app provides an example of an adaptation state
space that can potentially get quite large, and so it may provide a good
chance to evaluate both our ability to perform pre-deployment simulations to
reduce the state space and the success of post-deployment clustering
techniques to identify salient user differences.
|
