Complete
over 4 years ago

CIQQA-34

Cannot Reproduce

App View corruption on Session.save() and on Notifications

I'm currently testing with a Forerunner 245 Music.

I have a menu item in my app to stop recording.

The code calls session.stop(), then session.save() then sets the variable sesssion = null

Works as expected on a VA-HR, and on the simulator.

On the actual Forerunner 245, the menu that was presented to stop recording leaves the underlying view's display corrupted.

While chasing this separated the menu selection and the actual session calls in time, so the menu can be correctly removed and the underlying View can be restored correctly.

That works as long as I move the session.stop() code to the delayed code along with session.save() and session = null.

That looks like a bug in the underlying menu management code in the Forerunner 245 that is supposed to pop the menu and restore the previous view's display.

Notifications like GPS status or "Complete"  that appear on the top of the screen while the app is running also leave the display corrupted.

Jeff
  • over 4 years ago in reply to jim_m_58

    From the API doc for onUpdate:

    "This is called when a View is brought to the foreground, after the call to onShow(). While a View is active, this method is generally used to update dynamic content in the View."

    It's the "While a View is active..." part that lead me to believe that clearing the view and redrawing everything on every call to onUpdate() is not intended and not desirable.

    While my view is active the watch sometimes shows alert messages. I got those alerts when your messages were posted. My app was running on the watch at that time and those alerts left the screen corrupted. To me, when an alert is displayed or when a menu is displayed, my view is no longer in the foreground, meaning that onShow() should occur again to indicate to my app that the screen was taken over and I need to redraw everything. 

    I can clear the view and redraw everything once a second but that seems like a battery waster as well as contradicting the description of onUpdate().

    It seems to me that that's a bug in Garmin's code since "While a View is active, this method is generally used to update dynamic content" isn't a true statement if onUpdate() must start from scratch on every call.

  • over 4 years ago in reply to Jeff

    Never seen that's the intent of onShow stated anywhere.  In WFs you can start/stop timers, in DF's onShow is only called once in most cases, even though the content of the DF is cleared, etc.

  • over 4 years ago in reply to jim_m_58

    Isn't that expensive in terms of processing and associated battery usage ??

    I thought that was the purpose for onShow() being a part of the sequence for showing a view.

  • over 4 years ago in reply to Jeff

    Always update the whole screen in onUpdate.  Trying to use onShow isn't consistent, as you see.

  • over 4 years ago in reply to jim_m_58

    Hi Jim,

    Yes I call Ui.requestUpdate() once a second.

    The main view's onUpdate() redraws the entire view if onShow() was called before onUpdate(), but only updates dynamic fields after that.

    When the corruption occurs the dynamic fields are being updated but the background from the Alert or from the Menu remains as if onShow() wasn't called.