usage.tex
7.14 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
\section{Example Use Cases}
\label{sec-usage}
The \texttt{maybe} system is inspired by our frustrations building smartphone
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.
\subsection{PocketParker App}
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.
Such runtime decisions fit naturally into the \texttt{maybe} framework.
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.
\subsection{\texttt{\large PhoneLab} Conductor}
\PhoneLab{} is a large scale smartphone platform testbed at the University at
Buffalo~\cite{phonelab-sensemine13,phonelab-url}. We leverage the Android
\texttt{logcat} subsystem as a data collection mechanism---experiment apps
write their data into a system-wide log buffer and we collect and upload this
data on their behalf.
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
lowest possible score if data had been lost, or otherwise a score combining
the multiple attributes the app is trying to minimize.
Due to the uncertainties we faced during development, we implemented a
configuration interface that periodically retrieves parameters from our
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,
and how to decide whether to upload data. Several of these features have
proven essential after deployment---for example, when an upload policy that
worked previously abruptly stopped working on a newer Androiod version.
Development of this app would have been considerably easier using
\texttt{maybe}, which could automate the process of pushing policies to
clients in an energy-efficient way, and enable per-user goal-driven
adaptation.
\subsection{Navjack Sensing Platform}
The Navjack project is exploring hijacking in-car navigation devices built
from repurposed smartphones~\cite{sustain-hotmobile14} and deployed in
personal vehicles to enable city-scale sensing. Volunteers install a device
that acts as a dedicated navigational aid and car performance monitor but
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.
\subsection{Android Platform Services}
Earlier, we noted that that app developers should not use \texttt{maybe} to
make decisions that are best left to libraries and platform services. However,
those same
libraries and platform services can themselves use \texttt{maybe} to enable
post-deployment testing and adaptation. We are particularly interested in how
\texttt{maybe} can be used within the Android platform itself wherever
structured uncertainty must be expressed.
One use case is determining whether to use Wifi or cellular network. While this is
a hot topic in current mobile systems research~\cite{shen2008cost}, the approaches
that are currently being tested may struggle to adapt to many of the
variable that the \texttt{maybe} system incorporates and arrive at an
effective per-user approach. A similar example is optimizing the state of
GPS. With three modes already present---``High accuracy'', ``Battery saving'', and
``Device only'', the choice may need to be adapted both to app usage and more
user- or device-specific factors. \texttt{maybe} allows post-deployment
testing of a variety of different approaches to make this runtime decision.
\begin{comment}
Stretching this idea further, what if the developer didn't have to think
about cache or object availability? The language itself could determine which
block to run based on the semantics of the \texttt{maybe} case definition.
For instance, in the \texttt{android.emoji.EmojiFactory} class, there is a
method to get an eomji via its Unicode PUA (Private Use Area). To do this,
the emoji is either grabbed from a platform-level cache or is created then
written to the cache then returned. With \texttt{maybe}, the developer could
have two blocks one for the cache being empty for the PUA and one where an
object exists. Now, the developer doesn't need to think about the
possibilities of cache-state, but instead can move on to other functionality.
\end{comment}