Consolidated the insert/update steps for simplicity.

[lwis]

Using this method it should no longer require NewDayReceiver as we’re
always storing the most up to date steps for the current day at the
time of update.

Unless of course there’s another use for NewDayReceiver I’m not seeing
(I’ve not had a good look over the code).

The ShutdownRecevier is also VERY unreliable, what if the phone
crashes? I’m going to look at a better way of storing steps in the db
as I’ve lost steps myself from the app/phone crashing a few times.

[j4velin]

I don't think that'll work, here are some examples:

User walks N steps on day 1, then reboots the device (still on day 1):

• ShutdownReceiver will write N steps in the database
• on reboot, BootReceiver calls db.insertSteps(Util.getToday(), 0); which will result in writin "0 steps" in the database

User walks N1 steps on day 1 and N2 steps on day 2 without a reboot between those days.

• at midnight (changing from day 1 to day 2), NewDayReceiver will write -N1 steps for day 2 in the database
• 24 hours later, NewDayReceiver is called again and will write N1+N2 steps in the database for day 2. As insertSteps replaces the old value rather then adding both, this will result in a wrong step count for everyday until there is a reboot

[j4velin]

And to "storing the most up to date steps for the current day at the
time of update" we would need to update the database whenever a change in the SensorListener occurs - but I really want to avoid writing to flash memory whenever the user takes a step.

(I also just pushed some commits I made over the last days so please update your rep)

[lwis]

Good point, the first is easily solved if we just remove the insert from BootReceiver, right? Then whenever insertSteps() is called it will just create insert the steps for the new day.

As for the new day day;

What if NewDayReceiver operates a little differently, we can still insert a new day at midnight at 0, but before doing that we write to the DB with the final steps of the day. That way we can guarantee that we can always add to the current day or offset from the day before?

As for writing more regularly, I think a 15m alarm would suffice here. I'm trying to work out how often you're writing at the moment.

I'll rethink my strategy and create a new request, haha!

[j4velin]

Currently I'm only writing on shutdown and on a new day.
Removing the call from the BootReceiver doesn't really solve the issue, as SensorListener.steps is actually 0 right after boot. So whenever after the boot the insertStep method is called, it will overwrite the existing value with a lower one.
Note the the Android step sensor measures in "steps since boot"

[lwis]

That explains why I'm losing a day of steps then, I typically flash a nightly before I sleep (which is before midnight). CyanDelta doesn't shutdown gracefully so ShutdownReceiver won't be called.

That's a bit of a pain, it's difficult to work out where you are in terms of offset without writing regularly.

It's on the backburner 👍

[lwis]

Thinking aloud;

What if the last raw step count is stored?

If the current raw step count is less than the last stored, it's safe to assume a reboot has occurred?

[garyo]

On Wed, Jan 15, 2014 at 1:06 PM, lwis notifications@github.com wrote:

Speaking aloud;

What if the last raw step count is stored?

If the current raw step count is less than the last stored, it's safe to
assume a reboot has occurred?

You can still lose. If raw count > stored count, you don't know whether a
reboot occurred in the middle (and then the user took a lot of steps) or
not. The only way to be robust across reboots that kill the app hard is to
store more frequently, which would cost battery life. (But maybe not much,
if it woke up every 15 min or something).

Gary

[lwis]

Which is why I was going to suggest that the step count needs to be stored on boot, if it's 0 then that's fine - this just shows that we've had a reboot and the offset has changed.

The store frequency is something that seriously needs to be improved, the risk of loss at the moment is huge. The good thing about using an Alarm is that it will store when it's most efficient for the device.

[j4velin]

Well, on reboot it's always 0 (as 0 steps occured since reboot).
If everything would work fine, it would be enough to store it on a new day and on shutdown, in my opinion. So mainly my goal is to make the NewDayReceiver actually start at 0:00:01 AM ^^
So far, I have no idea why that alarm is ever canceled...

[lwis]

In a perfect world with perfect devices you have predictable usage. However, unfortunately, in the real world neither of those are guaranteed to execute so, in some cases, the app will never store data.