Retain state data over a crash.

I am retaining my app's state data using AppBase:setProperty which is working fine, and this data is being retained over successive app starts.

However, when the app crashes, the new state data is not being retained and an app restart will retrieve the same state data that the last app start retrieved.

It seems that the state data is only actually being written to a truly persistent object store when the app closes gracefully.

If this is the case, is there any way for the app itself to save the state data to the object store on a periodic basis to enable it to be restarted after a crash with the last saved state?

(Obviously, this wouldn't be an issue if the app didn't crash, and believe me, I'm working hard to track down the elusive bugs, but meanwhile...)

jim_m_58 over 8 years ago

It seems that the state data is only actually being written to a truly persistent object store when the app closes gracefully.

If this is the case, is there any way for the app itself to save the state data to the object store on a periodic basis to enable it to be restarted after a crash with the last saved state?

Yup.. writing to mass store is expensive, and happens on a clean exit today (you don't want to save something that may have caused your app to crash!)

The fix is to stop your app from crashing. I'm being a bit of a WiseA, but if your app didn't crash, all would be fine...

So WHY are you crashing?

Alan.raceQs over 8 years ago

Yup.. writing to mass store is expensive,

And that's why I deliberately specified "..on a periodic basis ..."

you don't want to save something that may have caused your app to crash!

I'm pretty sure I can handle that.

The fix is to stop your app from crashing. I'm being a bit of a WiseA, but if your app didn't crash, all would be fine...?

Yes, I have to agree with all three observations.

My question was, is it possible for the app to save the state data to the object store?

travis.vitek over 8 years ago

My question was, is it possible for the app to save the state data to the object store?

This functionality was previously available with AppBase.saveProperties(), but that functionality has since been deprecated.

Travis

Alan.raceQs over 8 years ago

Ah! I completely missed that. It's exactly what I want!
I don't suppose there's a release date for CIQ 3.0.0; I might have solved my crashes by then.
Thanks

jim_m_58 over 8 years ago

saveProperties() became nothing but a no-op back in mid 2015. The call doesn't do anything, but is still in the api in case any apps still calls it.

The doc isn't real clear on that and I don't see anything in the change logs for the SDK.

Search the forums for saveProperties() and you'll see references. Here's one post:

https://forums.garmin.com/showthread.php?292574-Connect-IQ-1-1-2-SDK-Available!&p=656214#post656214

Read a few more posts in the same thread. This from Kyle says it:

We only want the object store to be saved when the app exits. Since the normal use case will be on a device and in those cases the app will get shut down, I don't see saveProperties() reverting back to pre-1.1.2 functionality. This does break your particular use case, and I'm sorry for that, but you can quickly kill the widget with ctrl-k or command-k (Windows/OS X).

Alan.raceQs over 8 years ago

Good post, I was wondering why it didn't work!
Pity they removed it, I wonder what was the reason.

jim_m_58 over 8 years ago

Look at the thread I pointed to from back in June 2015 (CIQ 1.1.2).

Kyle again:

The object store is automatically saved when the app exits. It was never the intention for saveProperties() to have to be called by an app, but it had to due to a bug on the devices prior to 1.1.2.

I'm guessing, but the Object Store can be 8k, and an app could theoretically call saveProperties() VERY often for that 8k and writing to mass store is expensive.

(you may have noticed who's questions Kyle was answering back in the 1.1.2 days - it's the reason I didn't even bring up saveProperties() in this thread :) )

travis.vitek over 8 years ago

(you may have noticed who's questions Kyle was answering back in the 1.1.2 days - it's the reason I didn't even bring up saveProperties() in this thread :) )

I brought it up only to to indicate that this functionality had previously existed and is scheduled for removal as it is not a great idea.

jim_m_58 over 8 years ago

Travis... I knew what you meant with "was previously available", but I wasn't sure if RaceQ caught that. His statement about "I don't suppose there's a release date for CIQ 3.0.0; I might have solved my crashes by then." kind of tipped me off! :)

Alan.raceQs over 8 years ago

... as it is not a great idea.

I still don't understand why it's not a great idea.
OK, developers could over-use it and deliver sluggish apps, but surely (I know, "don't call me Shirley") that's up to them to decide, not Garmin. If that's the reason it has been withdrawn, isn't Garmin being a bit over-protecting... we don't really want a "nanny state" do we?

I vote for it to be reinstated, with an appropriate warning about the costs.

Or am I missing something (as usual).