Phew, long time no post, eh? Sorry ‘bout that. Recently, I’ve really been delving into some of the depths of Core Animation. I gotta tell ya’, Apple really hit it out of the park with Core Animation. I have no clue what Android or some of the other mobile platforms have out there, but if it’s not close to Core Animation, then it’s a fail. Anyway, I ran into an interesting “issue” involing Core Animation’s automatic removal of animations added to layers.
I started downloading a video from Path the other day, and it presented a bezel UI to indicate the download progress. As videos (and other large files) can take a while to download—especially over 3G—I wondered if Path even handles the case where the user would want to cancel the operation. Sure enough, they do, so props to Path. Tapping on the screen (or otherwise trying to interact with the app during a download) presents a cancelation action sheet. While seemingly insignificant, these types of interaction capabilities are important. The user isn’t always going to be under lab-tested conditions with super fast Wi-Fi. And while offering an “escape plan” isn’t a replacement for thorough testing under a variety of use conditions, it’s a great catch-all for instances where things just don’t go as planned… Or for where the user is just impatient, which is almost certainly the most common occurrence.
Updated 02/23/2012: Corrected “Positive/Negative Values”
Lately, I’ve been on a kick where I try to make my code more meaningful at a semantic level. I spoke a little about this in a previous blog post, but I wanted to point out a few more examples of things I’m doing to allow my code to read more like prose and less like programmer’s rhetoric. Most (if not all) of these are very trivial, but the purpose of these modifications is to expose more semantics. And it’s more of an experiment to see how my code changes—hopefully for the better. This blog post will be updated over time as I encounter new examples.
Most (if not all) of these semantic modifications are available in LTKit.
Last time, I spoke a bit about KaraokePad, a fun side project that I’m working on. Well, a new job and a new year have put that project on hold slightly, but I think about it constantly, so I’m going to pick it back up just as soon as things settle down again. In the mean time, though, I wanted to chat a bit about LTKit. It’s quickly becoming the portable tool kit I bring from project to project and fill with useful categories and classes. Well, not so many classes these days, mostly categories. Still, I created one view class for KaraokePad that I call LTKProgressSlider. It’s nothing monumental, but I think it’s a handy view that replicates the look, feel, and function of the progress sliders that Apple uses in its various media playback UI on iOS.
Today, I’m starting a new thing I’m calling my iOS Dev Journal. In an effort to blog more often (and in smaller pieces), I think a dev journal will be useful in gathering my thoughts about what I’ve worked on recently, what problems I’ve encountered, and what I hope to work on next. Plus I haven’t really blogged that much about iOS development, so hopefully this will beef up the content interest for my fellow developers. :)
Anyway, let me kick off the New Year a bit early with my first dev journal entry…
Paper cuts hurt, sure, but they aren’t fatal. However, what happens when you receive hundreds of paper cuts? Well, actually, I’m not sure, but I imagine you’d be in a lot of pain. And suddenly, something that isn’t particularly harmful on its own becomes painfully obvious. This concept ties in well to software engineering, especially to front-end software development.
Well, it took me long enough. Sorry. I’ve been extremely busy with some contract work lately. Also, the whole “I’m 15 years behind the times when it comes to web front-end development” thing didn’t help. Octopress is very well organized, but even still, I had no clue what SASS was or how to find what I needed to modify the default theme. It’s still not 100% finished, but the bulk of the major site architectural changes are good to go (I think). I’ll be tweaking typography, colors, and other such things until it’s just right. Now that I’ve overcome this hurdle, I can get back to blogging, hopefully much more regularly.
I launched Time Machine tonight by mistake, but before I could close it, a strange, sad feeling came over me. This is the only way I can express it:
Update (11/19/2011): Thanks to the wonderful Erica Sadun of TUAW, who tweeted about this pic, I received over 23,000 page views in less than a day. It’s awesome to be able to spread my heartfelt appreciation of Steve to the world.
I often get asked how to show something like a branding splash screen when an iOS app launches. While I think this is, in general, a bad practice, there are occasions when showing a quick intro screen can be appropriate. Or maybe it’s not a splash screen at all but something more like a user login screen. Especially to those new to the iOS platform, these kinds of tasks can be problematic.
The best part about Apple is that their products are gorgeous. The worst part about Apple is that their products are gorgeous.
One of my favorite parts about being an iOS developer is the opportunity to create amazing User Interfaces. I love nothing more than taking an awesome designer’s PSD and actualizing it on the iPhone or iPad. One my least favorite parts about being an iOS developer is…programmatic view configuration. It’s painful, it’s tedious, it isn’t always immediate obvious what’s happening, and it just bloats class files with a lot of extra cruft. In general, I dislike lots of boilerplate code, but this is especially true about setting up a complex view hierarchy entirely in code. So how do I minimize the inevitable impact of configuring views programmatically?
The other day, I needed to find parking in downtown San Francisco. So I checked out the Parkopedia iPhone app. It was…pretty bad. Aside from the ho-hum design, the user experience was confusing and frustrating. I found a parking spot but not without much hassle. According to its 2-star ratings, it seems like the rest of the (app) world agrees with me. Today, however, I checked out their website. And boy, was I surprised. The UX was pretty darn good! The web app looks clean and polished. I mean, it’s probably not going to win any Apple Design Awards, but it’s still good.
If you don’t know already, Final Fantasy Tactics is my favorite video game. Ever. In my opinion, it’s the epitome of the TRPG sub-genre, perhaps even the RPG genre itself: amazing story; outstanding music; hand-crafted, sprite-based graphics (major win!); deep gameplay; and lots of replay value. You should play it if you haven’t already. Anyway, I’ve been replaying it recently on my PSP—a custom PSX EBOOT version of the original game including the amazing Final Fantasy Tactics Complete patch.
I’ve been working my butt off to get a theme set up for Octopress. Well, let me rephrase that: I’ve been working my butt off trying to redesign my theme from LucasTizma.com. I’m going to stick with the overall look, but the main body layout is being reworked a lot. I have a good idea of what I want the site to look like overall, but my Photoshop skills are limited.
Octopress was mentioned to me by a friend, Jake Boxer. It’s a dead-simple blogging engine made specifically for coders, hackers, et al. Well, sort of. Even though I would consider myself a technical person, I don’t know too much about the Ruby ecosystem, which Octopress relies on. Even still, it only took me a bit of hacking and a good deal of Googling to get everything up and running on Mac OS Lion.