I also spent a long time trying to apply for the compulsory worker’s injury insurance thing we need to set up now, even though it’s just me and @belle working from home. There’s only a couple of companies in Victoria that offer it, and man, they’re all so bad at online forms that even the one I ended up going with did not at all inspire confidence. Plus they ask for lots of numbers you’re supposed to just know, like next 12 months’ revenue and expenses. I hate doing this stuff and by the end it made me question whether it’s even worth running a small business. 😩
Made good progress today on #exist #manualtracking — this time, making the necessary changes to the web interface. Back on the productivity wagon! A little more to do so users can edit and manage custom tags from the web, then some better custom entry UX in the Android app, then beta testing time.
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…
More #exist #android #customtracking fun today. Trying to design an alternative 8-day graph for the Today tab that’s a bit more compact and attractive than reusing the current graphs, as they’d all just say 1 or 0 anyway. So far I have some little ticks in pill shapes that look nice. I wish I could come up with something as readable that is more compact, but all the variations I’ve tried were harder to parse. Oh well, design’s all about compromises, right?
I guess I’ll leave it at what I have for now, and muse on it a bit while I work on the editing interface.
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.
Started setting up the interface in the #exist #android app for rendering #customtracking tags. There’s probably a lot of iterating to go on making it all look just right, but I think the first 80% is done. Next step will be to think about how the interface for tracking stuff (literally, typing in your tags) will work. We also want to make it easy to add and edit stuff, but don’t want to make people think they have to use it by making it too obvious with extra buttons everywhere and so on. So yeah, even more iterating to get it just right.
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!
Today I started setting up the backend architecture for the next big #exist feature, #customtracking. I’m pretty excited about it! I hope users will love it. We’re going to let them submit a daily string that’s just a list of tags, eg.
"piano, meditation" which we’ll turn into individual attributes with a value of
1 for that day. It means that users can track whatever they want (binary habits and events at least, but not integer values) and we’ll transparently support it, find averages, use it in correlations and so on. I think it’ll only take a few days to get the backend done, then we’ll make a beta mobile interface to test how users will interact with it.
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.
The new #exist weekly email went out this morning and though we didn’t hear a lot of feedback, two positive tweets will have to be the evidence that it was well received :)
This afternoon I started work on a new public page for Exist showing would-be users what data they can get from various services, and what they’ll have in total from the combination of those they use, hopefully making it clear not just which services we support but what they’ll get from each.
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 :)
This week I’ve been working on #exist’s new weekly email. I’m using a template based on the recent end of year one, which was well received, but have got it almost set up with all the weekly data I want to share. I just need to tweak the styling on some parts, like the correlations, but it should be ready by next week. Hope people enjoy it.
In other Exist news, we did okay converting many of our users who signed up right after Christmas, so we’re on a new maximum paid user count, and our average weekly income is quite high too. I think listing the yearly plan on the home page (previously we only mentioned the monthly cost) is helping drive some more yearly upgrades.
Fingers crossed we see another big spike in conversions from Back to Work listeners! Their trials should start ending today or tomorrow I think.
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.
Also sorted through all the suggestions for #exist that we got on #changemap over the past couple of days—only 1/5 was not a duplicate. It’s so frustrating when users ignore the message right on the suggestion form that asks them to search for their idea before suggesting it. It creates a big waste of time for me and doesn’t help anyone. /rant
Also updated the Exist FAQs page, as it was quite out-of-date in a few areas.
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
Overnight #exist got a mention on Gizmodo! Some kind of niche section called Field Guide. Well if we thought the Back to Work podcast helped, this has been nuts — over a hundred signups today, probably our biggest day since launch. I actually thought we were being targeted by spammers initially because of all the Hotmail signups 😆 if most of these people convert we’ll be doing so much better. I’m trying not to get too optimistic though.
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.
@belle and I had a chat over lunch about an idea I had for custom habit tracking in #Exist — essentially using a free text field to enter a list of tags, like “alcohol, piano, meditation”, or whatever you did. With some fiddling we could run correlations and generate graphs for each custom item, pretending that they’re real attributes. I’m still weighing it up but I think this would be easier and quicker than (finishing) adding manual tracking, with the huge benefit that users can track whatever they want. Of course there are downsides too, in that these aren’t real attributes so they’d not gain all the built-in benefits of being official attributes. Hmmm! More musing required.