Exception when calling pushView from datafield's settings view

Thrown if called from background, data field...

Instead pushView use getSettingsView() to return settingsFieldMenu

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.

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.

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 

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.

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

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

_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_ 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