UIAlertController as a Replacement for Single Column UIPickerViews displayed in UIActionSheets

Apple deprecated UIActionSheet in iOS 8 and now requires the use of UIAlertController instead. UIAlertController adds some really great new features and I think it is a good step forward but it does break backwards compatibility with some older apps in certain cases. One specific case, that I'm going to address in this post, is the presentation of a UIPickerView in a UIActionSheet.

Displaying a UIPickerView in a UIActionSheet was a quick way to allow the user to select one item from a list of multiple items. This was an especially helpful approach because it allowed for the display of UIPickerViews in the same fashion as the iOS keyboard. Users didn't have to learn a new way to interact with UIPickerViews.

Now that UIActionSheet is deprecated there are a number of approaches available to recreating this interaction.

  1. You could add the UIPickerView to your screen and modify AutoLayout constraint constants to slide the view on and off screen.
  2. If you have the ability to target only iOS 8 and above you could build your own reusable UIViewController and display it modally with the presentation style UIModalPresentationOverFullScreen.
  3. Or, if you only need to display a single column of data for the user to select from you can use the following UIAlertController approach that is quick and easy to implement.

UIAlertController can only display buttons and text fields, but it can display a lot of them! We can use this to our advantage.

The first thing to do is setup an Array that will act as the labels for the buttons in our UIAlertController.:

NSArray *items = @[@"Unfiltered",@"2015",@"2014",@"2013",@"2012"];
self.data = items;

The default behavior of UIAlertController requires that we attach a block to each button that will be executed when it is clicked. We will use this feature to make this work more like a UIPickerView. To do this we want to be able to reference these buttons by index once they are selected in the UIAlertController. UIPickerView has a method called selectedRowInComponent: so let's emulate that. Since we only will have a single column of buttons (that's all UIAlertController supports) we can ignore the component piece. The following example will set the text of a label based on the index of the button pressed.:

-(void)didSelectRowInAlertController:(NSInteger)row {
  self.outputLabel.text = [self.data objectAtIndex:row]; 

Since blocks capture their enclosing scope we can use a counter variable to represent the index of each item in our list of button titles. To do this we can loop through our list of button titles, increment our counter variable by 1 each time, and then attach a block of code to each button that calls our didSelectRowInAlertController: method and passes in our counter variable as a parameter. Here's how this piece looks. I've included the entire viewDidLoad method for clarity. You can find this full project and code on Github.:

-(void)viewDidLoad {
   [super viewDidLoad];
   NSArray *items = @[@"Unfiltered",@"2015",@"2014",@"2013",@"2012"];
   self.data = items;

   int i = 0;

   UIAlertController *alert = [UIAlertController 
     alertControllerWithTitle:@"Filter Data"

   for (NSString *item in items) {
       UIAlertAction* defaultAction = 
       [UIAlertAction actionWithTitle:item
                              handler:^(UIAlertAction * action) {
                                       [self didSelectRowInAlertController:i];

       [alert addAction:defaultAction];
   self.filterView = alert;

What's nice about this approach is that it is quick, the code is simple, and it is a reusable solution. I also really like that this works like the older UIPickerView approach which may make this a solution that more easily integrates with legacy code bases that require updating.

The biggest drawback to this approach is that you have to use Apple's default UI for the AlertController but I don't see that as a big deal. This is a great time saver so you can get your app shipped.

Here's what it looks like in the simulator.


Lego Duplo Apple Watch Stand

Since the Apple Watch has to be charged every night I figured that using it as a clock on my nightstand would be a good way to get some utility out of the charging process while I sleep.

After messing around with how to best set this I up I searched for Apple Watch stands and found a ton of options that will be shipping soon. Many of these stands are very cool looking but the biggest drawback is that they are all really expensive. While this seems like the perfect time to justify the purchase of a 3D printer I wanted to try and come up with an inexpensive solution. I have already spent enough money on the watch.

After some digging around I was able to replicate The Griffin WatchStand with Lego Duplo blocks and a small amount of 2-sided tape to hold the charger to the angled block at the top of the stand. Since I already owned the blocks this solution cost nothing. I may widen the base and adjust the color scheme a bit but overall this solution has worked well so far.

iOS Device Fragmentation, Responsive Design, and Your Team

On Wednesday, July 23rd I had the pleasure of co-faciliting an iOS discussion with Ben Shive at Venturef0rth in Philadelphia. Many thanks to the awesome people at Venturef0rth for this opportunity! The discussion was very casual and focused on how iOS 8 would impact new and existing app development. Chairs were arranged in a circle, there was no slide deck or projector, and the topics flowed from one to another based on the interests of the group. I really enjoyed the discussion and I hope that it was useful to those in attendance. It was also really great to meet a lot of new people. Philly's tech community is amazing and only growing stronger.

During the discussion I got to thinking about two things related to the rumored addition of new screen sizes to Apple's device line-up and iOS 8 app development in general.

  1. Android developers have been dealing with device fragmentation for a long time. There's a lot to be learned from their experiences. iOS dev teams would be smart to bring in some experienced Android developers for consulting on this matter to more quickly adapt workflows. I also think there's a good opportunity for Android developers looking to expand their skills into iOS development to do so based on this experience. They could be immediately productive on an iOS team by aiding in process improvements and UX design (related to varying screen sizes) while ramping up their iOS dev skills.

  2. Responsive web designers also have a lot of valuable experience to help guide UX and UI design across multiple screen sizes. If you're on an iOS team that primarily builds native apps with Apple's tools you may need to seriously think about bringing in some help in this area. I'd imagine that teams working on HTML 5 based app platforms will be much more well positioned in this area.

One of the biggest take-aways from this discussion, for me, is that iOS teams should seriously consider hiring experienced Android and/or responsive web designers to help consult on existing design and development workflows. There's no reason to build this experience from scratch and your team will be able to more quickly meet the needs of your clients or app's audience.

Philadelphia Code Works

I recently started a software company called Philadelphia Code Works with 2 other developers. If you or your company have an idea for an iOS, Android, or Web application, need on-going software maintenance services for an existing product, or need to update an existing mobile or web application we can help! Feel free to use the Contact form on our web site if you have a project in mind or questions. Thanks!


Glider Excel: Impostor Syndrome

I am happy to announce that there is a new Glider Excel album available! The album is titled Impostor Syndrome and is comprised of 7 songs in just under 16 minutes.

You can stream or download individual songs on the Impostor Syndrome album page for free. If you like the album and want to support future Glider Excel recordings you can purchase the album for $4 from GumRoad.com.

Some background. Glider Excel is the name I use for my solo music projects. I wrote and recorded the first Glider Excel album in 1996 and then did some additional recording again in 2002. Most of the songs recorded during this period are unreleased but served as a great learning experience for me. Some of the songs from the 2002 recording session are available on the Demos 2002 page in the Glider Excel section of megawertz.com.

Impostor Syndrome is the first of what I hope to be one new album every year or so. Let's see how long I can keep this up. I hope you like it. I had a great time writing and recording it.

New Order at the Mann Center for the Performing Arts, July 26th 2013

I've been a fan of New Order since the mid 1980s yet it took me until I was almost 40 to see them in concert. It was worth the wait. New Order's show at the Mann Center for the Performing Arts in Philadelphia on Friday, July 26th didn't disappoint.

The band was solid and they played a great selection of hits from across their 33 year career. The biggest "surprise" of the night was an encore composed entirely of Joy Division songs. It was wonderful.

Two things struck me about the show.

First, the final song of the night was Love Will Tear Us Apart. Of all the Joy Division songs New Order played during the show, this was the best. How good? I think they should release it as a New Order single. Bernard's voice fit perfectly into the song and the minor improvements made by the band gave the song a tight and modern feel. I realize that New Order gets touchy about being seen as "selling out" their Joy Division roots but I think they could release this single in a way that didn't compromise their values. Maybe they could donate all proceeds to epilepsy research in the name of Ian Curtis or give money to Ian's family. Again, the New Order version of this song was flawless and really deserving of a new release. It was that good.

Second, and it's a BIG second, was the absence of Peter Hook. Anybody that has ever heard my bass playing knows that Hook is a major influence on me. I taught myself to play bass by playing along to New Order albums. The falling out between Hook and the rest of the band has been hard for me to watch but I don't really come down on one side or the other. The fact that any band can keep it together for as long as they have is a miracle and conflicts of personalty are expected. I like New Order, I like Peter Hook. I am sad that he's no longer in the band but I don't harbor any ill will or anger towards the rest of the band or Hook regarding his separation from the group.

So, did Hook's absence effect the show? Sometimes. Tom Chapman, Hook's replacement, is a great bass player. He was tight...and that's the issue. Hooky is great, but he's a bit sloppy. That sloppiness is part of his sound. I'm not saying Hook is a bad bass player (he is my all-time favorite bass player), I'm saying that he plays loose and that looseness is part of his unique style. There were songs were Chapman stood out by being too tight. I felt that The Perfect Kiss and Age of Consent were examples where the notes were correct but the expression of the bass playing was noticeably not Hook. These are bass driven songs, that I play along with regularly, and so it makes sense that these might sound a bit off to me. It also might be that only a handful of people noticed any difference and nobody else cared.

The best song of the night, and my vote for best New Order song ever, was Temptation. If you know anything about this song you know that New Order worked this song out over time. Recordings from the early 80s show how it took them a while to get the lyrics and structure down. The 1998 version of Temptation and the current tour version of the song show that it is still evolving. Because of this, Temptation is a song written by the entire band and it feels that way. This was the last song New Order played in their regular set and it was the best. Everything gelled, the energy from the band and the crowd was high, and the song was flawless. This was a case where Chapman's bass playing fit perfectly with the band.

I had a great time at the show and I would definitely go to see them again if I get the chance. I'm also looking forward to their new material (even though I really don't like The Lost Sirens but I guess that's another post). Peter Hook is playing Philadelphia with his band The Light in September and I may go see him to round out my New Order experience for the year. When I discovered Brotherhood in 1986, and started my life-long obsession with the band, I would never have believed that 2013 would be my year of New Order. It's been a great year.

Date-Only Pebble Watch Face

I wanted to take some time to explore the Pebble SDK and so I built a very basic watch face that only displays the date. Since the Pebble makes it easy to scroll through the installed watch faces I thought it made sense to have one that only displayed the date and could be used as a modal view for a time-only watch face. The date-only view is also nice if your day is dragging and you catch yourself constantly looking at the time.

The code itself is very simple and based on the code from one of the default watch faces that come with the device. The real goal for me when building this watch face wasn't learning the SDK but, instead, setting up and testing the development environment. I'm working on a review of my Pebble experience both as a user and a developer that I hope to post soon. I'm also working on another watch face with the goal of digging a bit deeper into the SDK (but not too deep, I've already spent way too much time hacking around with the watch).

Download the watch face pbw file

Source on Github

The Paradox of Node Module Choice

Update: @ginger_beered points out that I could simply wrap the modules that concern me. This is a great, and simple, solution to my issue. For some reason, this wasn't obvious to me. I still think my post stands. I love the large selection of modules but I need to build more confidence in myself as a Node developer and gain more experience interacting with the community so I'm not wrapping every module I use.

I'm slowly building a web service in Node.js and learning to work with Node as I go. The most interesting part of this process for me has been seeing how the community works and how new developers are on-boarded through documentation and other materials. There are a couple of general observations I've made so far.

  • I don't remember anything about Javascript syntax or library functions. I'm guessing I never actually learned these things very well to begin with. I wrote a lot of client-side Javascript around 13 years ago but I probably did more copy-and-paste coding than anything else at that time.
  • The process of writing Javascript code hasn't really changed too much even though I'm writing server-side. Write some code. Restart the server or clear the REPL module cache. Check the results. Rinse and repeat. There may be better tools for developing Node apps beyond a text editor and the terminal but I haven't looked. I'm not complaining (too much), I'm just spoiled by IDEs.
  • Do I call it Node.js or just Node? Do I capitalize Node?
  • NPM is magical (except when it isn't) in the same way that APT feels magical on Linux. I have no complaints about NPM itself and, despite what I'm about to say, I plan on publishing some of my own modules.

My biggest issue at this point has to do with the sheer quantity of modules available for Node. I want to pick well maintained highly-used modules that will have minimal bugs and maximum performance optimizations (who wouldn't?). Since I plan to build a service that I will charge money to use I'm extra concerned about the reliability and maintainability of my codebase. As a new Node developer I'm having a hard time differentiating the good modules from the bad modules based on my criteria.

"Autonomy and Freedom of choice are critical to our well being, and choice is critical to freedom and autonomy. Nonetheless, though modern Americans have more choice than any group of people ever has before, and thus, presumably, more freedom and autonomy, we don't seem to be benefiting from it psychologically." — quoted from Ch.5, The Paradox of Choice, 2004 via Wikipedia

I'm currently using Express for the core of my app, PG because I'm using Heroku with Postgres, and several other standard built-in Node modules. I don't see myself going much beyond that in terms of community-built modules. I think I've identified a pretty good bcrypt module based upon the number of recent downloads, dependent modules, and Github activity. I hope to have the bcrypt module integrated into my app shortly and I'm curious to see how that goes. Maybe it's just me, but I'm finding it hard to evaluate modules and feel good about my choices with my limited Node experience. I wish choosing every module was as easy as choosing Express.

There are some strong aspects of the Node module ecosystem. It's great that I can fork a module and continue to maintain it as long as I need into the future. I'm happy to contribute bug fixes and updates to modules where I think I can be of help. I love the strong role that Github plays in the Node community and I already mentioned how great of a tool I think NPM is.

With that said, I'm getting older and the idea of needing to maintain a library that falls out of favor is not where I want to focus my energy. I also don't like the idea of needing to constantly refactor my application to accomodate the new module-of-the-month if there isn't some level of stability in a given category. I would rather pick a strong codebase that appears to have a long life ahead of it and put my time and energy into building my product. I would prefer a library system that supports longevity and promotes quality modules with the most potential for stability. Maybe the Node ecosystem does this already and I just don't have the experience to see it yet? Maybe the process I used to choose a bcrypt module is the way I'm supposed to pick all modules? Maybe there is an opportunity for a company to write Node modules that are closed-source, well maintained, well documented, and supported for the long-term? Maybe I just haven't participated in the Node community long enough to trust the community? Maybe I'm missing something obvious? I'm usually missing something obvious.

What I'm Reading: Wednesday, May 1st

  • The Icarus Deception by Seth Godin
    This is the first Seth Godin book I've ever read. Over the years I have read a lot of things on his blog that were promoted in tweets and posts by almost everybody I follow online. I'm not sure why it took me so long to actually read one of his books. This book is well written and inspiring. I have thought similar things to what Seth writes about in The Icarus Deception but I was never able to clearly articulate those ideas. Seth is a great writer and has really helped me to open my mind to a number of new ideas and clarify many ideas that I was still trying to process.
  • The Manga Guide to Linear Algebra by Shin Takahashi & Iroha Inoue
    I teach an introductory course in game development to second year students where I work. It has proven to be a challenge due to the fact that many of them are not very far along in their mathematical studies. I don't believe that you need a couple of semesters of Calculus to learn Linear Algebra and I think I do an OK job of teaching the basics. I've never been able to find a book that was able to work in the context of this course until now. I'm going to test The Manga Guide to Linear Algebra as a textbook, along with the Unity 3D programming book I use, in the Fall 2013 semester. I think it will help students to more quickly grasp these concepts and gain a deeper understanding of the subject matter. If I remember I'll be sure to write a post-mortem after the course is over about how well the book served the needs of my students.

Node - The Very Beginning

I'm in the process of building a web service that will eventually serve a mobile app I plan on writing. I'm building the service on Heroku using Node.js.

I chose Heroku because I want to explore using a hosted development environment and I really don't want to spend time administering servers when I can be writing code. I chose Node because it seems to be popular and because I want to give Javascript a second chance.

Over 12 years ago I completely wrote off Javascript and promised myself that I would never write another line of it. I really hated the language (but I loved Perl and still do, go figure). A lot has changed in that time. Lately I've been doing a bunch of game scripting in Unity 3D using Javascript and it has been enjoyable. I have also been warming to a more functional style of coding and Javascript gives me a nice, practical, playground to explore that a bit further. In retrospect, what I hated most about Javascript wasn't the language but the amount of work required to deal with cross-browser compatibility issues. Node let's me play with Javascript without the confines of the browser.

I will be posting lessons learned, observations made, and possibly some tutorials as I work my way through the process of building this service and learning a new development stack. Hopefully these posts will be of some use to somebody.

First Lesson

I was in the process of installing the PostgreSQL module pg for use with Heroku. My main development machines are currently OS X. In the process of installing the module I got a bunch of errors related to node-gyp.js

gyp ERR! build error 
gyp ERR! stack Error: not found: make
gyp ERR! stack     at F (/usr/local/lib/node_modules/npm/node_modules/which/which.js:43:28)
gyp ERR! stack     at E (/usr/local/lib/node_modules/npm/node_modules/which/which.js:46:29)
gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/which/which.js:57:16
gyp ERR! stack     at Object.oncomplete (fs.js:297:15)
gyp ERR! System Darwin 12.2.1
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /someDirectory/SomeWhere/node_modules/pg
gyp ERR! node -v v0.8.19
gyp ERR! node-gyp -v v0.8.4
gyp ERR! not ok 

In the end it turns out I did not have the Apple command line developer tools installed. This might sound like a simple mistake, and it is, but since Xcode has moved to a single application bundle it's pretty easy to forget that the common developer tools aren't readily available to the wider system.

To resolve this issue launch Xcode, then select Preferences -> Downloads -> Components and install the Command Line Tools package.

I realize this might seem like an obvious solution but I'm guessing I'm not the last person that will run into this issue.