2

I'm currently writing an Android app that will need to do things such as :

  • Retrieving sensors data such as ActivityRecognition data, say every 20-30 seconds
  • Retrieving GPS data from time to time (e.g. when activity recognition sends that user is using its bike or car), so I'd say a few times per day max for average user. Frequency of GPS data retrieving could be every 5-10 seconds for example.

Of course, this data should be stored somewhere to be, later on, analysed by my app. The analyse part is not the problem here as I do not need a real-time calculation of any kind, so my actual concern is how to store the data efficiently.

So if we consider an average user that will generate about 5000 sensors data + 5000 GPS data :

  • How to best store this data ? Database ? 1 file per day ? I'd say database for performance issue and simplicity of use, but I'm not sure it's very good practice to open/close a database connection every 10/20 seconds to add just one line of data. Also, a journaled file (one per day) could be a good idea but I think this is pretty bad for a performance point of view, even using serialization ?
  • Will storing these 10000 data degrade battery life much more than just retrieving sensors (ActivityRecognition, GPS) data without storage ? I mean, it seems to me that it will be a bit overconsuming, but in the same time GPS is already using so much battery...
  • Is there another way to do that ?

Also thought of in-memory storage then every few minutes it could be put in hard storage (SQLite, files), but I'm not sure this is a good idea in terms of safely keeping the data...

Thanks in advance

Pom12
  • 7,622
  • 5
  • 50
  • 69
  • Sensor data, no. GPS drains some phones, but only while it's turned on. AFAIK simply reading it doesn't drain the battery; it's that it is turned on. If you need the data, you need the data. – Robert Harvey Jun 17 '14 at 18:56

3 Answers3

2

Compared to the GPS battery consumption, the reading and writing in the database will consume almost nothing (it is flash storage, after all), so no worries there. The database would be the best option to store this data in my opinion and I don't see a problem in creating a single entry every 10 or 20 seconds.

tknell
  • 9,007
  • 3
  • 24
  • 28
  • I would second the database approach, and if you want you can write to the database less frequently until reaching a local memory limit so you don't do frequent open and closing of the database. But you had already suggested this. – Jay Snayder Jun 17 '14 at 19:13
0

Also thought of in-memory storage then every few minutes it could be put in hard storage (SQLite, files), but I'm not sure this is a good idea in terms of safely keeping the data...

This is a very good idea. I have it done this way, and most systems that deal with files do it that way (called a buffer).

If your app crashes due a bug, some data will be lost, depending on the buffer size. In all other cases (device will shut down, user terminates app) you have time to write (flush) the buffer.

AlexWien
  • 28,470
  • 6
  • 53
  • 83
  • Thanks for the answer, but your answer leads me to a few questions : 1. How often would you recomand transfering data from memory buffer to database ? Should it be done every X minutes, or when we hit a list size limit ? Maybe both ? It seems to me that to avoid data memory loss I should save this data to database when any of the two conditions (either time or list size) is met, am I correct ? 2. It's interesting to think that I can still save memory data during a "normal" exit, but here I think I cannot spend too much time saving data in an onPause or equivalent method, it should run fast... – Pom12 Jun 17 '14 at 19:57
  • Saving that little data won't take long if run in a single transaction. Aditionally you can use an AsyncTask for saving the data in the onPause(), so the saving will not block the lifecycle methods. – tknell Jun 17 '14 at 21:13
  • Yup ok that's a good idea, I will test if saving to DB executes fast enough to be done directly in the onPause (it might be...) otherwise I'll just do that in an AsyncTask. Thanks a lot. – Pom12 Jun 18 '14 at 07:05
  • 1
    @Pom12 1) I have used the list size limit approach, because it is a buffer, and buffer have sizes. Buffer size can be an equalent of 30s to 5 minutes. (30 -300 location for frequency 1 location /s) – AlexWien Jun 18 '14 at 12:18
0

Just an short additional note.

Other than shutting down peripherals, not really an option in your case, maximize the length of time the processor is inactive. (This is not the same as minimizing the length of time the process is active.) This allows the processor to drop into lower sleep states (called C-states). The deeper the sleep state, the more power savings.

In a general sense, this means

  1. no polling; use interrupts instead,
  2. if you need to periodically wake up to see if anything needs to be done, make sure your interrupt period is the maximum allowable. (Contrary to current practice, waking up every 10 ms does not improve your responsiveness when the average event happens every 500 ms.)

This also applies to peripherals, as they drop into sleep states also when not active (Called D-states).

  1. Minimize the number of cloud accesses you do.
  2. Maximize the length of time between cloud accesses.
Taylor Kidd
  • 1,463
  • 1
  • 9
  • 11
  • I just answered another question that gives some more info on your question. See http://stackoverflow.com/questions/24207590/battery-effects-of-web-apps/24291017#24291017. – Taylor Kidd Jun 18 '14 at 16:51
  • Thanks for the additional note. For what is worth, I do not need any internet connection to run along with the GPS so cloud accesses are not really the subject here. The question is : shouldn't a peripheral like GPS be kept active if it is going to be used within the same period of time, rather than doing some cycles of go to sleep/wake up that could potentially consume a lot more than keeping in woken up ? I mean, I imagine that searching for antennas (for GPS) is very time and battery consuming, so I'd rather keep it active unless I really don't need it for a large amount of time ? – Pom12 Jun 19 '14 at 08:52