• Replies 40 replies
  • Subscribers 19 subscribers
  • Views 5485 views
  • Users 0 members are here
Options
Related

How do I know if onStop,onStart is suspend/resume or start/stop in my datafield?

flocsy🤠
over 2 years ago

In my DF i need to be able to differentiate between starting "from scratch" (then the DF needs to connect to the nearest ANT HR device using ANT ID: 0) and when I am "saving for later" and then "resuming" the activity (then the DF needs to connect to the same ANT ID it was connected before resuming, so instead of 0 I need to use the actual ANT ID).

I thought that in both onStop and onStart I will know if the scenario is "full start / full stop" by having state as null, and the "suspend / resume" by having something else in state. But unfortunately it seems I haven't understand the documentation because in both cases state is null.

Now my problem is that because I can't differentiate between the two onStop-s, currently even if I finished the activity I save the ANT ID, which causes the next onStart (even if it's a totally new activity) load the ANT ID, and instead of connecting the nearest ANT device it only wants to connect to the same device I used last time.

Is there a way (or trick) to differentiate?

  • over 2 years ago

    Can't you just save the ANT Id in Application.Storage/Application.Properties when you find one, and then just use that if the data field is used 5 minutes or 5 days later?

    Maybe provide a setting to reset the ANT ID if needed?

    Consider the case where you are at the start line for something like a 5k.  There could be a number of External HRMs close by and you don't want to just connect one at random.  You want to connect to a "known"

  • over 2 years ago

    If it makes you feel better, even a Garmin app like Lap Running Power doesn't handle Resume Later properly. When you select Resume Later and resume the activity, the data field acts like you started from scratch (e.g. lap information is not saved and restored.)

    In fact I don't know of any CIQ data field which handles Resume Later properly (in the case where the field tracks activity or lap data.)

    flocsy🤠 said:
    But unfortunately it seems I haven't understand the documentation because in both cases state is null.

    Sounds like a bug to me tbh - either the documentation is wrong or the implementation is wrong.

    developer.garmin.com/.../AppBase.html

    onStart(state as Lang.Dictionary or Null) as Void

    Method called at startup to allow handling of app initialization.

    Before the initial WatchUi.View is retrieved, onStart() is called. Application level settings can be initialized or retrieved from the object store before the initial View is created. This method must be overridden to handle your own app initialization.

    Note:

    the suspension state can be cleared in the event of reboot or app update.

    Parameters:

    • state — (Lang.Dictionary) —

      Required. If an Intent is not used to launch the application, then an empty "state" Dictionary is used. If an Intent is used to start the application the Dictionary contains the arguments from the Intent.

      • :resume — (Lang.Boolean) —

        If true, indicating app has been resumed from suspension, restore the previously saved app state if needed.

    EDIT: actually it seems that :resume is all about suspended super apps, and has nothing to do with "Resume Later" for data fields.

  • over 2 years ago in reply to FlowState

    I have wondered several times what does this mean :suspend /:resume. Does it apply to all types of applications or just the date filed? It is understandable in case of DF but other types?

  • over 2 years ago in reply to _psx_

    Hmmm perhaps suspend/resume has nothing to do with "Resume Later", but is in fact all about super apps.

    https://developer.garmin.com/connect-iq/core-topics/application-and-system-modules/

  • over 2 years ago

    Also, since this is a data field, can't you just call Activity.getActivityInfo() and check whether timerTime or elapsedTime is non-zero at the start?

    EDIT: I upvoted my own post for visibility, since this isn't the type of post where I can "suggest as answer", and the thread has gotten pretty long.

  • over 2 years ago in reply to FlowState

    Well, I read this doc before they released 4.0 so it wasn't :) And there are effects when documentation in many places. This piece should be simple added to:

    developer.garmin.com/.../AppBase.html

  • over 2 years ago in reply to _psx_

    Yeah the documentation is not great. They should really clarify / link to what "suspension" means in that context.

    _psx_ said:
    And there are effects when documentation in many places.

    Yeah, Don't Repeat Yourself is a rule that everyone breaks, and it causes problems every time.

  • over 2 years ago in reply to FlowState

    And it means state is only for new type of apps named superapp (there is no such type in eclipse). And this superapp has the same like in older one, view and glance.
    I don't have 4.0 watch. I do not understand what does it mean? No separate view for widgets? Everything is mixed in one place applications / widgets / activities?

  • over 2 years ago in reply to _psx_
    _psx_ said:
    And it means state is only for new type of apps named superapp (there is no such type in eclipse). And this superapp has the same like in older one, view and glance.
    I don't have 4.0 watch. I do not understand what does it mean? No separate view for widgets? Everything is mixed in one place applications / widgets / activities?

    It's just a CIQ thing which means that there's no more CIQ widget app type for CIQ 4 devices. Basically, one super app can provide both "device app" and "widget" functionality. The device app part is mandatory, and the widget part is optional.

    In the UI, widgets and apps still exist; widgets still go in the "glance list / widget carousel" (accessed by pressing UP/DOWN from the watch face), and apps still go in the activity list (accessed by pressing START from the watch face).

    However, it's now a single CIQ app which provides both kinds of functionality. By default, a device app goes in the activity list (just like before). If you *also* want the app to go in the widget list, you provide a glance view.

    Notes:

    - I don't think "super app" is supposed to literally be a separate type. If you create a device app for a CIQ 4 devices, it's automatically a "super app". You just have the option to provide a glance view and it also becomes a "glance/widget."

    - in the UI for newer devices, widgets are exclusively referred to as "glances" now

    - if you launch a CIQ super app from the glance list, it will still time out after a certain period of inactivity, just like widgets in the past

    - for CIQ super apps, every CIQ glance will also be in the activity list, but not vice versa. I don't think there's any way to have a CIQ 4 app that's in the glance list, but not the app/activity list.

    - native glances are *not* also in the activity list (as far as I know), so this highlights how this is really just a CIQ thing (IMO)

    EDIT: based on what Jim posted, it seems that either a device app or a widget can be a super app in CIQ 4.

  • over 2 years ago in reply to FlowState

    If you take a widget with a glance and build it for a CIQ 4.x device, it because a "Super App" - A device app with a glance.

    Widgets are not supported on CIQ 4 devices, and if you build one for a CIQ 3 device and sideload it to a CIQ 4 device, it won't run and you'll see a message in the CIQ Log file.

    If you take a widget type app, build it for a CIQ 4 device, it will show in both the glance loop as well as the list of activities, (no glance there) because it's really a device app..