Stream of ADD

I’ve been distracted again. Not by a project this time. Just by my own inner thoughts. I have this thing that makes it difficult to remain productive for long stretches of time. I worry that it will make me never finish a project of any significance. Mind you, any true work of art is never finished, only abandoned.

Right now, as I type this, I’m not even thinking about what I’m writing. And I’m not a good multitasker. My mind just reals with ideas, thoughts, images, and sounds. These are going on all the time except during rare moments when I feel calmed. This is not one of those moments.

A while back, I was inspired to do a nutrition app for iOS. Something that could be hooked up to Health Kit. The problem that really needs solving is getting a database of packaged foods so that I could scan in the code with the camera and look up that item to calculate such things as calories, sodium, fat, vitamins and minerals, etc. It’s a good app idea. But I haven’t gotten far with it. Getting the database together has been an issue.

Scanning codes led me to the QR Code. I’ve only been peripherally aware of their existence until I wrote two proof of concept apps. Both are on GitHub. One is called HelloUPC. It’s a simple proof of concept for scanning all sorts of bar codes, including QR Codes that are recognized by Core Image. The other is QRTest, another very simple app that lets you type in arbitrary text and produces a QR Code for it.

I’ve played with both apps a surprising amount. Neither are intended as a product. They were just learning exercises.

The idea of using QR Codes for business cards is not a new idea. It is in fact probably a great idea. You can store more than a simple URL in a QR Code. You can store a vCard in there. There is a limit to the data that can be stored. But partial information that allows you to scan a business card that uses a QR Code to encode a vCard is a nifty way to get the information from the business card into your contacts list.

One small problem. I’ve lost all enthusiasm for that project. It’s gone. What happened instead is this crazy idea that it might be possible to store a QR Code as a PNG file in a QR Code for that very same PNG file. I don’t have the math to prove if this can be done or not. Nor do I know how much time it would take if it can be done to find a point of convergence where the data in the PNG file matches the the data in the QR Code. I did find that Core Graphics does not provide a means of writing 1bpp PNG files which would be necessary to get the file size small enough to fit in a QR Code if it can be done at all. So now I’m looking at libpng to do the job.

While libpng is a nice library I’m sure, it is not as simple as using Image IO to write out a graphics file. Or maybe it is. There is a surprising amount of documentation to read to understand how to use libpng. Mind you, I did read a lot of documentation to get as far as I did with writing out QR Codes to a PNG file that is not 1bpp.

So why did I lose interest in the idea of using QR Codes for business cards? I don’t have any business cards. I don’t go out and exchange business cards. I can’t eat my own dog food, an expression that basically means you should be using your own software so that you are a user as well as the author.

I’ve had numerous other app ideas that have gone by the wayside. Usually either due to distractions or the realization that I’m aiming too high for a single developer. Programming is hard. It is amazing how little code you can end up with at the end of the day.

It goes something like this. You have an idea. So you start a test implementation. It’s crap. So you rewrite it. It gets a bit nicer. But you find other ways of doing it that are even better. So you rewrite again. Lines are added and then taken away. It’s like modeling clay except that the clay is spells in a text editor for doing the magic things that computers do. My programming style is very organic in this way. To keep things clean, it is necessary to constantly go back and organize things so that what you grow is a nice tree and not a thorny bush.

Working with these APIs and frameworks has also demonstrated something else to me. Apple has put together a rather nice package of tinker toys. A lot of hard things have been made easy. Mind you, a lot of easy things are still hard. Also, building a complete application from the ground up is not an easy thing to do. There are usually many people who have their hands in the cake, so to speak. You have UI people, UX people, algorithm people, art people, code people, etc. Often there is a lot of overlap.

When you are going it alone, you wear all the hats, including the marketing one.

There’s more. OS X and iOS are not entirely the same. iOS is not simply a subset of OS X. Certainly there is a lot of that. But there are also some fundamental differences. One is based on mouse and keyboard input. The other is based on touch input. Not just touch input either. iOS devices can know where they are and how they are moving. Those are also forms of input. iOS’s different hardware allows for an entirely different style of app than you get on the desktop.

Now here’s the rub. I sporadically come up with ideas that can work on one device type or the other. Now I’ve got one that should work on both. This is where the UI issue comes into play. OS X uses AppKit. iOS uses UIKit. How would one go about writing an app that crosses that boundary in such a way that you have a proper experience on an iPad and on an iMac?

I think that is an interesting challenge. How did Apple do it with Pages? I suspect one has to work at a lower level than both AppKit and UIKit where the common subset of functionality is. And it would be very nice for the file formats to be common to both iPad and iMac (including the laptops of course).

All These Worlds
All These Worlds

Don’t Even Read This

It’s been too long since making a post. I think the three or four people who read this blog are getting bored checking to see if I’ve made a new post. So here it is.

I’ve been distracted from an iOS app I’ve been working on. The distraction involves having to do a custom view to have different layouts between portrait and landscape orientations. UI is not exactly the most exciting thing for me. The distraction, on the other hand, has proven to be too much of a distraction. I had this idea that should work. At least, I think it should. My math skills are a bit iffy. But intuitively, I think Shannon’s Law allows it.

Let me post a bunch of code and then explain what it is I’m trying to do. Bear in mind that this is strictly an intellectual exercise with no intrinsic or economic value.

[gist user=”DavidSteuber” id=”78b2c6a83932b0e307d8″]

Now for a quick run through.

qrCodeWithMessage creates a QR Code from an NSData object. This is straight up binary data. The idea is that the data would be the on disk representation of a PNG file that displays the QR Code. If a QR Code scanner is able to display binary data and discern that the data is a PNG file, it should display the image which is the QR Code. At least that is the goal here. The current code doesn’t work. I’ll get into that.

colorSpaceIndexed is supposed to create a two color pallet in B&W for a one bit per pixel PNG file. I don’t get any errors with it. But it doesn’t seem to work. I don’t know why. I’ll post links at the bottom of the article about where I’ve asked how to get things to work.

createBitmapContext is the drawing contest for the CIImage that is produced by qrCodeWithMessage. A CGContext is required to create the pixel data for an image that can then be drawn using Quartz. This is a gray scale context. One bit per pixel contexts are not supported.

createCGImage produces a CGImage using the CGContext. At this writing, it is a gray scale image. This chews up 8 bits per pixel. Even with compression, this is too much data when the image only has the two colors.

saveImage does pretty much what it says. The NSData which contains bytes representing a PNG file is saved to disk.

getImageFileData simply gets the bytes from the NSData object that represents a PNG file. This is so I can compare the bytes for equality.

compare is the function I use to do the comparison. It’s pretty much like the standard Unix function. It tests for equal length first and then does a byte for byte test.

main makes it all go.

The problem I’ve had is that I have been unable to find out how I’m supposed to create an indexed PNG image. PNG supports such a representation. I use it as a QRCode (generated from a web site) that points to my blog site.

QR Code
QR Code

If you inspect the properties of this image, you can see that it is a 1 bit per pixel indexed image. This is the format I’m trying to create with my Swift code using Quartz.

What I get instead is this, an 8 bit gray scale image with no alpha channel that exceeds the amount of data that can be stuffed into a QR Code.

8 bit gray scale PNG file
8 bit gray scale PNG file

This is not what I want.

Too be fair, even if I got the 1 bit per pixel file format, I’m not certain that it would fit into a QR Code. I also don’t know if I will converge on a QR Code that represents itself as a PNG file. But it would be very cool if it did.

This thing is taking up my waking mind. I’m at war with Quartz to get the file representation that I want. I’m actually tempted to take zlib and libpng and use them to do the work. But this would be insane since it is obvious that OS X and iOS have no problems with drawing a PNG file of the type I want to produce.

So How do I produce the PNG file that I want using Quartz?

Boards I’ve posted my question on:


Apple has released OS X 10.10.3, iOS 8.3, and Xcode 6.3 on April 8th!

The good news for everyone is bug fixes. The good news for me is no more dancing between Swift 1.1 and Swift 1.2. I’ve already updated relevant code from my recent posts on GitHub. For the first time in a while, I have just the one Xcode icon in my dock. I think I’ll keep it that way for a while.

I’ve also noticed that my twenty fifteen-child theme is unreadable on mobile devices. I’m going to switch back to the main theme while I get that fixed even though it uses up too much white space. It’s better that this blog be readable on mobile since that turns out to be the primary platform used to read it!

QR Code
QR Code