Mobile Apps: It's Time to Move Up to CondOS

Sensing is a significant contributor to the current mobile computing revolution. Today’s typical smartphone has more than eight sensors, including multiple mics, cameras, accelerometers, gyroscopes, a GPS, a digital compass, and proximity sensors. These sensors not only provide natural user interaction with the device, but also offer tantalizing opportunities for context-aware computing. A rich history of work has investigated algorithms for converting raw sensor data into context, and their specific usages [3]. To cite just two examples: A restaurant finder app may adjust its search radius depending on whether a user is on foot, cycling, or driving, which can be inferred from GPS and IMU readings [11]. A Twitter app might choose to alert the user of her latest updates at an interruptible moment such as when she is not engaged in conversation, which can be inferred from the mic’s audio [5]. The ingredients for context appear ready: the sensing hardware, the data processing algorithms and the application scenarios are all primed. The question that emerges is: who is responsible for context generation? One option is for apps to manage their own context generation. This approach appears appealing because apps are most familiar with their own context needs. However, many mobile OSs such as iPhone’s iOS and Windows Phone’s WP7 harbor legitimate energy concerns and severely restrict non-foreground processing. As a result, an app may generate context from immediately available sensor data, but is unable to maintain context while outside the scope of its execution. This can be as simple as missing the accelerometer’s transition from sitting to standing, since sensing either state outside the transition period does not yield distinguishing information. Alternatively, Android apps may run in the background, but then the user is at the mercy of the flawless app developer to use resources intelligently. Another option is to simply ship all sensor data to the cloud