Making Progress on ViewDeck 3.0

I took over ViewDeck as a maintainer from Tom about a year ago. Since then not much has happened, it looks like. In this post I want to talk about what I have done in the last year and where I clearly have underestimated the amount of work maintaining an Open Source project like this takes. I’ll then talk a bit about what the next steps will be.

Maintaining ViewDeck

For a couple of weeks now I have taken over ViewDeck as the maintainer of the library. The original author and maintainer Tom Adriaenssen aka @inferis was able to get a Software Engineering job at Apple and therefore is not able to maintain the library anymore. Congratulations on the new job! Tom has been looking for a new owner for some time now. I want to thank Tom for his work on this great library and I hope I will be able to keep up his good work.

I am planning on changing a couple of things in this library in order to lift this very big project which technically still supports iOS 4 to a current set of technologies. My goal is to provide a future proof option to easily integrate a side bar into every iOS project.

Connection Handling in UIViewController

This is the second post in my UIViewController series. This time I want to explain what I think is the best practice to do connection handling in your custom view controller instances.

There are a couple of ways to implement a connection handling in your application and different reasons for an application to load data from the web. If you are for example developing an application like a todo application, you probably do not want to load data in the view controllers at all. A better way to do this would be to have a synchronization manager that does all the loading and the view controllers are only showing the locally cached data. If you are developing one of these apps, this post is not helping you at all. Connection handling is not part of your view controller, but updating your view according to changes in your model is, so you might want to have a look at my previous post about model handling in UIViewController. This post is only about the how and when to load data in your view controllers and how to respond to error events.

Custom Error Handling on iOS

In the last weeks I reimplemented the error handling of the HRS app in a way that is painless and very fast for the developer to use, and gives the user a good, detailed and specific error while even allowing him to recover from certain error cases. The way I did this was basically by reimplementing a concept that is available on OS X for a long time now.

Model Handling in UIViewController

This is the first post in a series of posts about UIViewController subclassing best practices I got used to. This series is about how to write a robust view controller that is as dynamic as possible and can be easily adopted to new technices you might use in your app in the future for whatever reason. E.g. you might have handled you view controller instantiation in code in the past but then decided to do it with storyboards; or you might change your underlying connection handling; or you might change from an NSObject based model structure to Core Data. These are all cases that will end up in a big refactoring of your view controllers if you don’t be careful when implementing them. I did all these things with view controllers that where build with the best practices I am going to describe in this series, and most of the time I didn’t even had to change a single line of code in my view controllers.

An Improved Way to Integrate Reveal Into Your Xcode Project

Oliver Jones had a great article at the Itty Bitty Apps Blog about how to ‘Integrating Reveal without modifying your Xcode project’ that was also featured in iOS dev weekly. Reveal is a great tool to debug layout issues. I highly encourage everybody to check it out. It improves debugging UI related issues like UIView position and clipping or CALayer ordering and really makes your life easier. Oliver’s blog post explained a great way to integrate Reveal into your Xcode project without linking it automatically and without having it automatically starting up during app start. There are a couple of benefits with this approach.

Drawing Buttons With Blurred Background

A glossy looking button is a well known and widely used type of button that everybody knows if he or she hasn’t been on the moon the last couple of years. Apple uses these buttons excessive. In OS X as well as on iOS. Those buttons look nice and they work very well when trying to achieve a polished, three dimensional look. However, they are always used with a background color that differs from the surrounding background or the surrounding background doesn’t have much detail. This is because if you use this button on a background that has a lot of detail, like a photo, they don’t look like glass anymore, at all. The button looks very flat if you can see, that the background isn’t distorted by the ‘glass’ in any kind.

Welcome

Welcome to ios-coding! My name is Michael Ochs, I am an iOS software engineer working in Cologne. This blog will deal with iOS development and things Apple does, from a developers perspective. I am writing about open source projects I use or participate in and about code samples I find useful during my work. I hope you will find useful ideas and tips on this blog and enjoy reading it. If you want to find out more about myself, check out the about page.