05 Dec 2015
Everytime I manually had to create some thumbnails for josiemccoy.co.uk, or a whole
set of icons for an iOS app, I thought “next time I’ll write a script to automate this”.
Finally I got around to writing the script, which only took a few minutes which should save me, er, a few minutes each year.
Once I found the excellent JIMP package - a pure JavaScript image manipulation library -
it was easy to write a couple of scripts to do exactly what I wanted.
The script to generate all the image sizes required for an iOS app is available on GitHub if
you want to try it out yourself.
01 Dec 2015
After a pretty long development “sprint”, Daily Optimiser 3.0 has finally
hit the App Store.
Apart from lots of under the cover changes and UI improvements, the big news
is that the app - previously iPad only - is now available for the iPhone.
The reason it took us so long to release an iPhone version is we always assumed one of the
key features of the app is the ability to see both your task list and meetings in one view.
However after a few UX experiments it turns out - not for the first time - I was completely wrong!
Having a quick way of switching between the 2 lists is very useful, and the visible timeline
pulls together the two views in “task mode” nicely.
One thing I didn’t solve in this version is a reliable way to sync which reminders are “most important tasks”
in the cloud. I tried using Apple’s CloudKit, but this proved wholly unreliable in the way I was using it.
Unfortunately I had to pull the sync feature from this release, but will almost certainly revisit this topic
in later releases.
We’re also trying the “patron model” of funding, where users get all features for free, but if they feel so inclined
they can make a one off in-app purchase to support us. In other words, shareware :)
Be interesting how this pans out, whether the
(hopefully bigger installed base we’ll get for a free app make up for lost revenue).
I’ve got another idea for an interesting app, and I’m very much looking forward to tackling some new problems for a while.
25 Nov 2015
We found an “interesting” issue at work yesterday regarding IE, cookies and domain
names that I thought might be useful to share.
At FindMyPast - where I’m currently contracting - we heavily
use GitHub Flow which involves multiple development branches
being worked on at once.
By convention we use underscores in our branch names e.g. “dev_feature_branch”, and
have recently automated hosting of feature branches for test purposes. For example
for the above branch we’ll setup a host for dev_feature_branch.findmypast.com
For a feature I was working on, everything worked great on Chrome and Firefox, but for
some reason we couldn’t login properly using IE.
After much head-scratching, we fired up Fiddler which gave us the
answer.
!! WARNING !!: Server hostname contains an underscore and this response sets a cookie.
Internet Explorer does not permit cookies to be set on hostnames containing underscores.
See http://support.microsoft.com/kb/316112
The obvious solution is not to use underscores in the domain name used for the virtual host,
either by convention of stripping them out when setting everything up.
Hopefully if you see a similar issue, this may help you debug it quicker than we did!
21 Oct 2015
Unfortunately there was a bug in v2.0.0 of Count The Days Left where the watch
complication wasn’t reliably updating itself.
Fortunately the issue was interesting enough to blog about :)
What I believe was the issue - not 100% sure but it appears fixed now - is that a watchOS 2 app only has a limited budget
of time where it’s allowed to update itself.
In the getNextRequestedUpdateDateWithHandler function in my complication data source class, I was telling the watch
to update once an hour. This seemed a reasonable compromise (without thinking much!) where the watch would update
itself once an hour automatically, even if the options for the countdown didn’t change - which forces a complication refresh.
However I believe that once an hour is too frequent. If you read the Apple Documentation
closely, it says:
At the end of a scheduled update, ClockKit calls the getNextRequestedUpdateDateWithHandler: method to get the time for the next scheduled update. Specify a date as far into the future as you can manage. Do not ask the system to update your complication within minutes. Instead, provide data to last for many hours or for an entire day. If your budget is exhausted, the next scheduled update does not occur until after your budget is replenished.
Now obviously my count only updates once a day, so I can return in getNextRequestedUpdateDateWithHandler to next update
itself at the start of tomorrow, which means it will only automatically update once a day (but should be correct all that day!)
It appears to have worked on my watch overnight, so I’m sending a v2.0.1 to the app store today (Wed 21 Oct 2015). The last version
made it past review and into the store in about 2 hours(!), but it’s unlikely to be that quick again.
Update (2015-10-29)
Turns out it was more complicated than I thought :)
Even after the fixes above the complications still intermoittently failed to update overnight. I just think the “automatic updating”
is just a bit flaky.
Anyway, I’ve much improved things by putting in an additional call to update watch complication every time the iPhone app,
today widget or watch app is access. I also added a background app refresh handler in the iPhone app to call the same update
method when ever it is intermittently called.
All of these calls shouldn’t be too frequent - so should have a neglible effect on battery life I hope - and guarantee
as much as I can the complication is up to date.
Another version has been submitted to the app store, and hopefully this one will fix the issue.
N.B. All code can be seen on GitHub
17 Oct 2015
All done! A final few tweaks and v2.0.0 of Count The Days Left has been submitted to the app store for review.
Things I learnt
Developing for the watch is fiddly
watchOS 2 is a pretty big change from the first version, with the extension code now running on the watch. In theory this should
help the performance of watch apps - and I believe it does - but some thought needs to be put into to how you manage your
data flow between the phone and the watch to optimise this.
I also struggled for a while understanding the best workflow for testing watch apps, using a combination of the Xcode
simulators and the watch itself, but definitely learnt a lot along the way what works best.
Is Swift ready for prime time?
I really like Swift as a language compare to Objective-C (although now I’m used to the crazy square bracket syntax I don’t mind
the latter any more), but I don’t feel as though Xcode is quite as reliable when building a Swift project compared to an
Objective-C one.
Sometimes the dependency detection on what changed seemed a bit flaky, or the compiler would say a setting is missing from
an Info.plist file when it was actually there (and a recompilation “fixed” the issue).
None of the problems are major, and won’t put me off starting a new project using Swift. However I’m hoping things get
fixed in later versions of both Xcode and Swift.
What next?
Right now I think I’ve reached the end of features I can add to the app, at least until iOS10/watchOS3 come out and offer some
new things to play with.
However I’m always open to suggestions, so drop me a line at johnp@bravelocation.com or
reach out on Twitter to @yeltzland if you have any thoughts.
v2.0 Articles
N.B. All code can be seen on GitHub
