Data Field variables lost when you Resume Later

Apologies if this is already covered - I wasn't successful searching for this topic. It appears that any global variables declared in the Ui.DataField or Ui.SimpleDataField classes go out of scope when you stop the activity timer and choose to "Resume Later". When you do resume the activity, all variables are reinitialized. Am I missing something? Is there a way to persist values through a Stop - Resume Later - Start cycle?

Top Replies

All Replies

jim_m_58 over 8 years ago

...would it be valid to test for timerTime < elapsedTime as an indicator of a continued activity?

The difference between the two is that they both start at 0 when you start an activity. Elapsed time continues to run until the activity is saved or discarded.

However, timerTime will stop when you pause an activity, so you see the recorded time. This means if you paused even for a few seconds (you can manually pause many apps, and some also have auto-pause) and then resumed, timerTime will be less than elapsedTime for the rest of the recording

If you save off timerTime, you can check if it's less than it was the last time, meaning a new activity has begun. If it's the same, recording has been paused, and if it's increasing, you are recording.

I'm just talking a standard recording here and not a "resume later" type function,and for that it will probably be more complex.

Former Member over 8 years ago

Is there some reason that you can't you call Activity.getInfo()? Also, average speed can be zero if GPS is off, so this isn't a reliable way to detect an activity reset.

Many activities make little sense without speed. I suppose you could use elapsed time.

I don't know what the state of Activity.getInfo() would be in onStart, do you?

TermiSkater over 8 years ago

Many activities make little sense without speed. I suppose you could use elapsed time.

I don't know what the state of Activity.getInfo() would be in onStart, do you?

Perhaps I'm missing something obvious, but from what I can see, Activity.getInfo() isn't valid until after the onStart event has completed, so it's necessary to wait until the compute event fires before using any activity properties to decide whether the onStart which just finished represents the start of a brand new activity or the resumption of a prior one that's still in progress.

Former Member over 8 years ago

If you use elapsed time to detect activity start, you will be tied to when the user starts the activity.

The reason I use average speed to detect activity start is so I can display different info prior to the start of actual movement.

TermiSkater over 8 years ago

The difference between the two is that they both start at 0 when you start an activity. Elapsed time continues to run until the activity is saved or discarded.

However, timerTime will stop when you pause an activity, so you see the recorded time. This means if you paused even for a few seconds (you can manually pause many apps, and some also have auto-pause) and then resumed, timerTime will be less than elapsedTime for the rest of the recording

If you save off timerTime, you can check if it's less than it was the last time, meaning a new activity has begun. If it's the same, recording has been paused, and if it's increasing, you are recording.

I'm just talking a standard recording here and not a "resume later" type function,and for that it will probably be more complex.

(For once!) I think I was making this more complicated than necessary. It appears you can identify "new activity starting" by testing for info.elapsedTime == 0, and "previously paused activity resuming" by info.elapsedTime > 0.

udotha over 2 years ago

What about instances of global class variables? Do they also get out of scope when an activity is stopped and "resumed later"?

FlowState over 2 years ago in reply to udotha

udotha said:
What about instances of global class variables? Do they also get out of scope when an activity is stopped and "resumed later"?

You mean static variables? Just like anything else in your CIQ data field app's memory, they're lost when the user selects "resume later", because the CIQ data field app is terminated and the watch doesn't automatically save its state anywhere.

When an activity is "suspended", the only state that's automatically saved is the native activity state.