More Basic Watch App Mysteries

My starting point is as before.... create a basic watch app in Eclipse, using the wizards.
I don't change anything.
I build the app.... with the timeout change, the build now succeeds.
I run the app in the simulator on the Vivoactive HR simulation.
The app that is created presents a graphic of a monkey.
When I hold down the right button a 2 item menu is presented.
If I select Item 1, a message appears in the debug log window indicating that Item 1 was selected.
If I select Item 2, no message appears, though the code indicates that it should.
Instead, the menu shifts up, centering the Item 2 menu item text.

I see no code in the example that causes this behavior
The documentation for the Menu support in the UI does not describe this behavior, or how to control it, though it shows exactly the code that I'm seeing in the project that was created.

I also attempted to use the debugger to follow the code and see what's going on.
The onMenuItem() function is not entered when I select Item 2.

So.... what's happening here, and is it possible to create a menu that does not behave in this way ?
The API documentation for menu, and menuInputDelegate do not describe this behavior.
Is there documentation that describes what to expect from the underlying menu handler ?
I see a parameter called ui.SLIDE_UP that looks suspicious, but it is passed to pushView() so I suspect (though the documentation does not verify) that this applies to how the view is presented over the previous view.


Also....
The debugger does hit the break point that I set inside onMenuItem(), but once the break point is hit, and I attempt to get the code to continue to run, the app in the simulation no longer responds to any button or menu selection.

I hope there's a way to use the debugger to hit a break point, walk through the code, and continue to run until another break point is hit.
  • I think you need to spend some time looking at the programmer's guide in the SDK as well as the UX guide, and the API docs. Using the debugger is a bit advanced for you right now in my opinion, (you are just starting out) You need to understand the basics first, and see how the app works. See how things run in the sim and on a watch, with no debugger involved.

    The monkey is "Alpha Monkey" BTW... The creator of "Monkey C" Yes, is is a real person!
  • Thanks Jim,
    I really appreciate your quick responses.

    With respect to the debugger, and to give you a frame of reference about me.... I've got many years of experience with programming, leading programming teams (director of software development at one company), putting highly reliable systems into the field, and have worked with a number of IDEs developer for embedded systems, as well as for code development for windows, so the ideas behind an IDE or a debugger are not new to me, nor is coding in general or hunting for details about how an API works in the documentation provided.

    The documentation I've found so far is:
    the Online Programmer's Guide: https://developer.garmin.com/connect-iq/programmers-guide/
    the online API docs: https://developer.garmin.com/connect-iq/api-docs/

    and the corresponding Programmer's Guuide and API docks that are available through the ConnectIQ menu item on Eclipse, which were apparently loaded on my machine when I installed the tools, and which look to be very similar if not the same as the online versions.

    You mention a "UX guide"....
    Can you tell me what you are referring to, and where I can find it ?
    Are you referring to the User Interface guide that's part of the online documentation ? ... https://developer.garmin.com/connect-iq/programmers-guide/user-interface/

    In an effort to hunt down this mystery about the operation of the menu in the sample code, I searched the API documentation for the functions involved, the parameters involved, the Toybox::WatchUi documentation and Menu related entries..... I see no answer to my question.

    So... If you have the answer, or can direct me to documentation that describes the behavior I'm seeing, where it is implemented, and how it can be overridden, please point me at that documentation. My concern here is only partly about this particular behavior.

    A mystery like this is not a good indication about what I can expect from these tools, and this documentation.
    What else, that is more important, and more deeply hidden, will I end up running into during my development, that I will not be able to get answers for ?
    What other underlying behavior of the platform is either poorly documented, or not documented at all ?
    So... please point me at the documentation that I've apparently missed.

    Thanks
    Jeff

  • All the docs are actually in the SDK's directory structure, with the UX and programmer's guide at the top level (along with a readme that explains the sample). The API doc is in the doc directory. I tend to go with the docs in the SDK vs the website. When a new SDK comes out the website might not be updated for a day or two, etc.

    Sorry, I missed this yesterday
    Oh, one thing about the menus in the sim. It's a "generic" menu, and doesn't often work like on the devices. So for the va-hr in the sim in the sim, your "selection" is in the middle of the screen, and if you tap below that, it just scrolls the menu.up. You move what you want to the center and then click on that.

    I've been doing CIQ for a few years, and there are some tricks (like the way menus work in the sim), but not many. Been coding myself for many years and part of what I mentioned about the debugger, is it's still a bit green in some areas (it first came out in April with 2.3.0). And like with the menu, there is a bit of a learning curve for the basics and the environment. Don't know if you're been doing sideloads, but there's running/debugging on the real device, and then app settings too.

    And there are plenty of people here to help! (including the folks from Garmin!)
  • Thanks Jim,
    I have scanned the User Experience guide, and found it in the SDK file structure.
    Thanks for that pointer.

    The documentation for Class: Toybox::WatchUi::Menu includes a note at the top of the page that says
    Note: The look and feel of a menu is device-specific.

    I've tried searching for descriptions of device-specific behavior and don't see that described.
    Do you know of documentation that provides an explanation of device-specific behavior of the underlying code, for each device ?

    I turned to the debugger because my prior experience has been that debuggers will let me chase down things quite quickly, sometimes allowing me to walk into the underlying code to see what's going on.
    Thanks for the warning about this debugger being a bit green.


    And... I haven't tried side-loading yet, but will shortly.
    You mention debugging via sideloads.... does the debugger allow stepping through code on a side loaded app, or is the debugging simply about running the code on the target and possibly logging debug lines to a text file ?

    Jeff
  • I don't think the way menus look on each device is documented anywhere, as it's the same calls for any device, and the CIQ menu itself looks pretty much like the native menu on that device. Try a simple sideload with what you testing and you can see how the menu looks and acts on the va-hr.
  • Hi Jeff.
    I too have come to Connect IQ from a solid background of software development and totally empathize with your well disguised frustration.
    The bottom line is that whilst the development environment is very new and inadequately documented, the platform is surprisingly powerful and flexible.
    It's taken me nine months to "crack the code", relying heavily on experimenting with the samples in the SDK to explore the subtleties and nuances of the language and the SDK.
    And yes, the menu is an odd beastie that looks quite different on the watch to the simulator.
  • Former Member
    Former Member
    Hey Jeff,

    Sorry about some of the difficulties. The documentation is definitely one of our biggest works in progress. We've revamped the API docs from where they were so that they are much easier to navigate and provide more robust examples than before (ask jim_m_58 about how far they have come). Our next big focus is our Programmer's Guide. We don't want to hide any of the "quirks" that may come up in working with Connect IQ and want to make it as easy as we can to work with the SDK.

    Regarding the menu system, you rightly note that the Sim does have a very generic menu right now. Currently Menus create a custom version of the native menus on the device. You can assign text, behaviors, etc to each of the items in your custom menus, but every menu will be an implementation of the native menus for each device. One of the major goals of CIQ is to create a user experience that is portable across many devices. With vastly different UI elements on our many platforms, this is what made the most sense. Users will hopefully intuitively know how the menu works because they are used to all menus working this way on the device. This should lift the burden off of the developer's shoulders when it comes to the Ui. You need only decide what each menu item is intended to present and what it does when selected. The virtual machine will take care of the rest.

    This is a pretty general philosophy that we take on a lot of things. For example, our Pickers will look a little different on different devices. We work with device teams to make sure that they will do what you need while giving you access to something that looks native for each device. For some elements like these (where you have little to no control over the Ui) the sim will generally use a generic version. This gives you the behavior, but not necessarily the look.

    I hope this clears up some of the confusion and helps explain some of the "why" behind the ways that some things are done. In saying all of that, we definitely have room for growth and know that there will be bugs to squash in our environment. If something seems off, feel totally free to speak up. We appreciate it.

    Thanks,
    -Coleman & The Connect IQ Team

    P.S.

    Welcome to Connect IQ!
  • To RaceQs.... Thanks for the sanity check concerning the learning curve.
    That helps to set my expectations for making progress.
  • To Coleman.ConnectIQ...
    Thanks for chiming in.
    I do understand the philosophy when you're trying to help developers to write code once, which behaves in sensible ways on a variety of devices.
    That said, I can't for the life of me understand why someone would want a menu to behave the way the one on the ViviactiveHR does when running the generic code that I referred to.
    As a user, if I can see a menu item and I touch it, I expect that the device will act as if I've selected that item.
    Given the behavior I'll be looking for alternatives to using menus at all.


  • This is one of the top reviews in my App. "I cannot select ...". All of them are Vivoactive HR users, because you have to center the menu-entry first, to select it.
    They think my menu is not working properly, but it is "by design" ;)

    Being a professional developer makes understanding monkey c and its philosophy just harder :p
    But I don't want to extravagate :rolleyes: