• State Not Answered
  • Replies 17 replies
  • Subscribers 17 subscribers
  • Views 1135 views
  • Users 0 members are here
Options
Related

Button Press Detect on an EDGE Data Field

DaveBrillhart
7 months ago

There isn't a way to detect the press of one of the buttons on a non-touch screen EDGE device, right? Other than the LAP and START buttons using onTimerLap and onTimerSTOP or START? At least in a data field?

Someone mentioned a CIQ Application is able to sense the other buttons to trigger application actions. But I'm not aware of a technique within a data field to do this.

"Note that on wearable products, input events are not supported for data fields." I think this applies to non-wearable products as well?

  • 0 7 months ago in reply to DaveBrillhart

    Kk for what it's worth, here's a simplified snippet of my code.

    Again, I don't really recommend this approach at all.

    datafield view class:

    https://pastebin.com/SyszCy7f

  • 0 7 months ago in reply to flowstate

    Thanks! I agree this isn't ideal. But everyone with a touchscreen loves the feature, and I want to provide a method for EDGE 5x0 devices to access it.

  • 0 7 months ago in reply to DaveBrillhart

    Consider if others read what you are doing and implement the same logic in their DFs, with a real chance a user can use multiple that do this in the same activity.  Couldn't there be a conflict?

  • 0 7 months ago in reply to DaveBrillhart

    Interesting. I wonder if this is a bug? onShow() is triggered as soon as you begin to slide the screen away from being active. This video also captures a rare screen flicker issue I see very infrequently... And since on a touchscreen at least (not sure about a 5x0 EDGE device) since onShow() is triggered and therefore the feature is activated, I need handle the watchdog timer, because say you switch away from the screen for 30 seconds... upon returning to the screen I do not want the feature to be shown....

    vimeo.com/1055231518

  • 0 7 months ago in reply to DaveBrillhart

    The watchdog gets triggered if you run a a loop too long without returning to the VM.  Ideally, you'd save the time in onHide and check the difference in onShow, but I don't think data fields call onHide.

  • 0 7 months ago in reply to jim_m_58

    Sorry - I overloaded the term watchdog. I need a timer in compute() to disable the feature if the field remains in an inactive screen. Since apparently onShow() is (erroneously?) called when swiping away from the screen. It is supposed to be called when the field arrives back to an active screen.

  • 0 7 months ago in reply to DaveBrillhart
    DaveBrillhart said:
    I need a timer in compute() to disable the feature if the field remains in an inactive screen

    The way I implement this is I have timeout logic to reset my view if the user does not return to the data field within a certain period of time. [I did not include that in my example, but I alluded to it above.]

    e.g. when onShow() is called, you check whether the last onUpdate() was more than X seconds ago, and if so, you reset datafield’s view. I guess you could do it in compute too, but there’s no need to reset the view if the user isn’t actually looking at it.

    DaveBrillhart said:
    Since apparently onShow() is (erroneously?) called when swiping away from the screen

    I alluded to this above too. Iirc, I observed it on fr955 but not on fr935.

    I don’t think it’s necessarily erroneous, but it could just be a side effect of the fact that newer watches support smooth scrolling [e.g. when scrolling through data pages)] while very old watches just abruptly go from one page to the next with no transition. The extra onShow() call(s) might just be a reflection of the fact that the data field is still rendered multiple times as the data page is smoothly scrolled away.

    Then again, fr935 also has smooth scrolling [a little slower than fr955 tho], so smooth scrolling alone can’t really explain the difference.

    This again goes back to why I don’t really recommend this approach. It’s pretty hacky and user-unfriendly

    jim_m_58 said:
    Consider if others read what you are doing and implement the same logic in their DFs, with a real chance a user can use multiple that do this in the same activity.  Couldn't there be a conflict?

    Personally I think this approach is so user-unfriendly that there’s little chance of mass adoption by devs.

    In my own data field, I have this feature disabled by default. [I think if it was enabled by default, it would be even unfriendlier.]