One of the things I’ve done several times in my career as a developer is to write color pickers. I was one of the authors of the color pickers in an early Mac painting program Color It! years (and years) ago. Since then, I made a couple freeware color picker components for the Apple extensible color picker dialog that was present in Mac OS 7.x (until it was superseded in Mac OS X by the new color picker panel). After starting at Adobe, I wrote the color picker panel and dialog used in ImageReady (where I included a mechanism for doing web-safe color selection, which at the time was a useful feature). And when Phil Clevenger came to us with a design for a popup color picker for Lightroom version 2, I loved the design (there are a couple fun elements to it, especially if you play with modifier keys while it’s up) and implemented it one weekend.
So, after leaving Adobe last year and founding an indie company named InfinitApps, it was only natural that one of the first things I wrote for myself was a color picker for iPhone and iPad, especially since there isn’t one included in the OS. I used this color picker in my Pyramid 13 solitaire game (it’s used to allow users to pick a custom color for the background and the cards), and I have other apps where I plan to use it eventually.
It had always been my intent to eventually release this color picker as open source, but other things came up, and that got pushed back. However, last month, I had the opportunity to present a short session about my color picker at our local CocoaHeads meeting. In the process, I did a little bit of cleanup, and prepared it for release. Now, it’s almost a month later and the next CocoaHeads meeting is tonight, so I thought it prudent to actually publish the code I talked about last month for all to download, clone, fork or what-have-you on GitHub.
So, without further ado, hop on over and take a look at the InfinitApps Color Picker (InfColorPicker for short). Let me know if you find any problems or have suggestions for improvement (or fork it, make some changes, and send me a pull request if you think the changes would be useful for everyone).
I recently saw a link on Twitter to a blog post on The Practice of Code where Jay nicely details the performance difference between his 2010 MacBook Air 11”, which had a Toshiba SSD (with a 128GB capacity), and a new 2011 MacBook Air 11” fully-upgraded to the i7 processor, 4 GB of memory, etc. which happened to come with the Samsung SSD (256GB in this case). He shows a graph comparing these two machines’ disk scores from XBench both with and without Lion’s FileVault whole-disk encryption turned on.
Well, I also have a new i7 MacBook Air (in my case with the 13” screen size but otherwise configured the same as Jay’s), and I’d been considering turning whole-disk encryption on, so this post was timely.
In my case, I had the “bad fortune” to end up with a Toshiba 256GB SSD in my Air (again — my 2010 Air also had a Toshiba drive). Apple appears to source their SSD drives from either vendor at random, and it has been known for a while that the Samsung drives are somewhat faster than the Toshiba ones.
However, this did provide me with an opportunity to run the tests Jay described on my Toshiba drive and get some numbers that I could compare with his Samsung. Adding my numbers to the ones he gave in his post produces the following:
So the Toshiba drive is in fact somewhat slower than the Samsung, but not by too large a margin. In the sequential and overall cases, it’s almost as fast as the Samsung drive even though it falls behind a bit more in the random access tests.
Also, the 256GB Toshiba in the 2011 Air is faster than the 128GB Toshiba in the 2010 Air by a noticeable amount (I don’t know if this is due to the capacity — perhaps the 2010 Air with a 256GB drive would have been as fast in the non-FileVault case? — or due to a newer model of the Toshiba drive perhaps being used now).
The overhead added by FileVault is similar regardless of drive vendor, as one might expect since the processor doing the work is the same in both of the 2011 cases.
As I’ve used them, I’ve never noticed the Toshiba SSDs feeling slow. Regardless of brand, an SSD holds clear advantages over a spinning-disk-based drive, so I’m happy to have one in my laptop. Still, it’s nice to know that I’m not sacrificing too much performance due to the make of drive my machine happens to contain, and it’s also good to be aware of the overhead FileVault incurs.
I just signed up to do one of four small talks being given by people at our local Minneapolis/St. Paul CocoaHeads meeting next month (in two weeks, on August 11). There’s less pressure due to the reduced time allotment, and I thought I had something that would be just interesting enough (I hope) for a smaller talk like this.
I’m going to be showing code for an iOS color picker I wrote last year. I’ve always meant to publish it as open source for others to use, but I’ve never quite found the time to do the extra work necessary to polish and publish it. This talk will be my opportunity to do that, so the color picker will be made available that day (or the next).
I use Mercurial and BitBucket for my own projects, so it’s tempting to publish it there, but it seems that GitHub has a much wider reach when it comes to this kind of thing, so that’s probably where I will end up putting it.
If you want to check out my color picker and how it works in an iOS app prior to my releasing its source code, download my Pyramid 13 app from the App Store. You can access the color picker by going into the Settings view and picking a custom color for the card backs or one of the first few wallpapers.
I did this initially to scratch my own itch for a better version of the game than I had seen in other multi-solitaire games and a couple of the other dedicated Pyramid games I had tried from the store already. I wanted to make a game that felt more like a native app than many games tend to. I wanted it to be fast to launch, support all the modern things like multitasking (I’m actually often amazed how long it will stay “running” while in the background — days at times on my iPhone 4) and high-res Retina graphics, have simple sound effects (though no music track, but it does allow you to keep playing your own music while playing the game). Also, it’s pretty friendly to the battery, especially for a game.
It was a part-time effort, as I was also working on a couple other apps during the time and getting my indie development company, InfinitApps, in place, registering it with the state as an LLC, getting a bank account, and so on.
In the process of building this game, I decided to try something that’s (probably) somewhat novel for a game, which is to use high-level UIKit code (that’s the Apple framework used for most apps with standard UI elements) for all of the UI. I didn’t use OpenGL or even CoreAnimation directly, but rather I used the animation APIs available in iOS 4 for all of the card animations, including the card flip-and-slide. This worked well (probably better than I expected it to), and it was pretty quick to get the initial playable game working.
Of course, it then became an issue to see how I could make a game worth selling, and I spent quite a bit of time doing the other things that I thought would help set it apart.
I created a few different card styles, including the default one which I think is a nice addition to the landscape for playing Pyramid solitaire: it uses numbers rather than face cards for 11, 12 and 13, thus making it more accessible to younger kids. This one also is more friendly because it color codes the cards not along suit lines, but rather based on the pairs of cards that add up to 13, so 5 and 8 have the same color (and same-colored icon) for example.
I also have a traditional style that uses suited cards, and I threw in a fun one which has hexadecimal and binary numbers on the face. I also played with a couple other styles that I ultimately decided to leave out of 1.0 in order to ship it.
I also wanted to include multiple backgrounds, as the background gets more visible as the cards are removed from the board. Then it was natural to be able to use your own pictures or favorite color for the background or card back. Since I had previously built a color picker for iOS (more on that in a future post, as I hope to release it as open source soon), I included that as a way to change the color of the built-in card backs and some of the backgrounds. For the photographic card backs, I fortunately have a wife who is an accomplished photographer, so she provided me with the better-looking ones.
I also spent the time needed to add Game Center support. This included having a scoring system to let people compare scores based on how far they got in a game. Also included are a handful of achievements (13, naturally) that can be earned as the game is played.
Game Center support turns out to be a bit more involved than one might at first expect due to some choices made in the API and the number of things left to app developers, but it still seems worth the effort to get the additional network effect that is possible with groups of friends playing the same game and comparing results.
One of the things that Game Center achievements require is artwork, so I worked with a designer/artist (who is a friend of mine) to create those, along with the app icon and the stylized card back.
Finally, as I was looking at Pyramid 13 on my iPad one day, I was unhappy with playing the game zoomed up to 2x. Apparently, it is possible to get artwork rendered in high resolution when zoomed up like that (both Trainyard and Carcassonne, even prior to the iPad version coming out last week, would show at least some of their graphics in high-res when rendered in 2x on the iPad). But instead of doing this, I decided to just take the extra time and rework my code to support the iPad natively. This means that when searching for iPad or universal apps in the app store, my game will appear, and it’s a better experience anyway. It fills the screen, and it allows playing while holding the iPad in either orientation (when used on an iPhone, Pyramid 13 is a portrait-only game).
I’m pretty happy with the result. It’s a fun game that I still enjoy playing (even after play-testing it quite a bit for the last few months). I like seeing where I rate relative to my friends and others in Game Center, and it’s nice to see other people, including my mother-in-law, brothers-in-law, sisters-in-law, wife and daughters all enjoy playing it.
Of course, I have plans to make improvements in the future. I want to make the end-of-pyramid experience a bit better with improved graphics and feedback. The toolbar graphics could probably use some tweaking. And there are a couple small bugs I noticed after submitting it. I’ll probably do a 1.1 update to address these (and any other problems that might turn up now that more people are using the app) early next year.
Longer term, I have a couple other card styles I could finish and include, and there are some other Pyramid game variations that could be fun. Of course, I also have other app ideas that I want to dive into, so these other ideas will depend somewhat on how successful Pyramid 13 is in the App Store. Also, I’d be open to localizing it into other languages, but that’s not something I’ve had time to investigate yet.
I’ve also considered doing a Lite version that would remove most of the customizability (but not alter the basic gameplay) and include iAds. This would allow me to release a free-but-ad-supported version, so that could be interesting to pursue.
Looking at iOS Fonts today (via Daring Fireball), it occurred to me that some of the extra fonts that appear on the iPad are actually used in various Keynote and Pages templates. So use with iWork (and other such creation apps) is probably one of the reasons the iPad has more fonts installed with the OS than the iPhone does.
As I was looking into this, I went into the custom font list that’s available in Pages and noticed some of the font families included styles that weren’t listed on the iOS Fonts page.
So, I decided to write an app that would enumerate the fonts on my iPad. What I found initially, by using the UIFont API to get a list of family names (and the font names from there), was a list similar to what iOS Fonts showed, which didn’t include all of the styles visible in Pages. I then went to the CoreText API to see if there was a lower-level API that would provide them all and found CTFontCollectionCreateFromAvailableFonts. Using this, I enumerated the available font descriptors, and it includes several fonts that are not in the UIFont-provided list.
On my iPad running 4.2 these “extra” fonts are:
So, it’s clear that there are some additional fonts available (and usable) compared to what the high-level UIFont API reports.
A couple of these are obviously omitted intentionally, such as PhonepadTwo and LockClock-Light, as they are used for various UI elements and not meant for end-users.
Most of the others are additional styles of other existing fonts, including Condensed styles and weights like Light, Semi-bold and Black. It’s interesting that they are not listed when using the higher-level API. Perhaps there’s another manner in which they are meant to be accessed.
FWIW, while looking at this, I found an free app in the App Store named Typefaces that shows a list of all the fonts on the system, including the “hidden” ones and the extra styles listed above. It also shows previews of the fonts and has a glyph list, for the interested.