Devlog: CAP Flight Logbook — v3 → v3.6

The headline feature is Google Drive backup/sync, but there are a few smaller fixes riding along with it.

1. Google Sign-In + Drive backup (the big one)

v3 had no cloud storage at all — everything lived in localStorage under the cap_v3 key and that was it. v3.6 adds the Google API script tag to the page head and roughly 400 new lines of JS implementing a full backup pipeline:

• Sign-in flow: tries Google One Tap first, falls back to an explicit popup-based OAuth token request if One Tap is suppressed by the browser. Also auto-restores a previous session silently on load if the user had signed in before.
• Drive folder/file management: creates (or finds) a CAP Flight Logbook folder in the user’s Drive, and creates/updates a cap_logbook_backup.json file inside it.
• Pull-then-push merge on first sign-in: treats Drive as the source of truth, merges in any local-only flight entries that were logged offline, then writes the merged result back. It reports how many entries were loaded, kept, or dropped.
• Manual restore: a “Restore from Drive” button that fully overwrites local state with whatever’s in Drive (with a confirm dialog warning it’s destructive).
• Sign-out: clears all the Drive-related localStorage keys and the in-memory token/user.
• UI feedback: a dismissible colored banner system (showDriveBanner/hideDriveBanner) for sync errors, popup-blocked warnings, and merge summaries; plus a small sync-status indicator both in the Settings card and now in the top bar (shows a green checkmark with the user’s first name once signed in).
• save() was changed from a one-line localStorage write to also trigger driveBackup() whenever a Google token is present — so every save silently pushes to Drive in the background.

2. Settings page reorganized

The old single “Data” card is now split into a “Google Drive backup” card (sign-in button, account info, restore button) followed by a separate “Local data” card for whatever local-only settings used to live there. This is purely a layout consequence of feature #1, but worth noting since any custom styling targeting the old card title would need updating.

3. Airport search fallback rewritten

apRenderFallback() — the function that runs when the OpenAIP API is unreachable or no API key is set — was reworked:

• v3 shipped a hardcoded ~120-airport fallback list (AIRPORTS_FB) and did fuzzy scoring/ranking against it locally so users without a working API key still got reasonable autocomplete results.
• v3.6 removes that entire list and instead just shows a hint message (different wording depending on whether it’s a network error vs. missing API key) plus a “manual entry” option to add the typed ICAO code directly.

This is a meaningful behavior change, not just a refactor: v3.6 users without an API key (or with OpenAIP down) lose airport name/city autocomplete entirely and have to type/know the ICAO code themselves. It does shave a few hundred lines of static data out of the bundle, though.

4. Minor refactors

• rHeroUnit(c) was extracted into its own function instead of being an inline template literal — same output, just cleaner.
• The Settings “Data” card title and a couple of inline conditionals were tidied up to support the new sync-status helper rSyncStatus(ctx), which now serves both the top bar and the settings card from one function.

#What’s New?

In terms of new, I have added the requirements page, I fixed the printer button, I added the breakdown of which hours will be next, I made things look better on mobile for easier use, I even added in the API Key that allows cadets to register their own personal key to pull almost any airport in the U.S. and it works, and finally I added an issue.

#AN ISSUE?!?!

So flashback to the last devlog, I said that I wanted to implement google drive integration. The good news is I figured out how to do that and I believe that it shouldn’t need a backend, unfortunately I don’t know this for sure and it’s still a work in progress, my next log (after this one) will hopefully be a positive update on that. As for the website idea for documentation and so on, I have decided to halt that and either make it a separate project or wait until I have this one almost completely done.

#And after that?

Well, hopefully after these next few updates, all will be done and I’ll be able to ship this project (after some major updates to the github repo readme file of course) and finally be done. The goal is to ship by the end of the week, I really want the sticker.

Adding Features

I have begun adding features and putting data where it needs to go. I added a settings tab which includes Cadet Information such as Name, Grade/Rank, and unit. It also has the import and export features, and includes the ability to erase all data from the site. I added the print button here as well, but there are some minor issues with that button in particular, it prints the wrong page. I plan to address this with my next edit.

Next, there is now separation between the logbook and dashboard tabs, the dashboard tab greets the cadet by name and grade as well as has their unit listed. It shows some brief information at a glance: Hours, a less-detailed breakdown of hours, average flight length, and the most recent logs. I have also added the acronym (CAP) into the app. This shows in the corner where the app says CAP with a little plane, and the title says “CAP Flight Logbook” now instead of just, “Flight Logbook.”

What’s next?

My next goal is to add in a requirements page that displays everything from practical exam (the one where you fly the plane) to whether or not your medical grade is registered. I want to fix the printer button, and have a breakdown of hours left vs what they have and the percentage of the way the cadet has on his license. The final two goals for this next edit are: Making things look better, and adding in the API key function to fetch all airports in the U.S.

What’s after that?

After those next few edits, I want to build a decent looking webpage to provide basic information on the project, how to implement it properly into the unit, and some documentation. I would also like to try and add google drive integration because CAP cadets have google accounts provided by the government, this would allow to sync the backups to google drive instead of doing manual backups and would negate the need for a vps to host this app’s database and authentication system.

This includes two iterations because I originally started it and before making my devlog, I started the second piece. The first iteration was just to test browser storage and missed 99% of features, it only included the date, aircraft tag, and hours, it was as boring as the website could look. The second version is that same idea but with an actual UI, color and design, it also featured the hour breakdown tool and allowed more input options on the log. It featured a json export and import with a simple format shown below in a photo, and finally included the print button also shown below in the photo. At this point, I was just focused on the logbook and haven’t added any of the fancy features or the designs that make it look like it was built for CAP. All of that will hopefully be in the next edit.