As I am now back working on flickery after a short hiatus – sometimes you need a little distance from a project to be able to reflect on it and maybe get a new perspective on some things, I figured I’d talk about the process as I am working on it, not after, in a so-called “post-mortem”, as my memory is now fresh and “in medias res”.
Before going into about what’s coming though, allow me to go back to see what’s been.
A New Beginning
Starting from scratch is usually admitting to having screwed up before. In flickery’s case, I wouldn’t say I screwed up completely. I am, however going to say that I could have done some things better. In some parts, a lot better.
I started developing flickery 1.0 in early 2008. That’s a long time ago. I’ve become (I hope) a better programmer with a deeper understanding of how things work and are supposed to work. I have (a lot) more experience in Cocoa and a better understanding of UX and UI. I don’t let myself get away with things that work ok but could be better that easily anymore.
This is a good time to start from scratch.
Why start from scratch?
They say the way your desk looks, your mind looks. If you apply that to the code base of flickery 1.x, you’d commit me. It is not a pretty sight.
It’s really hard to look at, it’s difficult to follow and understand… it’s a fine mess, to be honest.
So one part of the reason why I started from scratch is that I didn’t see the forest for the trees (the app for the code) anymore.
Additionally, things have changed a lot in OS X since 2008. Which makes version 2.0 a good point to get rid of all the legacy code (individual code paths for OS X Leopard and every iteration that came after) and create clean code for OS X Mavericks and newer. (Mavericks is a no-brainer, it’s a free upgrade, everyone should go and get it.)
There’s blocks, ARC and Objective-C 2.0, just to name few. Going back to flickery 1.0’s code and re-working all the parts might very well have taken just as long (if not longer) as starting anew. It was totally worth it.
New Back-End
Absolutely essential for flickery is it’s communication with flickr’s API. Incidentally, in flickery 1.x, that was the #1 cause of crashes and bugs.
I’m not going to tell you how I did it back then; it’s just too embarrassing.
This time around, I’m not making the same mistakes again (all the while hoping I’m not making any new ones).
Let’s just say, in the old backend, I handed NSDictionaries et.al. back and forth. I didn’t use any XML or JSON parsing, I did it all with NSString’s rangeOfString, etc., not always checking if a range existed before working with it. As I said – embarrassing.
So the first thing I did was switch from getting XML from flickr’s API to JSON and not parsing it myself, but letting the system do it. That’s a huge load off my mind right there.
Secondly, I’m done with handing NSDictionaries, NSArrays, etc., around. The new back-end returns proper objects that contain the necessary info in an easily accessible and understandable way.
There are a few Objective-C wrappers for flickr’s API out there, but I didn’t like any of them. They let you do this (pseudo-code)
NSDictionary *responseDict = [SomeFlickrWrapper executeMethod:@“flickr.photos.search” withParameters:someDictionary];
Aside from also handling OAuth and signing methods, etc., this is all they let you do. So you have to remember the methods, the parameters – it’s really not a wrapper, it’s an access point to the API.
What makes my back-end different is this:
- (ESSflickrGallery *)createGalleryWithTitle:(NSString *)title
description:(NSString *)description
primaryPhoto:(ESSflickrPhoto *)photo
error:(ESSflickrError **)alert;
You call the method and the back-end does all the parameter and method stuff for you. It’s much neater. In this example, you can also see the use of custom classes instead of dictionaries. ESSflickrGallery, ESSflickrPhoto and ESSflickrError are all wrappers for responses from the API, neatly packed up in an easily accessible class.
I guess I could have used one of the available back-ends as a back-end for my back-end, but I figured, if I’m going through the trouble of matching all available flickr-API-methods, I might as well do the OAuth and signing stuff myself as well.
This new back-end doesn’t only make things easier to develop, read and understand, it also improves the app’s stability and performance (mostly because it’s easier to develop, read and understand 😉 ).
As you can imagine, this has taken up the most time up until now. Now comes the fun part of using it to create the next version of the app.
I hope you’ll enjoy this upcoming series of posts about the development of flickery 2.0 and some of the design decisions behind it.
Upcoming in Part 2
In part 2, I’ll talk about uploading to flickr with flickery 2.0. Lots of suggestions will make it into the new version 😉
Thank you for reading. Enjoy your day!
My name is Matt, and I’m the developer of Eternal Storms Software. You can follow me on twitter here.
