Seems like #exist for #ios is updating #healthkit data in the background fairly regularly now. Fingers crossed it stays that way. After a little more testing to make sure the updating works well I’ll send it out to beta testers for the first round of #applehealth #sleep testing.
Left #exist for #ios alone over the weekend to see how well my #healthkit background updating would work. Today I had a look at the logs and it looks like all my data is updating without me opening the app, but not as often as I’d like. A change I made to stop duplicate updates occurring seems to be stopping a lot of non-duplicate updates getting through, so I had to try a different approach to de-duping the updates. I also noticed the app is getting a lot of “Network connection lost” errors when trying to send requests. Not sure what that’s about yet, as I haven’t been able to reproduce those errors to debug them. Still, getting closer and closer to releasing the #applehealth #sleep update to beta testers!
Yesterday I tried using
beginBackgroundTaskWithExpirationHandler to ask #ios to give my app more time to complete tasks in the background. This seems to have fixed the #exist for iOS bug @josh and I have been struggling with for a week now. Certain calls, usually when my app was in the background, were taking ages and eventually timing out during the handshake stage with the server. It seems like it was actually iOS killing the tasks, but I don’t know why it was taking so long to do so. I didn’t try this
beginBackgroundTask method earlier because everywhere I’ve seen it mentioned it seems to be used for continuing tasks in the background that were started in the foreground, which isn’t what I’m doing, but it seems to have worked anyway! #laterlog
Spent a very frustrating afternoon with @belle trying to debug an esoteric timeout issue between her #ios app and the #exist server. For some reason, in certain conditions, all of her requests to the server hang for like 30 seconds, and then time out in the “ssl handshake” stage (verified on the server). I can’t find anyone else with this issue, and we tried a bunch of different things to fix it but were basically stabbing in the dark. To top it off, it’s not even consistent — requests made while the app is in the foreground do work, and occasionally the background ones do also. And browsers and the Android client don’t have issues. Just iOS. Argh! I’m out of ideas. Maybe if I wish hard enough it’ll magically fix itself…
Aaaargh #applehealth! I’ve had the majority of the #sleep integration in #exist for #ios done for days now, but I’ve been fighting with getting the background observers working. I can’t watch the logs run in realtime, because I’m testing for #healthkit waking up my app in the background and telling it to send new data to Exist, and it won’t do it every time I add new data, because it wants to save battery. So I’m stuck adding data and waiting an hour or so before grabbing the log file to see if anything happened.
Fixed a bug in #exist for #ios today that was causing the app to crash when users turned on location tracking for the first time. Also continued some refactoring of #healthkit code in an effort to get background observers working for #applehealth #sleep and other HealthKit data. The idea is that iOS will notify my app when the user syncs new data to Apple Health, rather than me checking for it regularly. Still trying to get that working for activity data, but it seems to be working well for sleep so far.
Woo! Got #customtracking working in a hacky way in #exist #android. Solved some minor issues with that on the server side, and then verified all works as it should. The next step will be to actually make a nice UI for adding and tracking various custom habits and events, and at some point I’ll deploy the backend stuff to the live server so we can test it for real with some beta testers.
Making great strides today with #applehealth #sleep integration in #exist for #ios! Thanks to some help from @josh last night I got on the right track and today I figured out why I wasn’t adding up all the sleep data per day correctly. I fixed that, and also added some code to check what the longest period of “time in bed” is per day, so I can get bedtime and wake time from that record, in case there are multiple “time in bed” periods. I also added a check to make sure I only use data from one app per day, so if users record data from multiple apps for the same day I’ll just take the first app’s data and ignore the rest so they don’t get doubled-up data in Exist.
First pass of the #exist #customtracking backend done today. Didn’t get time to make the custom Android client that can talk to it, ended up spending the evening helping @belle sort out some sleep logic for #healthkit stuff in #ios. Healthkit is like a dumb database returning low-level records, rather than giving a nice daily summary, so it’s much more akin to the crappier APIs I’ve had to integrate (cough-withings-cough) than the lovely ones like Fitbit’s. We’ll also have to implement custom de-duplication as healthkit won’t prevent multiple apps adding overlapping sleep records. Super fun times!
Still slogging away at #HealthKit refactoring in #exist for #ios as well as adding sleep data from Apple Health. Got some help from @josh to help me figure out the best ways to make my HealthKit code as generic and simple as I can, and after implementing his suggestions I’ve probably cut about half the code involved in the Apple Health integration. I’m expecting lots of bugs to work through, but really happy about cleaning this up, as it’s definitely been the most complicated, messy code in the app.
Not a lot to report today, except that I started a new branch in #exist for #ios, ready to tackle #AppleHealth sleep data, which we’re always getting requests for. I expect It’ll be a painful few weeks (or longer) getting this working and bug-free, but I’m really looking forward to giving users what they want so they can ask us for something else :)
Worked on the login process for #larder for #ios and some refactoring. Tried AppCode again, since it’s been a year or more since I gave it a shot, but I like to use a dark theme for coding and AppCode makes all my fonts look bold when it’s in dark theme. I thought this problem might have been fixed, but it hasn’t and it’s really bugging me. Plus, AppCode makes my computer hot and noisy because it struggles to run such a big Java app. Undecided for now, but not sure I’ll stick with it long-term.
What a week! Spent the past three days feeling stupid, frustrated, and confused, because I couldn’t get this new year ago mood feature working in #exist for #ios. Grappled with two different third-party libraries that didn’t work as I expected them to and roped @josh into an afternoon of helping me debug my #autolayout issues before giving up and building the UI myself from scratch.
This afternoon I managed to get the whole UI built and working with some more help from @josh, so now I can test it out. Hopefully I’ll be able to send this out to beta testers this week.
Spent most of yesterday afternoon debugging an issue in #exist for #ios affecting a couple of users. For some days (but not all), their steps and distance data from #AppleHealth (but not any other data) was super low and incorrect. Lucky @josh was able to help me debug it because I got really stuck and wouldn’t have figured it out by myself.
Turns out the issue was due to me asking HealthKit for data for each day up to midnight for the following day, which sometimes included a tiny number of steps and distance right in that first second of the following day. Once we figured out why I was getting the extra data (totally my fault) and how to exclude it from the results I was sending to the Exist API, the fix didn’t take long. And thankfully Apple approved the update overnight, so it’s already in the App Store. I think that’s the quickest I’ve ever had an update go through Apple review. #laterlog
Yesterday I did some more work on #exist for #ios. I’m still working on building in the new feature to show your mood note and rating from this day a year ago after you submit a mood rating for today. I wanted to re-use layout code for the mood note and rating UI but being the n00b I am, I hadn’t made my old code generic enough, so I spent a good chunk of yesterday afternoon decoupling my code and making it more generic. #laterlog
Yesterday I cleaned up my extra #exist for #ios #git branches and started a new one for a feature that’s been in the Android app for a while—your mood rating and note from this day a year ago. Started working on the API call after you rate today to check if you have a rating and note to show from a year ago. Still need to finish this off and add the UI to show the data to the user.
Today I did some overdue #support tickets instead though, and later tonight I set up macOS in a vm on my pc so I can build some #ios apps. I do have a macbook, but I’d rather be at my pc. I actually got that running with few issues, and I can build apps in xcode without it taking too long — performance seems decent. I’m going to have a go at learning #swift to build the #larder iOS app. I don’t really want to steal it from @belle, but she has enough on her plate already.
So far this week I’ve been mainly working on bug fixes in #exist for #ios and some small refactoring to make my code simpler and easier to maintain. I have a couple of new features on my to-do list to bring the app up to par with @josh’s Android version, so I’m hoping to have all the bug fixes done soon so I can get on with those.
Changed my #rescuetime hours this week to be 4 hours every morning so I have afternoons off for #HelloCode. I was finding it hard to be totally switched off from Hello Code for 3 days a week, and to plan everything I need to do for RescueTime in just 3 days. This setup seems to work better.
Last week I sent a new update of #exist for #ios to the App Store with some bug fixes and some different bug fixes to my beta testers. I also wrote a new post for the #larder blog about why I blog about my code even though I’m not an expert.
- Paid my latest #tax instalment
- Cleared out my inbox (mostly)
- Followed up most of the #changemap tasks for #exist that came in over the past week
- Wrote up the Hello Code monthly report for December and drafted a matching #blog post
- Worked on bug fixes for #exist for #ios, sent a new version to TestFlight, and tried to submit a new version to the App Store but iTunesConnect was broken yet again.
A very late #laterlog to mention that @josh and I spent all afternoon Sunday #pairprogramming to implement a new feature in #exist for #ios: in-app notifications! We’ve had these for a while in the web app, so users are alerted when we’ve made a major change like adding a new feature or integration, but not on mobile. Josh recently added them to the Android app and was kind enough to help me get them done on iOS in an afternoon. Just need to do some testing now, but hopefully I’ll be able to release a small update with this feature included soon!
Update on #changemap on betalist: around 30 waiting list signups in the first day (which will probably be the biggest). Not too bad given the minimal effort. Mostly smallish SaaS startups, based on some email domain browsing. Hopefully people who understand the value of paying for stuff!
My passion for working on #exist for #ios has been reignited! I sent out the latest update including lots of new Apple Health data (workouts, nutrition, active minutes, heart rate) to the App Store this week, so I’m just waiting for it to be reviewed.
For some reason we had a bunch of users all asking us for menstrual tracking over the past week or so, and it’s something I’ve always planned to get from #healthkit but haven’t gotten to yet. So after sending out that update I was really motivated to explore getting menstrual data from Apple Health. Exist doesn’t support it yet but I’ve started working on getting the data anyway. I think my motivation really wanes when I’m working on bug fixes. It’s a very slow, difficult, lonely process for me, and I often struggle to replicate bugs and feel like updates just get stuck in limbo for ages while I worry about how to fix all the bugs. But starting a new feature is always fun and exciting—and a lot faster these days than it was a couple years ago!