• State Not Answered
  • Replies 24 replies
  • Subscribers 20 subscribers
  • Views 366 views
  • Users 0 members are here
Options
Related

Layer not rendering when added to a View

the-ninth

Hi,

I’d like to use a layer to display a visual indicator in my app. The indicator should be a circle along the edge of the screen in a specific color, or a rectangle, depending on the screen shape. I want this indicator to appear not only on my own View implementations, but also on top of CustomMenu implementations, which is why I’m trying to use a layer.

I tried following the example in the documentation (https://developer.garmin.com/connect-iq/core-topics/user-interface/), but my layer never shows up.

Since posting code here often fails, I’m linking directly to the relevant files.

Layer implementation:
https://github.com/openhab/openhab-garmin/blob/main/source/connectivity/WifiIndicatorLayer.mc

I’ve confirmed the constructor code runs. A Dc is returned and drawing calls execute.

For testing, I added the layer to one of my views in the view constructor:
https://github.com/openhab/openhab-garmin/blob/main/source/user-interface/loading-views/WifiCheckView.mc

Is there anything else I need to do to get the layer to display?

Also, is my understanding correct that the layer is drawn on top of the view’s base Dc?

  • 0 in reply to flowstate
    flowstate said:
    I guess this means that Garmin shows a full-screen wi-fi sync status page, like what you see with Spotify.

    Exactly. In fact, there are two screens. The first one shows a progress bar. Your code can report the sync progress as a percentage, and this is reflected there. At the end, a second screen is shown that indicates success or any error reported by your sync code.

    In the simulator, this final view has to be confirmed using the back button. On my Epix Pro Gen 2, the back button can also be used, but the view disappears automatically after a few seconds as well. In any case, this is not something that runs in the background while the user continues using the app.

    From the perspective of my use case, a permanent Wi-Fi connection would of course be an advantage. I am not entirely sure whether I fully understand the distinction, but there seems to be a difference between an app started as a full app, similar to an activity, and one started in widget mode, which nowadays means from the glance carousel. In the latter case, the app is automatically terminated after a certain time without user interaction. In that scenario, a permanent Wi-Fi connection may be considered acceptable, but i guess the use case is to rare for Garmin to do anything about it. 

  • 0 in reply to the-ninth

    I guess it's all there in the use of the word "sync", right? Garmin only wants CIQ apps to use Wi-Fi for long-running, but relatively infrequent, content sync activities. 

    I think that, originally, wi-fi sync was only available for music providers (CIQ 3.0.0), and the relevant class was Media.SyncDelegate, which is now deprecated.

    In CIQ 3.1.0, the generic Communications.SyncDelegate class was added (I assume this is because Garmin wanted to allow non-music apps to use wi-fi sync), but it doesn't change the fact that Garmin probably just wants us to use this stuff for infrequent syncs of possibly large amounts of content.

    (The docs for Media.SyncDelegate refer to syncing "audio", while the docs for the newer Communications.SyncDelegate refer to syncing "content".)

    I don't think it was ever intended to be used in the same way as makeWebRequest over BLE (general purpose communication).

    I also seem to recall talk in the forums that a regular makeWebRequest would automatically use Wi-Fi assuming the device was already in "wi-fi mode" (e.g. say it recently performed a native sync over wi-fi), but there was no way for CIQ apps to force wi-fi to be turned on in this case. CIQ apps could only implicitly use an existing wi-fi connection. This was before the wifi sync delegate class even existed, I think. So this behaviour is probably still around, but it still doesn't help you because it will only apply in the rare times that wi-fi had already been activated by some other means.

  • 0 in reply to flowstate
    flowstate said:
    I also seem to recall talk in the forums that a regular makeWebRequest would automatically use Wi-Fi assuming the device was already in "wi-fi mode" (e.g. say it recently performed a native sync over wi-fi)

    Yes, I observed that as well. If my polling timer triggers immediately after a sync, it may still succeed, even though the sync has already ended. Therefore, when determining whether BLE is available, I also needed to take connectionInfo into account.

    However, the time during which the connection remains open is only one or two seconds.

  • 0 in reply to the-ninth

    WiFi also has a much larger impact on the battery than BLE, and establishing a wifi connection takes more time than just using BLE.

    With some devices, using wifi to download music required that the Garmin be connected to a charger so the battery didn't die while the sync was in progress.

    On at least some edge devices, when you first turn them on and before you start an activity, it starts up wifi for things like downloading FW, syncing with connect, etc.  Those are the only devices I've seen that start up wifi all on their own.