Related work

This is a list of similar projects and how they compare to our goals. In other words, an ongoing justification of why I'm writing this myself instead of using an existing codebase.

Here's a list of the goals that I have for what I call "the sync layer".

1. Low power consumption, which implies:

• Not using the sensors unless we have to
• Using the lowest power version of the sensors that are feasible
• Offline caching and periodic sync. Per: https://source.android.com/devices/tech/power/index.html indicates that using the cellular radio to transmit data is very power intensive: an order of magnitude worse than using wifi, and two times worse than using the GPS continuously. So sending sensor data up to the server continuously or pulling data from the server continuously is going to kill the battery, even if the connectivity is not intermittent.
  • screen on at max brightness: 300mA - 600mA
  • wifi on and transmitting: 31mA
  • radio transmitting: 100mA - 300mA
  • gps acquiring signal: 50mA

2. Support for both push (listener based) and pull sensors

• Push sensors are mainly sensors that are already supported for polling at various frequencies by the phone OS
• Pull sensors are mainly sensors that we need to query periodically, such as the fuel consumption using bluetooth

3. Support for both iOS and android

• iOS has a significant market share, at least in the US
• However, while android has solid support for background operation, iOS does not.
• Fortunately, location tracking is one of the supported background modes, but it implies that all sensors on iOS are likely to be pull sensors.

4. Dynamic "settings" and screens. Personalized settings, screens and results help us tailor the app to user behavior and also perform better testing.

• Low response time/intermittent connectivity
  • Data that is displayed to the user, and/or used to configure the background collection, should be cached on the phone for maximum effectiveness
• Support for caching and dynamically updating result screens using cordova

5. Security and Authentication

• Strong authentication that does not require users to log in every time, and which does not leak information to other apps
• Preferably OAuth/JWT based in order to avoid managing our own usernames and passwords

Here are the projects that I have found so far, and how well they match up to the goals.

• BearLoc (Kaifei)
  1. Low power consumption: No local caching or deferred update. All sensor data immediately published using MQTT
  2. Push and pull sensors: ??? Currently pushed codebase only appears to read WiFi values
  3. Multiplatform support: No. Android only
  4. Dynamic settings and screens: No. Native UI, config in local files.
  5. Security: ???
• StreamFS/EnergyLens (Jorge): No phone codebase available.
  1. Low power consumption: Local caching with a batched retrieve, but not in the background.
  2. Push and pull sensors: Unsure, no codebase
  3. Multiplatform support: No. Android only, and even that codebase is not available.
  4. Dynamic settings and screens: Unsure, no codebase.
  5. Security: ???
• Funf (MIT): Won grant from Knight foundation for "Behavio". Behavio was acquired by google. No updates since 2013. Forum has a lot of questions and complaints about things not working.
  1. Low power consumption: Local caching with background sync. Naive background operation. Old location API, not fused.
  2. Push and pull sensors: Looks like it (SMS, "Android Info")
  3. Multiplatform support: No. Android only
  4. Dynamic settings and screens: Config is retrieved from the server using HTTP get. Don't see how to specify the user, so unclear if this is personalized.
  5. Security: None. The data is uploaded to a HTTP server using form-data. I don't see any authentication in there. The assumption appears to be that nobody will know about your secret HTTP server.
  6. Misc wierdnesses:
  • Data is uploaded as raw files instead of through a REST API
  • Lots of support for manual uploading
  • They have built their own scheduler/pipeline
• xsensorlabs/emotionsense.org (Cambridge): Ongoing development.
  1. Low power consumption: Local "logging" with automatic background transfer based on alarms. Only supports passive location handling.
  2. Push and pull sensors: Yes, including media
  3. Multiplatform support: No. Android only
  4. Dynamic settings and screens: No. Config is hardcoded. I am not sure about screens, but they are not javascript based.
  5. Security: None. The data is uploaded to a HTTP server as raw files. I don't see any authentication in the POST request.
• Ours: Ongoing development.
  1. Low power consumption: Use of geofences to collect location data intelligently. Automatic background transfer based on the recommended data sync protocol.
  2. Push and pull sensors: Only location and activity initially. Have a initial sketch of a poll sensor implemented. Poll sensors are only invoked when we get location updates.
  3. Multiplatform support: Android and iOS. iOS needs to be changed to use visits/push notifications instead of background fetch, which is notably unreliable.
  4. Dynamic settings and screens: Config and results can be loaded and cached on the phone. Need to build in some server side mechanics to add/edit configs, and implement screen caching.
  5. Security: OAuth + JWT.