I’ve been nudging my #exist #android #customtracking beta testers recently, trying to get feedback (in traditional fashion, only 3 or 4 of the group bother to say anything), fixing some small issues, and doing some extra bits and pieces to round it all out, like writing some new insight types. The little feedback I have received has been positive at least, so I don’t think there’s too much left to do. When @belle has finished and tested it for iOS (maybe a few months?), then we can launch 😁
In the meantime I’ll need to work out what to go on with.
Finally finished reading a research paper this morning, based on a study done using #exist! It was mainly about correlations and how to figure out which ones are interesting to users and avoid overwhelming the user with too much information. Some really interesting insights in there.
After that I went back to last year’s annual Exist user survey and read through all the free-form responses again. Nothing gets me more fired up about working hard (and impatient about everything we have to get done) than reading lots of user feedback and thinking about concrete ways to improve the product.
Yesterday I spent the afternoon working on adding #customtracking to #exist for #ios. @josh helped me work out the basic steps to get the user’s custom tags showing up, but I got stuck on the layout and ran out of time to get it working.
I also finally made it to a #cocoaheads meetup last night. I’ve been meaning to go for months and something always stops me, so even though I got off at the wrong train station and had to walk an extra 25 minutes to get there, I made sure I did!
#exist #android #customtracking beta testing is going a little better today. Got some feedback from a few people in the group, and nudged some others to get it installed. Couple of small issues, but overall I think we’re not far off. Helped @belle make a start on it in the #ios app today also. She should have an easier time of it hopefully as I’ve already had to figure out how it’ll all work.
Launched #exist #android #customtracking to the beta testers last night, and pushed a new update today with some small improvements. Looks like a couple of testers have tagged a few days already, which is a good start, and I’ve got a little bit of feedback too. Hope to see more of both over the next few days.
Some final bug fixes in #exist for #ios today. Part of my update that adds #applehealth #sleep syncing was to make the initial sync cover the past 30 days instead of the past 14. I found a timeout issue in that process, thanks to some good user feedback, and sorted that out today.
Submitted a new build using the new #TestFlight setup. Thankfully it didn’t take too long to figure out where they’d moved all my cheese to, and some parts of the process are more simple now (e.g. seems like they’ve removed the specific “notes for review” section, which I never used anyway). Feeling good about getting sleep out to all our users very soon!
Okay, #exist web is ready for #customtracking. I’ll deploy that sometime in the next few days, then get the #android app changes merged so I can deploy a beta for testers that talks to the live server (currently testing custom tracking on our dev one). So early next week it’ll be out!
Also, if you’re an Exist user on Android, and want to help beta test, let me know. I could use some more eyes on it 👍
Bug fixes in #exist for #ios today. One of the recent bug fixes I made for #applehealth #sleep wasn’t quite right, so I fixed that, and another reported by a beta tester from the latest version. Looking forward to getting this next version out to testers, as I think it’s getting quite close to release-ready!
More work on #exist #android’s #customtracking, just one more feature to get it to a point where it’s ready for others to use. That should happen tomorrow, then a few days of testing here, then finally out to the beta testers along with deploying the changes to the web app to make that possible.
Today I did a few improvements to the beta version of #exist for #ios: I added an option to force sync #applehealth data from the past 30 days in case it doesn’t stay up-to-date, made all Apple Health data sync 30 instead of 14 days when first set up, and added a message to tell users who only track time in bed or time asleep but not both that they should use a different sleep tracking app.
Have been continuing to work on #exist #customtracking in #android the last few days. Getting closer to “good enough” for beta testers to have and use, although @belle and I have different ideas about how custom tracking should be used and how prominent its role should be in the app. Not something we can really know without more people using it. I am worried that we’re opening a can of worms by giving people all this power, and potentially they’ll want to do more and more with it until Exist is 90% custom tracking. But I guess if that’s what people want, we should give it to them…
Anyway, hopefully next week we can get it in the hands of people outside Hello Code HQ.
Ahhh I thought I fixed that crash in #exist for #ios yesterday but I didn’t. Should have known that if I couldn’t reproduce it, it probably wasn’t what I thought I’d fixed. Turns out, it was only affecting some of our UK users, because they just switched to daylight saving time last weekend and some naïve usage of date objects on my part created a crash in some cases. So I tracked that down and fixed it today with @josh’s help.
Got sidetracked by lots of #exist #support today. Not sure why, but we had quite a few random emails coming in. Some easy to deal with, and some from people who thought it was appropriate to send us a single vague sentence(!) to interpret. Still, haven’t had any angry people for a while, that’s something.
Sad to see how bad everyone’s data is, though. The main reason we put off this integration is because Apple Health doesn’t enforce any kind of data standards on the apps syncing to it, so the data I can get out tends to be low-quality, inconsistent, or both. I was hoping I was worrying about this more than necessary, but so far I’ve seen exactly the kind of bad data I expected in most cases.
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.