Kelake

I’ve rewritten the audio player for the iPhone app that I developed 4 times before settling on the current implementation. Playing audio with Swift has many working examples to choose from and at the most basic level is easy even for me to implement. But streaming and caching audio was a bit outside of my range of capabilities at the time, so I used an open source library to fill the requirements.

Unfortunately, the framework I am relying upon does not allow for repeating audio if the screen of the device goes to sleep. A rather serious limitation as far as the user is concerned.

I’ve been sitting on this bug for over a month and today I, after doing all the possible household chores imaginable, decided to sit down and once again to try and attempt a fix. Unfortunately no easy fix was forthcoming, except this rather inelegant hack:

UIApplication.shared.isIdleTimerDisabled = true

This essentially prevents the screen from dimming and going to sleep. That solves the problem, and would be fine if this was an alarm clock app., but not fine when you are trying the escape the glow of a device in the bedroom.

This method also breaks down if the app for some reason is placed in the background, which will require a whole other set of digging for answers.

From Writing software is hard by Signal v. Noise

Software frequently fails to be good because its creators simply aren’t competent enough software writers. There are many qualifications to that charge, many alleviating circumstances, and a very broad definition of “competent software writer”. But it is a helpful start to accepting responsibility. And accepting responsibility is the first step to improvement.

I write poor software. I hope that someday I won’t but that is the current state I am in.

I completely understand how we ended up here. With good intentions, of course. Learning something new, like programming, is daunting. Imposter syndrome is rife. We have all sorts of reasons why we want to encourage and support everyone trying to entice grumpy computers to dance.

And we’ve succeeded to an astounding degree with those intentions. Getting started programming today has never been easier. From open source to superb books and tutorials to bootcamps, it’s a splendor.

This is in sharp contrast to the fact that programming has also never been harder to master, in both depth and breadth. There has never been more languages, more concepts, more frameworks, libraries, tools. It’s impossible to know, let alone understand it all. What an odd dichotomy.

Learning to program feels like the hardest thing I have ever done. It’s so often boring and frustrating. The resources are there to get you started – too many resources perhaps. But the feeling I have after understanding the most fundamental aspects is one of being lost. Finding a good map is difficult. Writing software that you would actually want to use is difficult.

A friend once said that learning php for him was much like learning Chinese. I see the similarities and I certainly struggled for years before I could claim fluency, but I don’t think the experience is as similar as he claimed. With Chinese you can put to use what you have learned almost immediately, which is fun, and it builds upon itself. Of course there is Hello World in Chinese as well, but that is almost useful while in iOS development at least, it is not.

Originally one of my goals was to try a career change, work remotely for someone as a junior engineer, but that idea might have been naive, at least in the time frame I had set forth. Which is just like my experience in studying Chinese. I thought just over 6 months might be enough, then 4 years went by (including almost 3 full-time), and I was only then becoming functional. Maybe programming will be the same.

This is a note-to-self: Don’t use Non-ascii characters in Bundle ID. I’ve made this mistake twice now causing all kinds of extra time fixing the problem.

Bundle ID should not be localized according to CFBundleIdentifier Documentation:

CFBundleIdentifier (String - iOS, macOS) uniquely identifies the bundle. Each distinct app or bundle on the system must have a unique bundle ID. The system uses this string to identify your app in many ways. For example, the preferences system uses this string to identify the app for which a given preference applies; Launch Services uses the bundle identifier to locate an app capable of opening a particular file, using the first app it finds with the given identifier; in iOS, the bundle identifier is used in validating the app’s signature.

The bundle ID string must be a uniform type identifier (UTI) that contains only alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.) characters. The string should also be in reverse-DNS format. For example, if your company’s domain is Ajax.com and you create an app named Hello, you could assign the string com.Ajax.Hello as your app’s bundle identifier.