• State Suggested Answer
  • +2 person also asked this people also asked this
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 25 subscribers
  • Views 2373 views
  • Users 0 members are here
Options
Related

How to cancel onBack

RoLynx
over 5 years ago

Hello,

Not sure if this is a bug and I haven't checked yet for other view types.

For ProgressBar, I pass a delegate that returns true on the onBack function, but when I press the back button, the view is poped from the stack.

I used the code provided on the docs: https://developer.garmin.com/connect-iq/

What am I missing?

PS: I tried on both simulator and real device.

Thank you!

  • 0 over 5 years ago

    The progress bar sample in the SDK works the same way.  I'm not sure why to wouldn't want on_back to pop the view, as you wouldn't want to get stuck on that view if progress stopped changing.

  • 0 over 5 years ago

    You aren't missing anything. Pressing the back button while at a progress bar page dismisses/cancels the progress bar unconditionally.

  • 0 over 3 years ago

    Hehe... shortest thread I bumped into, describing why CIQ platform is not usable for sustainable development in general. For real devs, this not need explanation. 

  • 0 over 3 years ago in reply to Jan Čapek

    Yeah, I will say there are some frustrating edge cases/limitations in CIQ.

    Like the fact that you can't programmatically pop the initial view of a widget. Which is fine for older non-glance widgets, but I have a stopwatch widget which is actually less user-friendly in glance mode, because the user has to press Back twice to exit "full mode" (with full user interaction) for glance watches instead of just once for non-glance watches. Because without glances, the "full view" of the widget is the 2nd view, whereas with glances, it's the 1st view, and for reasons I don't want to go into, I have to add that extra top-level view to the glance mode widget, in order for it to work as closely as possible to the non-glance mode widget.

    Glances are a nice feature, but that one aspect seems like a step backwards, as it requires the user to press more buttons to do the same thing, in certain rare edge cases.

    I mean I get that a lot of these design/technical limitations have underlying reasons, but there seem to be so many of them.

  • 0 over 3 years ago in reply to FlowState

    The real issue there is inability of CIQ team to determine whether something is feature or bug and actually DO something about it. You are correct, there are hundreds of similar "issues" across whole platform so nobody bother anymore to report all of them, even when they usually break developer neck while he is trying to implement something. 

  • 0 over 3 years ago in reply to Jan Čapek

    When you find something you think is a bug, be sure to do a bug report, as the Garmin folks might not see it if it's just a post in discussion.  And when you do a bug report, be sure to include what's needed in a bug report (see https://forums.garmin.com/developer/connect-iq/w/wiki/5/bug-reports-faq).

    A way to reproduce it (sample code), and things like the SDK version and target device are really important.

  • 0 over 3 years ago in reply to Jan Čapek

    Well, I don't see the same thing you are.  Maybe it's just I've been doing this for a long time and know what should work and what doesn't work (it's not always a bug but could be a limitation).

    If you find something you think is a bug, do a bug report.  Don't just post in discussion.

  • 0 over 3 years ago in reply to jim_m_58

    Why, when you don't fix any bugs at all? 
    I did it in past, but it's wasting of energy. Nothing was fixed. Gave up. 
    – Watch locating for weather forerecast does not work often. 
    – MakeWebrequest does not work on some devices
    – On some devices, the display drawing does not persist while on other it persists
    – Different behavior of FR45 and other watches in simulator
    – Simulator crashes on Mac OS after every Background.exit
    And many other bugs here on the forum. 
    There's nothing that is more meaningless than reporting bugs to one who does not solve any and who does not care about quality of his work. 

  • 0 over 3 years ago in reply to myneur

    I don't work for Garmin so I don't fix any bugs!  Just report them.

    How many of those have you reported?  Some of those things probably aren't bugs.  The fr45 for example is a CIQ 1 device, with only 8 colors, and doesn't support things like 1hz or a background process, and has a max of 48k.  I'd expect it to be different that other devices.

    I've not seen an issue with makeWebRequest on different devices (I support things that use it back to the original va), but that could be based on things like the size of the response vs size allowed for a background service.