mac

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.

Creation Date of flickery 1

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?

flickery 1 crashlog

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

ESSflickr classes in flickery 2

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.

Read more

NewImage

Presenting Yoink 2.0

Screenshot of MarsEdit

 

 

 

 

 

 

 

 

 

 

A picture usually says more than a bunch of words.

What is Yoink?

Yoink is an created to make “drag’n’dropping” files easier.
It shows a “shelf” when you start dragging files or content from applications so you can drop them onto Yoink. This way, your mouse is free for you to move between Finder windows, apps, spaces, fullscreen applications, etc.
Once you are where the files are supposed to go, you can drag the files out of Yoink again to drop them to their destination.

What’s new in version 2.0?

I got a lot of feedback on Yoink 1.0 from customers (thank you very much, by the way) and the changes you see in Yoink 2.0 are a direct result of it.

As you can tell from the image above, there’s a new look – done by the very talented Dietmar Kerschner.

Secondly, you can finally drop content from application onto Yoink – meaning images, text passages or links from within websites, for example. Or files on a server from the FTP client Transmit.

Also pictured in the image image above is a file stack. New in Yoink 2.0, when you drag multiple files onto Yoink at once, they’re not separate items in the list but just one item so you can easily drag them out at once again.

I’ve added a hotkey so you can manually show Yoink’s window so you can drag files from a Dock’s stack or applications like iTunes or Adobe Bridge that don’t trigger Yoink’s window for technical reasons – they use a non-standard NSPasteboard instance to do their dragging duties.

There are four new positions available – left, pinned to the top, left, pinned to the bottom, right, pinned to the top and right, pinned to the bottom (additional to the already existing left center and right center).

Availability and Pricing

Yoink is available exclusively on the Mac App Store for $2.99. But as usual, there’s a free, fully functional 15-day trial available at Yoink’s website (direct download). There’s also a quick screencast that shows exactly what Yoink does, and how it does it.

Feedback Appreciated

I really appreciate your feedback, input and criticism, so please do not hesitate to write me if you have any comments on my apps. Thank you kindly 🙂

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

Read more