Obviously my career as a blogger is not going to happen. That’s OK. I have this site for other reasons.
Since I last posted, a lot has happened. New iPhones. New OS X. New iOS. New Xcode. I’m now on Xcode 7.1 running on OS X El Capitan. I endeavor to do my development in the latest version of Swift when I’m doing Swift (which is what I do for OS X and iOS). Swift 2 has broken some of my code in ways I haven’t figured out.
I am hating the new developer forums. Not all change is good.
My latest efforts have been non-programming related. I’m evaluating programs that are effectively direct competitors to my project. These programs are developed by teams. I am one person. They have also done some pretty cool stuff. I have my work cut out for me if I am to succeed (no guarantees there).
I’m working on a bottom up approach which is not well supported by Xcode. The UI / UX is actually the last bit I’ll be working on if I make it that far. The first part is getting the foundations in place to build upon. This is where changes in Swift have hurt me. Calls to the Core X stuff have broken. I kind of need that to work.
Playing with the programs that do things like what I’m trying to do is educational too. Their APIs are fairly well refined, although I do run into quibbles here and there. They also show me just how much work I have to do.
I’m moving on from QR Codes. They were fun to play with. And I also got to see some of the Core Graphics and Core Filter APIs. I’ve also decided that the CoreX stuff will need a thin abstraction layer for proper usage in Swift. For example, instead of using a CFDictionary, I want to use a native Swift dictionary.
My real worry with starting a new project is failure to complete. I have a real desire to get this one onto the App Store. If history is anything to go by, the odds of that are grim. Even so, I thought I would go ahead and blog about the process I am going through. Maybe someone will read it and give me ideas.
The new project I have in mind has been given the code name Leonardo. I actually hope to make that my product name in the App Store. It’s an OS X project that will be implemented in Swift. Obviously I will have to use AppKit and some of the Core Foundation and other frameworks. Hopefully I can structure the code so that the majority of it is straight up pure Swift. The reason to do this is I like Swift a heck of a lot more than I like Objective-C. I may even like it more than C.
So anyway. The first step in creating a new project is to have a mission statement, so to speak. It’s the goal of the project. It’s the thing that should not be lost sight of. I’m using TextEdit to write down my notes on the project. Here is the statement:
My notes include more than the mission statement of course. I have a strategy for achieving the goal, if I can indeed achieve it. A fundamental part of the strategy is the file format itself. It needs to contain the information acquired from the user via the UI. I’ve decided to use a bundle of JSON files. There will also be bitmaps stored in the bundle if they are imported into a project.
The first step in my project will be rather peripheral. I will be working on importing an SVG file, which is in XML, and converting it to JSON. I will also go the other way. On top of that, I will render the SVG file to PNG, JPEG, and PDF. I will also support SVG output. I’m not sure that SVG supports all the features I have in mind though. So SVG output may lose information or get really complex to create the data for rasterization.
XML is actually kind of complex to parse, unlike JSON. I will almost certainly use the NSXMLParser class to do the work for me. While I would love to do the job in pure Swift, it’s work that is not core to the project.
JSON may not be compact like a binary format, but the human readability is a great benefit. There are also wins in using JSON. To give a hint at what I mean here, Lisp is written as a Lisp data structure. Code is data. JSON is also well defined and has all the necessary elements in it to describe an image.
I do worry about recording all the user input taking up too much memory and creating very large files. I’ll have to do empirical testing to see if that will be the case. The part that will take up the most space will be the free hand drawing. Basic shapes that are part of SVG and Quartz Core won’t present such problems.
Another concern is processing the data fast enough to give the artist the impression that he is manipulating pixels rather than vector data. There is more work here than simply pushing pixels around. Again, I do not know if this will be a problem or not. Humans think in millisecond time scales at best. The CPU clock is clicking away at over a billion times per second. That’s about a million times faster. Also, the typical screen refresh rate is only 60Hz on an LCD display.
I should be able to beat that window.
This is actually an ambitious project I am taking on. There are already programs out there that allow users to do all sorts of fantastic drawings. I’m looking for a different approach that I hope will prove to be advantageous over traditional bitmap drawing programs.
It is perhaps not all that well known that QR Codes were designed to be readable even when damaged. This is a clever feature built into the codes by using error correction to allow for smudges, wrinkles, and other damage to allow the QR Code to still be successfully scanned. This feature has the side effect of allowing the embedding of an image inside the QR Code, damaging it in the process, without seriously affecting the ability of the code to be scanned.
Some people have already taken advantage of this feature. You may have seen it before. I present to you a simple bit of Swift code that I wrote and ran from inside Xcode to create such a QR Code for a friend of mine to advertise his YouTube site. This code can be freely modified as required for your own use. I don’t see a need to copyright something so trivial.
The reason for creating such a large code in this case is so that it can be printed onto a business card, sticker, or what have you without needing to scale up. Certainly there are other ways to do the job. In this case, I’m pretty much treating Swift as a scripting language for a one off job.
The advantage of this approach is that the method for creating such a QR Code using Quartz in an application is very obvious without having to create a bunch of boiler plate code for a proper app. The one downside is that it doesn’t show how you might do the same job in iOS and save the output to your photos. This script runs on OS X.