I'm a full-stack web developer, and this is my blog. Please connect with me on LinkedIn or visit my Github for more! Also, you may be interested in learning more about me.

Projects

> > >All projects
  • More Fitbit Dev Resources

    a stock photo of a person wearing a smartwatch. I'm not even sure if this is an actual fitbit.

    The developing-for-fitbit journey continues…

    Breaking changes between SDK 4.x and 5.x

    The older Fitbit I have, a Fitbit Versa 2, uses software written with version 4.x (or lower?) of the Fitbit SDK. Modern Fitbits use… I think it’s up to 6.x? And excitingly, there were a ton of breaking changes between version 4.x and 5.x.

    I solved a number of the issues here, but am running into more, especially with premade Fitbit components like buttons–which, incidentally, are very poorly documented.

    However! Pure luck and a lot of random web searching led me to this official Fitbit demo project: https://github.com/Fitbit/sdk-exercise/. And we’re in luck, the initial version was written with SDK 3.0 and then was abandoned shortly after, even though all of Fitbit’s developer docs were updated for 5.0 when the Versa 3 came out. In other words, it’s an ideal resource for learning how things ‘used to’ be done.

    From that I found that if I want to place a button on the screen on the Versa 3, I would import <link rel="import" href="/mnt/sysassets/widgets/text_button.defs" />, but if I want to place a button on the screen on the Versa 2, I should import <link rel="import" href="/mnt/sysassets/widgets/square_button_widget.gui" />.

    I’m not even a hundred percent sure how to browse that widgets directory, if it’s even possible; I suspect it’s built into Fitbit’s firmware and can’t be accessed by humans. Which makes this dead repo possibly the best source of truth for SDK 4.0 widget names?

    There are a number of other demo projects in various states of completion in the Fitbit github organization. I believe the repos beginning with sdk- are the most useful, but take a look.

    General help

    Bless this Aussie developer who has 1) made about a thousand watchfaces for Fitbit (including not one, but two watchfaces that actually play Pong) and 2) written up his own SDK guide filled with helpful tips.

    Hopefully these resources help you as they are helping me. And I hope I will have an update on my own app(s) soon!

  • Common Errors When Developing for Fitbit

    Or maybe just common to me?

    Image of the Fitbit developer bridge on a watch

    Problem:

    Install failed: RPC call to 'app.install.stream.begin' could not be completed as the RPC stream is closed

    Cause:

    Jury’s out on what causes this. It seems to happen when I sleep my laptop; the Fitbit simulator doesn’t seem to be able to recover.

    Solution:

    Remove ~/Library/Application\ Support/Fitbit\ OS\ Simulator/, which contains caches, preferences, etc. You’ll have to reset your preferences afterwards of course.

    Read on →

  • Developing for the Fitbit Versa

    In my previous post I said something about learning Android app development so I could make a Fitbit app. However, silly me– just because Google owns Fitbit now does not mean that Fitbits run Android. (:

    Android Wear is what powers Google-owned smartwatches, but if you have a vanilla Fitbit like I do, it’s Fitbit OS. Clear as mud. The upshot, however, is that if you want to write an app for Fitbit OS, you can use plain ol’ Node. So that’s what we’ll do today.

    Fitbit’s dev page has a good tutorial which we’ll follow. First, make sure you have node installed, and have downloaded the Fitbit simulator. (Links on Fitbit’s page.) Then, run npx create-fitbit-app my-app to get started. For this blog post I’m following Fitbit’s instructions so the prompts to answer are clock, any name, no companion.

    cd into your newly created directory.

    I’m developing this app for my personal use (for now) and my Fitbit is a Versa 2, running the “mira” version of Fitbit OS. The default settings for npx create-fitbit-app assume I have at least a Versa 3. To get my new app onto the Versa 2 simulator (and ultimately onto my wrist) I have to edit my package.json:

    "devDependencies": {
    -    "@fitbit/sdk": "~5.0.0",    
    +    "@fitbit/sdk": "~4.2.0",
    ...
     "buildTargets": [
    -      "atlas",
    -      "vulcan",
    +      "mira"
        ],
    

    According to this forum user we also need to change some filenames in the scaffolded project. We must rename index.view to index.gui, widget.defs to widgets.gui (note the plural change), and edit the contents of widgets.gui to point to /mnt/sysassets/widgets_common.gui instead of the file it points to.

    Also, lol, the highest supported version of node is 16, so make sure you’re using node 16 or lower, preferably with something like nvm so you can go back to the present day easily. (Poor Fitbit!)

    Once you’ve done all that, you should be able to start the fitbit CLI with npx fitbit, then build and (assuming the Fitbit simulator is up and running Mira) install.

    Boom.

    Huh. Aren’t clocks supposed to, uh, tell time?

    Follow the Fitbit getting started tutorial to turn this blank screen into a clock. TLDR: Edit resources/index.gui (remember we renamed this from the .view file used in later SDK versions), styles.css, and app/index.js with the provided code, run build and install (or bi which apparently is shorthand for both) and you get a very nice clock:

    picture of a not-actually-very-nice clock face on the fitbit simulator

    Okay, it’s… fine. But hey, it’s up and running. Now let’s do something cooler with it… in a future post.

  • Firebase Crashlytics and Feature Flagging, or What I Learned at WITS Spring 2024

    The following info comes from the Women in Tech Summit which I attended in Philadelphia this weekend. I may type up a more fluffy post about how it felt to attend this conference later, but for now, these are my technical notes from the hands-on session I attended.

    Android app development seems a lot more complex than web-app development. I might be wrong, I’ve built a lot of web apps but no Android apps. (Yet; I just got a Fitbit Versa and feel like that postage-stamp-sized screen is crying out for me to do something with. Apparently it doesn’t run DOOM yet…)

    Anyway, making an app run on the hugely fragmented Android ecosystem, as well as keeping users’ versions up to date (including forcing them to update if there’s a critical security fix) seems like a huge problem. Presumably there are enterprise solutions for this but in my hypothetical DOOM-on-Fitbit scenario where it’s just me, what’s the solution?

    Google Firebase has some great options for solving these problems, which I learned about from two Comcast engineers. Crashlytics can help track and centralize crash data from multiple devices, and Remote Config can manage some app features without having to publish a new version of the app.

    Read on →

  • Local Firebase, or, how I learned to stop trashing my prod db

    Noodle has a lot of the hallmarks of a solo dev side project, which is fair, because it is. Stupid simple deploy pipeline (which is probably a good thing), no tests to speak of (probably not a good thing), no real dev environment. That means when I test Noodle locally I hook up to the prod Firebase db, and usually end up writing a lot of bogus data to it along the lines of:

    • “test event”
    • “test event 2”
    • “asfdkf;;; why wont you work”

    and so on. This isn’t really a problem, as Firebase lets me have a GB of data before I have to start paying them – that is a lot of JSON – but it’s kinda messy. And now that I’m converting Noodle to Typescript, I’m doing a lot of testing.

    Enter the Firebase Emulator Suite. I got it set up so I can run a local copy of my database on my machine and not worry about junk data polluting the real database.

    Here’s how I did it.

    Read on →

> > >Blog archive