OLED: font resources seem to be forgotten while sleeping which leads to a crash onExitSleep

> myneur - I don't call the onExitSleep

I didn't say or even imply that you were calling it yourself. As we all should understand, the onEnterSleep/onExitSleep methods are hooks for the system to notify the application that it is changing states. The system calls these functions, and those calls should only happen at specific points in the watch face life cycle.

> _psx_ - The problem is that sometimes system doesn't call onLayout, onShow etc.... 

If you are seeing app life cycle errors (onShow called before onLayout, onLayout not getting called, onExitSleep called before onEnterSleep, any member function called before initialize), those issues should be reported. We need information on the device that produced this behavior, the firmware version, and ideally a sample app with debug output that demonstrates the problem actually occurred. A simple test app with System.println() in each life cycle should be sufficient to demonstrate the problem in most cases, and we can create that ourselves, but sometimes that is not enough.

Maybe I'm not spending enough time on the app development side, but I don't think I've seen this happen in a *long* time. It would be extremely difficult for it to happen as the app work area keeps a series of flags to indicate the app state. If the device tries to call a function before a prerequisite has been called, the prerequisite will be called automatically. i.e., if the system wants to call onUpdate, but onLayout and onShow have not been called, it will call onLayout, set the bit indicating layout has been completed, and will then call onShow and set the bit indicating the view is now visible, then will call onUpdate. Similarly, if the system wants to call onHide and the flag is not set to indicate the view is visible, View.onHide will not be called.

I'm not saying it isn't possible for something like this to happen, but we have a system in place where it should be nearly impossible. As I said above, if you are seeing cases where this is happening, we need bug reports; ideally with test apps and reproduction steps. If that is not possible, then at the very least we need to see the data that led you to your conclusion.

> _psx_ - Problem is that sometime system calls onExitSleep:
> - without the previous onEnterSleep
> - only after initialise

No class member function should ever be called before initialize, so I'm not sure what you expect with respect to the second bullet here. You simply cannot safely call any function on a class instance before you have a class instance to call it on.

As for the first item, this should not be possible. We have a flag indicating the current "power mode" of the application, and we don't allow calling onExitSleep or onEnterSleep on the app if it is already in that power mode.. i.e., app is initially in high power mode and attempts to trigger calls to onExitSleep have no effect, but calls to trigger onEnterSleep do.

Again, if you have a device details, a test app, reproduction steps, or debug data to support this, I'd love to see it.

> myneur - I consider onLayout a method to be called when a layout recalculation is needed. 

Yes

> myneur - I consider initialize the method where resources are expected to load. 

Yes-ish. Technically the system was written originally expecting that resources would be loaded in onShow and unloaded in onHide. You don't have to do it that way. If you are using a device that has a resource pool and you aren't locking resources in memory, you don't need to unload as that should happen automatically as I described previously.

> myneur - That's exactly what happens!

I think you are misreading the data. I'm almost certain if you print the value of fontSmall just before the exception occurs, you'd see that it is non-null. As I tried to describe, fontSmall is a FontReference on current devices, and the FontReference has information contained within to locate the cached FontResource data in a shared memory pool. My bet is that there is a bug somewhere in this logic and one of those internal data members are getting nulled unexpectedly.

We found an issue with bitmaps that is very similar to this about a week ago. I would not be completely surprised if there was a similar issue with fonts. We are looking at it.

> _psx_ - Your problem is probably because sometimes system doesn't call onLayout().

Pleas provide details, preferably in a separate thread.

> myneur - I don't call the onExitSleep

I didn't say or even imply that you were calling it yourself. As we all should understand, the onEnterSleep/onExitSleep methods are hooks for the system to notify the application that it is changing states. The system calls these functions, and those calls should only happen at specific points in the watch face life cycle.

> _psx_ - The problem is that sometimes system doesn't call onLayout, onShow etc.... 

If you are seeing app life cycle errors (onShow called before onLayout, onLayout not getting called, onExitSleep called before onEnterSleep, any member function called before initialize), those issues should be reported. We need information on the device that produced this behavior, the firmware version, and ideally a sample app with debug output that demonstrates the problem actually occurred. A simple test app with System.println() in each life cycle should be sufficient to demonstrate the problem in most cases, and we can create that ourselves, but sometimes that is not enough.

Maybe I'm not spending enough time on the app development side, but I don't think I've seen this happen in a *long* time. It would be extremely difficult for it to happen as the app work area keeps a series of flags to indicate the app state. If the device tries to call a function before a prerequisite has been called, the prerequisite will be called automatically. i.e., if the system wants to call onUpdate, but onLayout and onShow have not been called, it will call onLayout, set the bit indicating layout has been completed, and will then call onShow and set the bit indicating the view is now visible, then will call onUpdate. Similarly, if the system wants to call onHide and the flag is not set to indicate the view is visible, View.onHide will not be called.

I'm not saying it isn't possible for something like this to happen, but we have a system in place where it should be nearly impossible. As I said above, if you are seeing cases where this is happening, we need bug reports; ideally with test apps and reproduction steps. If that is not possible, then at the very least we need to see the data that led you to your conclusion.

> _psx_ - Problem is that sometime system calls onExitSleep:
> - without the previous onEnterSleep
> - only after initialise

No class member function should ever be called before initialize, so I'm not sure what you expect with respect to the second bullet here. You simply cannot safely call any function on a class instance before you have a class instance to call it on.

As for the first item, this should not be possible. We have a flag indicating the current "power mode" of the application, and we don't allow calling onExitSleep or onEnterSleep on the app if it is already in that power mode.. i.e., app is initially in high power mode and attempts to trigger calls to onExitSleep have no effect, but calls to trigger onEnterSleep do.

Again, if you have a device details, a test app, reproduction steps, or debug data to support this, I'd love to see it.

> myneur - I consider onLayout a method to be called when a layout recalculation is needed. 

Yes

> myneur - I consider initialize the method where resources are expected to load. 

Yes-ish. Technically the system was written originally expecting that resources would be loaded in onShow and unloaded in onHide. You don't have to do it that way. If you are using a device that has a resource pool and you aren't locking resources in memory, you don't need to unload as that should happen automatically as I described previously.

> myneur - That's exactly what happens!

I think you are misreading the data. I'm almost certain if you print the value of fontSmall just before the exception occurs, you'd see that it is non-null. As I tried to describe, fontSmall is a FontReference on current devices, and the FontReference has information contained within to locate the cached FontResource data in a shared memory pool. My bet is that there is a bug somewhere in this logic and one of those internal data members are getting nulled unexpectedly.

We found an issue with bitmaps that is very similar to this about a week ago. I would not be completely surprised if there was a similar issue with fonts. We are looking at it.

> _psx_ - Your problem is probably because sometimes system doesn't call onLayout().

Pleas provide details, preferably in a separate thread.

In this case I think it suggests it is crashing in TVM code rather than app code. There is going to be no way to catch such an exception.

t's a release build, right? What to get from it? I don't see any clue to identify the cause if there's no the stack trace from the debug mode. I don't have an OLED device to test it by myself. 

Coincidentally, there is just one Exception in ERA from 13. 2. (Epix) on this line. The line is just a var declaration:

var line;

That makes zero sense. What exception can be raised by a single declaration? 

All reported issues go through QA first before passing it on to development. We have a great number of test applications that we can either use for reproducing problems directly or modify them to cause the particular issue, but more obscure problems can require writing something from scratch.

The more information provided and especially a CIQ project that already reproduces the problem with Monkey C code that can be examined the quicker an issue can be resolved.

Dear Travis!

I've reported a lot of bugs and a few with flow. How many times should I report the same bug to be treated seriously?
Why many bugs hasn't fixed for years? So why do you surprise that the same problems appear?

I have already been taught that you cannot wait for bugs to be fixed, you should immediately look for a workaround.
So sorry I won't give you examples of bugs - it doesn't help because you have to solve the problem yourself anyway!
But as I've involved in this thread... How do I know that flow is bad sometimes? Because I guessed (not on my f6/f7 because I've never seen IQ errors on my watch) that onExitSleep is called directly after initialise and after getting rid of onLayout the problems have disappeared. Usually it happens for amoled's with AOD off - but I don't know why. Most importantly, there is no onLayout(), no bugs, no problems - but it waits for every new developer to time of fixing bug.

I added the devices to the initial report Travis.ConnectIQ – great you are on it.

There were many more devices in the ERA log, but I already deployed a hotfix so the log got cleared and now I only have a report from a watch face with quite a small user-base. From what I can recall, there were also devices like FR965 or Epixes. A huge list of devices and thousands of reports. 

The user who reported it to me (including a screenshot from his FR265) claimed, it was happening occasionally, not always, but after we started to investigate, it happened within hours. He did not have AOD on. I don't know about others, because I can't contact them.