Sleep Well

Legend of the “One Day” App, Days Four to Six

Posted on by Philip B. Gottschalk

A graphical representation of how interesting Days 4-6 were…

Days 4 & 5 (11th & 12th February) were a weekend. I code/do different things on weekends to avoid coding fatigue on my main project. So, already, that’s the best part of a week gone on my “one day” app.

Monday, Day 6, then, was spent on more unpleasant things: tidying & documenting code, and finding energy enough to write some of the blurb I imagined I would need for submitting Sleep Well to the App Store. Yes, Day 6 was Procrastination Day.

I did run into one rather annoying coding headache: how to close a window properly. I have several windows, you see, and, at various times, I need to close them. You might imagine the best way to do this is with [window close]; …well, it isn’t. If you do that you’ll get crashes. Clearly, the solution is to use [window orderOut:nil]; Clearly!!

The problem I have with App Store submissions is that I know they are the single most draining part of the whole project. I need to feel rested and full of vim to even open up the developer website. So Monday would be ideal, no? Well, no. By now it was Monday afternoon and I was cranky from the time spent on tidying code, that Window-close “feature” and my rather-horrifically-moribund attempt at a description (which I still needed to “translate” into three more languages).

So, instead, I worked on one of my other “almost done” big projects and prayed for more energy to find me on Tuesday…

(spoiler: I would have that energy and, by Jingo, I’d need it…)

Advertisement

Legend of the “One Day” App, Day (Part) Three

Posted on by Philip B. Gottschalk

Now, the problem with doing your own multilingual code is: you need to “fix” things which are designed to work with the “normal” way of doing things. A case in point: menus. Since I was doing my own on-the-fly translations, I needed to update menus on-the-fly too.

Now, Apple’s menu coding is confused. Or, rather, it confuses me deeply. I’m a simple sort of fellow, so when I see NSMenu and NSMenuItem, I wonder: are they views/windows/abstract? Why do they both have title properties? If I can set the title, why doesn’t it always reflect that on screen?

Of course, I can get them working, but IMHO it’s not intuitive. It’s the Item that has a title which I can edit – unless it’s an item along the top of the screen, then it’s another Item’s submenu, which is a Menu. Not at all confusing.

The other problem is that, if you want to update a menu, you can’t do that when you need to, i.e. when the menu sends you an Action. So, if I have a menu to change a display language to German, I can’t set the title of menu-items to their German equivalents straight away – but 20ms later is fine.

The 20ms-later trick is also good for adding emojis to menus. If you don’t do that, the emoji doesn’t get displayed. Is that really by design?

So, this sort of confusion is not good for a Friday, and that’s where Day 3 went. Along with researching which English words should be translated and which shouldn’t. For example, “Quit” doesn’t seem to be translated in other apps but “Window” does. This is why English is the easiest language to learn, because of all the English words that lazy gits/sheep like me couldn’t be bothered to translate…

Legend of the “One Day” App, Part Two

Posted on by Philip B. Gottschalk

After Day 1, this is probably what my one-button, one-label app looked like.

Basic. So, Day 2 was all about tarting it up a bit. Getting it a bit more like this:

In other words, I needed to:

  • create background windows to fade the desktop to black;
  • add a background gradient;
  • animate the button and gradient.

Actually, the button doesn’t animate, I have two labels over it, one sun, one moon, and I animate them instead.

The background started life a quick “painting” I made in krita.

This looked quite nice – at first – until I realized the brush strokes made me imagine my screen was dirty. It also clashed a bit with my “clean” sun and moon emojis. So, rather than painting new celestial bodies, I used Inkscape to generate a gradient for me, referring to images of scenic sunsets for colour inspiration. This gradient only needed to be one-pixel-wide, as it could be horizontally stretched, thus saving me a bit of space.

A couple of neat extras:

  • the window goes from “light mode” to “dark mode”;
  • the icon goes from an empty bed to an occupied one.

Don’t mind him – he’s from Barcelona…

On the Model side of the app, Day 2 involved:

  • ensuring that clicking or “typing” on one of the background windows should also cancel auto-sleep;
  • I wanted to be able to cancel auto-sleep by pushing a key modifier like “shift” – for this, keyDown: is no good; I needed flagsChanged: too;
  • I wanted to support German, French & Spanish.

Why German, French & Spanish? Well, I am very curious to find out whether going to the effort of translating text makes any sort of difference to sales. For a tiny app like Sleep Well it is not a massive amount of work to add a few translations.

But why German, French & Spanish? Well, I’m as English as Queen Victoria (I’m half-German, my father is German and I married a German). French and Spanish meanwhile are much-used around the world, I know some French from school, and Spanish also has Latin roots, so I have some tiny idea if the online translation tools I’m using aren’t just spouting gibberish at me.

As far as I am concerned, Apple’s approach to multilingual apps leaves a lot to be desired. It involves having all the translated text in one place with no context to it, and a lot of gobbledegook IDs. From such “localizable.strings” pages, how can I tell – for example – whether “Sleep” is meant as a noun or a verb? No, no, no, not for me! 🙂 I like to have text where the relevant code is. For instance:

char const * txt_hello = @”Hello|de Hallo|fr Bonjour|es Hola”;

That’s how I roll. Country codes and pipes, and let the smart labels work out which one to use. No need to restart the app or any such malarkey, just refresh some objects’ draw routines.

So that’s two days of the “one day” app. Reasonable so far? Good. It won’t stay that way… More soon…

Philip

Legend of the “One Day” App, Part One

Posted on by Philip B. Gottschalk

Is it possible to code a good, useful app – and something that’s not been done before – in just one day? Spoiler: yes, of course it is. But the coding is the easy part – getting the app to the point of release can take considerably longer.

So, in this new series of blogs (yes, I’m not dead yet) I’ll be talking through the pitfalls I faced just to release one very simple app. An app with a single button – and how many apps are that simple?!

Background

For the past too-long-to-admit, I have been working on several medium-to-large-sized apps. About three of them are “very-almost” ready for release. The last thing I needed to do was begin work on something new. But I felt I had to code it for the sake of my sanity and, once I did, I wondered whether I could also get it onto the App Store. A small appetizer before the feast to come.

So, here was the problem: my Mac had developed a nasty habit of waking up from sleep mode by itself. Mostly this happened a second or two after I pressed “Sleep”, other times it would wait till a particularly irritating moment (once it actually woke me up while I was asleep).

My options, as I saw them, were:

  1. use a screensaver instead (wastes power, keeps the monitors on);
  2. turn the Mac off (inconvenient to do for short periods of time; often I have tasks running in the background, and I also like to use a RAM-disk);
  3. code an app to put the Mac back to sleep automatically. 🙂

Why do Macs sometimes wake up randomly? Well, my research points to a malfunctioning USB device being the usual suspect, but who knows? I don’t want to replace my devices if they are otherwise-working. So, option 3 it was.

App specifics: the app must send the computer to sleep, monitor it if it wakes up, and put it back to sleep unless told not to do so.

Goodnight, Sleep Tight, Don’t Let The App Title Bite You In The Backside

My first mistake (not realized till many days later) was in the naming of my app. I called it Sleep Tight. Why was that a problem? Well, someone else had already coded an app called Sleep Tight. So Apple wouldn’t let me submit my app with that name. I’d have saved myself the hassle of a lot of renaming if I’d registered the app title with Apple in the first instance.

Above are my (slightly-redacted) work-progress notes from 8th February which, as of writing this now, is a month and eight days ago. In fact, I started mid-afternoon, as a last minute addendum to my working day. That lunchtime my Mac had auto-woken several times, and enough was enough. I was done with the app a couple of hours later. So just how does a two-hour app balloon into a five-week app? I’ll start that explanation next time… 😉

n.b. I do want to keep these blog posts brief (both for me to write and you to read), but if you want to skip to see screenies of my finished app you can visit the product support page for Sleep Well. And, if you’re interested in buying it, here’s a link to Apple’s app store page for Sleep Well. Cheers! 🙂

Philip G, 16th March 2023