Projects
-
Common Errors When Developing for Fitbit
Or maybe just common to me?
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. -
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
toindex.gui
,widget.defs
towidgets.gui
(note the plural change), and edit the contents ofwidgets.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
, thenbuild
and (assuming the Fitbit simulator is up and running Mira)install
.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
, andapp/index.js
with the provided code, runbuild
andinstall
(orbi
which apparently is shorthand for both) and you get a very nice clock: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.
-
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.
-
Typescript-ifying Noodle
Over the spring and summer, I built Noodle, a minimalist, privacy-focused event scheduling app. (more) My friends and I use it all the time, but development has kinda slowed.
This is a problem, because if I ever need to fix anything, I’m going to have to go back and remember how the code works, from scratch.
Javascript is so permissive. It’s great that I can get up and running without having to worry about whether I’m comparing a string to an int, but future me is going to step on that rake, I know it.
Separately from the conversation I’m having with myself about how to ensure code maintainability without having to remember why I made all the decisions I did, my mentor at work suggested converting the project to Typescript. So that’s two people telling me to do this, so here we are.