Exception when calling pushView from datafield's settings view

I got this error in ERA:

Error Name: Unhandled Exception
Occurrences: 1
First Occurrence: 2024-07-25
Last Occurrence: 2024-07-25
Devices:
    GPSMAP® 67 / 67i: 8.50
App Versions: 1.2
Languages: eng
Backtrace:
    UnitConverterDFSettingsMenuDelegate.onSelect:37

This is my Menu2InputDelegate. According to the documentation AppBase.getSettingsView is since api 3.2.0 and is supported by GPSMAP67.
The line in onSelect:37 is this:

WatchUi.pushView(settingsFieldMenu, self, WatchUi.SLIDE_RIGHT);

According to the documentation (which is IMHO misleading or wrong) pushView:

Throws:

(Lang.UnexpectedTypeException) —

Thrown when view is type MapView and the visible map area parameters are invalid
(Lang.OperationNotAllowedException) —

Thrown if called from background, data field, glance, or watch face app; or if the new view is a DataField, a GlanceView, or a WatchFace

I don't have MapView in my app, so it's not the 1st one I guess, and my "app" is indeed a DataField (where it works in numerous devices, so IMHO the 1st part of the sentence is wrong), but I call this from the settings view (which extends Rez.Menus.SettingsMainMenu). And again it works on devices I have access to.

Any idea what happens here?

_psx_ 4 months ago

Thrown if called from background, data field...

Instead pushView use getSettingsView() to return settingsFieldMenu

flocsy🤠 4 months ago in reply to _psx_

That's why I wrote: "indeed [it's] a DataField (where it works in numerous devices [i.e just tested in fr965], so IMHO the 1st part of the sentence is wrong), but I call this from the settings view"

The main point here is that it does work "from" datafield (type apps) when it's not from the main view but from the settingsview.

_psx_ 4 months ago in reply to flocsy🤠

I understand doc in this way: if you call pushView from CIQ code - exception, if you return view from getSettingsView and system shows view (system calls pushView) no exception.

flocsy🤠 4 months ago in reply to _psx_

But I just wrote 2 times that it does work! Either it doesn't work for the specific device (could be, because it's not the most common device, it's GPSMAP67, so not lot of users have it, probably even less who try to use the on-device datafield setting on it)

BTW on one hand it is compiled with the code, on the other hand with the simulator I can't even trigger the settings menu on this device.

So either it's a bug in the sim (if real device has settings) or the sim is "correct" that this device isn't supposed to be able to trigger the settings (in which case it's a bug in the real firmware) Plus of course the documentation is buggy, 'cause it doesn't reflect the reality

_psx_ 4 months ago in reply to flocsy🤠

If I read in doc "don't use .... because of exception" I don't use it especially I can simple use something what was prepared for it.

So, there is somewhere a bug (doc, firmware) but you can simple use getSettingsView but only from 3.2.0.

In my wf/df I use getSettingsView and probably for devices below 3.2.0 user can't use settings on device.

FlowState 4 months ago in reply to flocsy🤠

I think both of you are reading far too much into the docs. It’s clearly an error of omission that the docs don’t mention what would happen for the *settings view* of a data field or watch face, which is clearly a special case. Because it’s a special case, I don’t think the docs imply (by omission) that a data field or watch face’s settings view is not allowed to push a view, unless you take a very literal view of the docs (that they are exhaustive and free from errors/omissions.) We’ve all dealt with Garmin docs for years, so we should be used to this kind of thing. There’s a lot of stuff that you’re expected to figure out on your own, unfortunately.

It’s really easy to see how this could’ve happened:

- docs for pushView were originally written long before getSettingsView() ever existed

- docs were updated for the MapView case. It would be hard to miss this since a new exception (for this function) was added for this case

- docs weren’t updated for settings views, as there would be no new exception to be documented, only a note to be added to the OperationNotAllowedException blurb saying “this doesn’t apply to the settings view of a data field or watch face”

Common sense would dictate that there’s no good reason to prevent a data field or watch face’s *settings view* from pushing another view (and that’s what flocsy has seen in practice.) Here’s a couple of reasons why:

- it would be a very lame settings view indeed which had no ability to push (or switch to) another view. If that were the case, you would be limited to a single top-level view which would have to handle all of its state changes manually. e.g. When the user selects a menu item that would normally open another menu by pushing or switching views, instead the sole top-level settings view would have re-render itself to display the new menu. Garmin would have no reason to punish devs (and users) this way

- there is a very obvious reason why data fields and watch faces aren’t allowed to push a view - it’s the same reason they have limited / non-existent support for user input. Neither of them are supposed to be fully-fledged apps (i.e. device apps), they’re meant to occupy a limited role in the user interface. A watch face is just that - nothing more than a single screen which displays the time. Data fields exist in the larger context of an activity, which has its own set of screens and menus, and allowing a CIQ data field to push (or switch) a view doesn’t fit that paradigm. None of that applies to a settings view, which is why the restriction wouldn’t make a sense for a settings view

Having said all of that:

- this sounds like a bug in the GPSMAP67 (sim or real device) no matter what. If it’s the case that the sim can’t trigger on-device settings for GPSMAP67, then it sounds like they accidentally left some shared code in the real device which allows on-device settings to be launched, but full support isn’t there. Or maybe support is supposed to be there, in which case both the sim and device are buggy.

Whatever the case may be, I would report this

- this is also a bug in the docs. Garmin should explicitly address the case of the settings view. (Either they forgot or didn’t bother.) I would also report this

FlowState 4 months ago in reply to _psx_

_psx_ said:
In my wf/df I use getSettingsView and probably for devices below 3.2.0 user can't use settings on device.

Clearly the real GPSMAP67 at least has partial support for on-device settings, because:

- getSettingsView() had to be called in the first place (which could only be triggered by user action)

- onSelect() of flocsy’s settings view had to be called in order to trigger the exception, which means the settings view was displayed and the user was able to provide the input that triggers onSelect() (e.g. scrolling to a menu item and selecting.)

FlowState 4 months ago in reply to _psx_

_psx_ said:
probably for devices below 3.2.0 user can't use settings on device.

Not probably, but definitely. If there’s one thing we can all agree on, that’s it.

However, gpsmap67 is at CIQ API level 3.2.0 / 3.2.8 according to the device library. Any app that was built with that device definition wouldn’t even install on a gpsmap67 with a lower CIQ API level.

_psx_ 4 months ago

I've just realised that Era error is in the delegate returned from getSettingsView(). So it means that views returned from getSettingsView don't belong to CIQ app and they can use pushView (as some devices can run without exception) sob bug is in GPSMAP and doc.

FlowState 4 months ago in reply to _psx_

_psx_ said:
I've just realised that Era error is in the delegate returned from getSettingsView(). So it means that views returned from getSettingsView don't belong to CIQ app and they can use pushView (as some devices can run without exception) sob bug is in GPSMAP and doc.

That's what flocsy said multiple times above