Unexpected Type Error with CIQ 3.3

Not to state the obvious, but it sounds like the device doesn't like what's being returned from getInitialView()?

Is it your openhab app? Is it a version of the code which isn't on github.

If I run the current code for openhab on edge830 in the sim, I get a different, straightforward error on startup:

Error: Array Out Of Bounds Error
Details: Failed invoking <symbol>
Stack:
  - getCurrentView() at .../openhab-garmin/source/user-interface/view-handling/ViewHandler.mc:32 0x1000a2a3
  - <globals/ErrorView/<statics>/<>get>() at .../openhab-garmin/source/user-interface/error-handling/ErrorView.mc:40 0x10008143
  - createOrUpdate() at .../openhab-garmin/source/user-interface/error-handling/ErrorView.mc:26 0x100080f8
  - getInitialView() at .../openhab-garmin/source/OHApp.mc:78 0x1000a694

It's straightforward if you look at the code referenced in the stack trace.

After making a few changes it runs for me.

So I assume that either:

- you're testing with different code

or

- you're running on a real edge830 (which I don't have access to)

flowstate said:

Is it your openhab app? Is it a version of the code which isn't on github.

If I run the current code for openhab on edge830 in the sim, I get a different, straightforward error on startup:

Yes, that’s the app, thanks for testing it. I had committed the changes around the time you wrote, so you were probably working with an older version of the code.

The error I mentioned only appears when connecting to a real server, so you won’t be able to reproduce it locally. Without a server, the error view is shown instead, and that part seems to work fine.

The issue occurs when I return a CustomMenu implementation in getInitialView.

I’ve also managed to reproduce another error: if I first return a “normal” View in getInitialView and then switch to the CustomMenu on CIQ 3.3, I get:

Exception: Base view is not allowed to switch to native view for widgets 

Oh I see.

Exception: Base view is not allowed to switch to native view for widgets 

There's actually a very good reason for this. At least on a watch, the initial view for a literal full-screen widget (not a glance) cannot accept any input other either than onSelect() / KEY_ENTER.

The reason is that the "widget loop" (carousel of full-screen widgets that you navigate by pressing UP/DOWN from the watch face) is comprised of all the initial views of each widget (native or CIQ). As you scroll to the next/previous widget, if the widget is a CIQ app, the app is loaded and its initial view is displayed [*]. This initial view cannot take any other input because the only things you can do from here are:

- "open the widget" (onSelect() / KEY_ENTER)

- go the next/previous widget (by pressing KEY_UP/KEY_DOWN or using the touchscreen to scroll)

As you can imagine, a menu wouldn't work here because the it would need to handle KEY_UP/KEY_DOWN and swipe up/swipe down, and that would conflict with widget scrolling. If the menu would take precedence, you would no longer be able to scroll widgets. If scrolling widgets were to take precedence, then the menu would be useless.

This is also the reason that you're not allowed to programmatically exit or pop the initial view on a real CIQ widget (not glance) - both those things will result in a crash. By the logic of the device firmware, there's nowhere for the watch to pop "to". The only way for the user to cleanly exit a widget is for them to press BACK (swipe right) on the initial view, and for the initial view to *not* prevent the default onBack() action from happening - onBack() must not return true.

Ofc by the logic of us devs, the firmware could just return us to the watchface, same as if the user pressed BACK on any full-screen widget's top-level view (native or CIQ), but hey, they didn't ask us.

[*] This is obviously quite inefficient, which is why CIQ widgets would briefly display a screen with their name and launcher icon while they were (automatically) being loaded on scroll. The glance system is obviously much better, where the CIQ glance view runs in a smaller/leaner "process" that can be loaded much faster.

the-ninth said:

The error I mentioned only appears when connecting to a real server, so you won’t be able to reproduce it locally.

Does your server ever return anything other than a JSON object? `{ ... }`

Numbers, booleans, arrays, strings, and null are all valid JSON, but makeWebRequest won't accept them (when the response type is json). When the response type is json, makeWebRequest wants the top level of the response to be an object, presumably so it can consistently return a Monkey C Dictionary.

I don't like that design, but hey, they didn't ask me. 

flowstate said:

The reason is that the "widget loop" (carousel of full-screen widgets that you navigate by pressing UP/DOWN from the watch face) is comprised of all the initial views of each widget (native or CIQ). As you scroll to the next/previous widget, if the widget is a CIQ app, the app is loaded and its initial view is displayed [*]. This initial view cannot take any other input because the only things you can do from here are:

Thanks, understood. Actually my other app (evcc) does support older watches, and I do have a special glance-like first view there.
Do you by any chance know how this works on the Edge devices? Is there also something like a widget carousel there?

flowstate said:

Does your server ever return anything other than a JSON object? `{ ... }`

There are some error cases where due to a bug in the server it returns a 200 code but an empty response. This is reported as error by the API. But by and large it is always JSON.

I'm not quite sure if I ran into the same issue as you. I use a Menu2 as initial view and tried to launch it on a GPSMap device and it threw the same error you encountered, although it supports Menu2.
I ended up doing this: