When I started ReceiptWallet over 6 years ago, I wanted to use the latest and greatest Mac OS X technologies, so I used Cocoa bindings to make it easier to bring the UI to life. Bindings allowed me to write less code and have UI elements updated automatically based on what was selected and other variables. Bindings work great for simple cases, but once things start getting complex, bindings almost become a problem. Bindings are quite hard to debug as there is no one place where you can see all the bindings and one slight change to the code can cause a crash; tracking down the crash can take hours. I had to write custom debugging routines to examine the bindings and eventually shipped a stable product.
Fast forward 6 years. This past week I wanted to write a simple app and choose to use bindings again to link up the user interface. This app didn’t do much, but it took me hours to figure out bindings again discovering that I had forgotten almost all I learned about bindings and the documentation wasn’t much help. My biggest problem was that I accidentally setup a binding for an NSTableView in addition to setting up a binding for the NSTableColumn. Of course, nothing warns you of this and debugging is a nightmare. I’m sure if I started using bindings again I’d get better at them, but with as infrequently as I write Mac applications, I’ll probably struggle the next time I attempt to use them.
Is there a simple guide I’m missing? Should I abandon bindings completely? I have no idea.
Lately I’ve been more aware of developers using NSDictionary where a class should be used. While it may seem easier to use an NSDictionary to store data and pass it around, the lack of type checking and easily mistype keys is prone to failure. Creating classes with a bunch of properties has gotten even easier with the latest version of Xcode; you don’t even have to synthesize properties. Just define the properties and presto, you have a class where you would have used an NSDictionary. NSDictionaries have their place, but in many cases classes serve developers better.
As I’ve written in the past, I have mixed feelings about open source, so I take a close look at a lot of it, especially for some side projects that I have. There is a lot of decent code out there, or at least ideas that I can build on, so I’ve flagged code to look at and cloned a bunch of repositories from Github. The problem I’ve been faced with is that I have a folder filled with open source that becomes out of update quickly and updating each repository is cumbersome. I want to have the latest and greatest so I don’t have to think twice about the code when I go to evaluate it or use it.
Today I had a little time, so I threw together a shell script that walks through my open source directory and updates each repository in it. I could probably set this up us a cronjob, but for now, I’ll run it manually. For all those out there that want to do something similar, here is the script in all its glory!
for i in $(find "/Users/scott/Documents/Development/OpenSource" -type d -maxdepth 1); do
echo "Pulling from: $i"
About a year and a half ago, my manager suggested that I learn Android development, so I played around with the SDK for a few days and then got distracted by real work. Now that my role at work has changed, my manager again encouraged me to learn it and said that I could goto a class if it would help. So, this past week, I went to a class given by Big Nerd Ranch outside of Atlanta, GA. The class was quite informative, I learned a little Java and a lot more about Android than I probably needed to know.
I currently have no plans to write Android apps, but knowing a bit about it should help me better understand the other half and make it easier for me to communicate with my Android counterparts.
The biggest thing that I think is a stumbling block for learning Android is the development tools. Many developers use the Eclipse IDE. Any iOS developer that complains about Xcode, needs to use Eclipse for a day. Eclipse and the Android tools are extremely unpolished, buggy, and hacky. I’ve realized that this is probably the reason I didn’t get very far in the past; I like high quality developer tools and they just don’t seem to exist for Android.
Is it a telling sign that the instructor carries an iPhone?
In Mac OS X 10.6 and iOS 4, Apple added blocks to Objective-C. When I first started looking at them because various APIs used them, the syntax confused me, and I pretty much ignored them as I was still doing work that ran on iOS 4 and Mac OS X 10.5.
This spring, all my projects moved to iOS 4 and Mac OS X 10.6 as the minimum requirements, so I took another pass at learning blocks. This time, however, I could actually use them and read all I could about them. The more I started looking at them, the more I became enamored with them. I started using blocks in my own APIs and just finished rewriting a significant chunk of code using blocks. Using blocks has made my code more readable and has greatly simplified certain aspects of our app.
One of my co-workers cautioned me to not use blocks just because they were the shiny new tool which I admit was what I was looking at doing. However, after using them, we found that using blocks was pretty much vital to making our code more readable.
For developers that aren’t familiar with blocks, I’d suggest learning them. With most iOS apps having a minimum OS of 4.0, there is no reason to avoid them.
It was just over 2 months ago when I released MovieConverter to the world to fill a gap where iMovie for iPad wouldn’t import videos from certain video cameras including my Sony Cyber-Shot DSC-WX9. I had originally came up with the idea for MovieConverter back when I got my iPad 2 and started playing with iMovie. I worked on MovieConverter over the summer and finally released it.
When I installed iOS 5 on my iPad 2, I found that iMovie imported more videos than before, but still not ones from my WX9. I made a few minor updates to MovieConverter to get it working better on iOS 5 and pushed it out the door. I got back from vacation the day after iOS 5 got released to the public and quickly updated everything including iMovie. The iMovie 1.2.2 notes said it added support for importing video from additional cameras.
Much to my delight and dismay, the videos from my WX9 imported into iMovie without MovieConverter. I immediately updated the MovieConverter description to say it may longer be needed and dropped the price to free so that no users would be pissed at me for writing a “useless” program.
From an iMovie user point of view, this is great news. I didn’t write MovieConverter for fame or fortune, but it was nice to get a little money from it.
Oh well, now I have to come up with another idea that will have a little more than 2 months on the app store.
I’m pleased to announce that my MovieConverter app is now available on the iOS App Store. The app is designed for iPad users that want to import and edit video that was taken with a compact digital camera in iMovie.
The premise is pretty simple, but I think it is a huge help to those that don’t want to travel with a laptop and want to edit video.
While I don’t expect to become a millionaire on this, I do hope to sell enough copies to go out to dinner a few times!
Thanks Apple for the fast turnaround on approving this! Total time less than 9 calendar days from initial submission.