5 ms·

Write apps for Garmin watches, especially supporting ones a generation or two old and on the lower end. Welcome to the world of removing code to shave a couple

Write apps for Garmin watches, especially supporting ones a generation or two old and on the lower end. Welcome to the world of removing code to shave a couple KB off the space the code itself takes up in memory so you can use it for data. Oh and for some reason their language and APIs are OO despite the fairly tight memory limitations, and despite not having any real need to do that (nor enough memory to really take advantage of any OO features even if you wanted to). So you've really got to watch (haha) yourself.

nradov 6y ago
There are a lot of crappy third party apps on the Garmin Connect IQ store which burn battery life or cause random crashes or interfere with activity recording. On the Garmin forum another user found that a third party data field causes erratic GPS tracks for open water swimming.
- karatestomp 6y ago
  Some of that might just be sloppy development but I have a feeling that part of it's the SDK's fault. It's a weird mix of being too abstract to let you take tight control of performance but not abstract enough that I ever felt confident it was doing a reasonable job of taking care of that for me. Though maybe I'm wrong and that part's fine, I don't think I ever benchmarked power use (another thing: the tooling is about as mediocre as you'd expect for a proprietary platform like that) I tell you what, though: having a declarative UI where "declarative" is "now draw text at coords [some coords]. Then draw a square of dimensions [dimensions] at coords [other coords]" is a fucking refreshing break from webdev. Even more so than regular mobile dev. There's simply no room on the devices for much screwing about. You've got your lifecycle methods and some calls that draw things. You can listen for button presses. That's about it as far as the UI goes.
  - adrianN 6y ago
    If third party programs can disrupt core functionality that's a failure of the operating system.
    - nradov 6y ago
      The operating system is working as designed. Garmin wearable device customers demand maximum battery life with minimum size and weight. Within those constraints it simply isn't feasible for the OS to provide a high level of protection.
      - adrianN 6y ago
        I don't understand what power constraints have to do with the operating system providing proper process control, but I'm not an OS expert. Could you maybe add a few sentences of explanation?
        sys_64738 6y ago
        If the cpu is doing work it’ll consume battery life. You get longer battery life from a system mostly in a low power state. An app will get the cycles it requires - it’s a trade off which usually means doing more work means less low power states. Less efficient apps will not enable low power as often. There is cooperation here and it’s why Apple didn’t originally allow background apps on the iPad.
        skaevola 6y ago
        The Garmin Watches don't have DRAM for power reasons. The processor is a memory constrained microcontroller without a hardware memory management unit. Without the MMU you don't get as powerful memory virtualization or process isolation.

nradov 6y ago

There are a lot of crappy third party apps on the Garmin Connect IQ store which burn battery life or cause random crashes or interfere with activity recording. On the Garmin forum another user found that a third party data field causes erratic GPS tracks for open water swimming.

karatestomp 6y ago
Some of that might just be sloppy development but I have a feeling that part of it's the SDK's fault. It's a weird mix of being too abstract to let you take tight control of performance but not abstract enough that I ever felt confident it was doing a reasonable job of taking care of that for me. Though maybe I'm wrong and that part's fine, I don't think I ever benchmarked power use (another thing: the tooling is about as mediocre as you'd expect for a proprietary platform like that) I tell you what, though: having a declarative UI where "declarative" is "now draw text at coords [some coords]. Then draw a square of dimensions [dimensions] at coords [other coords]" is a fucking refreshing break from webdev. Even more so than regular mobile dev. There's simply no room on the devices for much screwing about. You've got your lifecycle methods and some calls that draw things. You can listen for button presses. That's about it as far as the UI goes.
- adrianN 6y ago
  If third party programs can disrupt core functionality that's a failure of the operating system.
  - nradov 6y ago
    The operating system is working as designed. Garmin wearable device customers demand maximum battery life with minimum size and weight. Within those constraints it simply isn't feasible for the OS to provide a high level of protection.
    - adrianN 6y ago
      I don't understand what power constraints have to do with the operating system providing proper process control, but I'm not an OS expert. Could you maybe add a few sentences of explanation?
      - sys_64738 6y ago
        If the cpu is doing work it’ll consume battery life. You get longer battery life from a system mostly in a low power state. An app will get the cycles it requires - it’s a trade off which usually means doing more work means less low power states. Less efficient apps will not enable low power as often. There is cooperation here and it’s why Apple didn’t originally allow background apps on the iPad.
      - skaevola 6y ago
        The Garmin Watches don't have DRAM for power reasons. The processor is a memory constrained microcontroller without a hardware memory management unit. Without the MMU you don't get as powerful memory virtualization or process isolation.