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...)

Alan.raceQs over 8 years ago

Ahhh...penny dropped.
I was un-setting the 'Build release version..' checkbox, and publishing on the App store. I didn't realize that that box only worked for a side load. Another trap for the newbies.

And thanks for the update on saveProperties...maybe with new info I will be able to squash the bug and make it unnecessary.

I remember in the old days there was a limit to the number of times an EEPROM could be written to - I wonder if that was the limit that saveProperties was pushing?

jim_m_58 over 8 years ago

When you build a .iq, it's always release builds (well, you might be able to hand craft a .iq with debug builds, but that can be a pain.)

For me, I leave the box unchecked all the time, as that's how I build sideloads for testing (I build right to the device most of the time).

What you see in ciq_log.txt is like what you see for a app crash in the sim on the console (the sim always uses debug builds when driven by eclipse)

Alan.raceQs over 8 years ago

Yes, that's what I was doing as well.
In the welter of learning the new environment, I had forgotten that I had un-set the switch.
Since the checkbox is obscured in the default display of "Build for Device..." dialog (OK there's a slide bar, but that's also easily overlooked) I was blissfully unaware of the benefits.
All good learning.

Maybe a slight change to the Eclipse plugin to stop that checkbox being obscured is in order?

PS - How do you paste a screenshot into the forum post? My Ctrl-V after Alt-PrtScn doesn't do anything!

jim_m_58 over 8 years ago

raceQ - with a debug build, that alone may give you enough info in ciq_log.txt to find and fix the bug. If not, it points you to where you need Sys.println() calls to help.

It could be something as simple as a typo in the name of a var in a rarely used code path and you'll catch that fast.

Alan.raceQs over 8 years ago

Yup, I'm pretty much across the basic debugging process. I just missed that the CIQ_LOG.txt file only contained useful references if you sideload a debug build.
Thanks.

But I'm still curious about how you pasted the image into the post.

jim_m_58 over 8 years ago

But I'm still curious about how you pasted the image into the post.

It's magic that only works north of the equator! :)

Attach a photo, then use IMG tags. Here, replace the ( and ) with the brackets, and xxxxx is the ID from when you do the attach...

(IMG)(url)https://forums.garmin.com/attachment.php?attachmentid=xxxxx(/IMG)(/url)

There might be a simpler way, but it works for me!

Alan.raceQs over 8 years ago

Sounds typically Northern Hemisphere tricky!

I tried it, but it seems I'm limited to around 5kB - when I try to attach a 54Kb file it tells me I'm 48kB over my limit:mad:

I wonder if there's a forum for the Forum?