Nick Harris


leave a comment »

Rudy Lacovara’s Smart Guy Disease post is a fantastic read. I’ve encountered many of those situations myself, but when you think about it in the context of Scott Hanselman’s Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE, I think it brings the overall problem more into focus.

I don’t believe that smart, seasoned, experienced programmers create overly complex solutions because they want to appear smart (though admittedly some I’ve met have). I believe Scott’s answer that we over-analyze problems, then over-architect the solution is the real culprit.

When I’m starting on a new piece of code, I often find myself thinking through and solving issues that will most likely never occur. Its a hangover effect from some bad situation I ran into previously that I simply want to avoid again.

For myself, a combination of the solutions from both posts is the best.

YAGNI – Ya Ain’t Gonna Need It

You’re a seasoned, experienced programmer who has seen many pitfalls and issues. That’s awesome. Use that experience to evaluate the actual problem you’re solving now and potential pitfalls that are eminent. Forget the rest. If / when they become problems you can solve them then. You already know how to solve them, but why complicate the problem at hand.

KIS – Keep It Simple

Simple code is easy code. Easy to learn. Easy to maintain. Easy to transfer. If you can’t explain your solution to a programming problem by pointing to well known and accepted coding standards, you most likely over thought the problem and out thought yourself. I love the standard Rudy has:

…your boast should be that your architecture is so well designed that any junior developer can come in off the street, understand the basics in a day or two, and be productive within the week.

That standard is my idea of true programming expertise. Been there. Done that. Made it simple.

Written by Nick Harris

April 3, 2014 at 4:43 am

Posted in Uncategorized

Full Stack App Developers

with one comment

I enjoyed reading Justin Williams “The Parts of Your Platform”. It’s a good rundown of how an indie developer (or small team) can leverage the tools available to them in todays world to build every layer of a software product. What’s more interesting to me is the term “Full Stack App Developer” and the reaction by some who seem to think this is a new idea.

The ‘full stack’ paradigm is starting to make its way to app development going forward as well. It’s no longer enough to just know how to write code for a single platform. To be truly relevant and valuable you need to have an understanding of API design and implementation and cloud computing as well.

This is what I’ve been doing throughout my 12+ years as a professional software engineer. When I’m asked to describe my career in a phrase, I say that I’m “well-rounded”. What I mean is that I’ve been a major contributor or owning architect at every layer of a software solution at some point in my career.

In my first professional job after graduating college in 2001, I wrote software that communicated with teleconferencing bridges through raw socket connections. On top of that layer we created a web service (using classic ASP pages and XML-RPC), as well as a Windows Pocket PC app that allowed the host of a conference call to control the conference from their device.

At NewsGator, I started by taking over NewsGator Outlook and integrating the new RSS sync web service, then writing a handful of other RSS desktop apps before joining the platform team and working on the lowest levels of the codebase.

With Glassboard I had the honor of doing File > New on the Microsoft Azure platform, architecting the REST API as well as implementing the 2.0 version of the iOS app.

I recount all this not to brag (though its good to remember your accomplishments), but to counter the thought that the “new full-stack developer” is actually new. For myself and many of my friends and co-workers, its been our template for success.

I’d encourage everyone to be a full stack developer. Not to “adapt or die” but instead to “learn and grow”. Your software (and users) will thank you.

Written by Nick Harris

March 27, 2014 at 3:28 am

Posted in Uncategorized

UIWebView, PDF’s and Page Numbers

with 2 comments

UIWebView’s are powerful. Not only do they render HTML, they can also render a handful of known file types. One of the most common use cases for this is to display a PDF file. Whether the PDF is loaded from a local file or from a URL, its basically “load and go”.

When viewing a PDF file, the UIWebView has a handy little layover view in the upper left corner that lets the user know what page out of the total number of pages they are viewing.

IOS Simulator Screen shot Mar 17 2014 10 00 10 PM

This works great, until you want that page number in your code.


In my situation, the code needed to report the current page number elsewhere while the user is scrolling through the document. The UIWebView is already showing the page number so I figured hooking into that would be straight forward.


UIWebView has two properties that sound promising, pageLength and pageCount, but as far as I can tell, they aren’t used when previewing a PDF file. A quick web search showed some suggestions, but none of them worked for my situation.

So I dug in a came up with my own solution. I have no idea if this will be valuable to anyone, but it was fun to figure out so I thought I would share.


This solution makes one big assumption: each page in the document has the same page height. My project can make this assumption. If yours cannot, this solution will not be accurate.

The Math

Page Height = Total Document Height / Total Number of Pages
Current Page Number = Distance Scrolled / Page Height 

There are handful of variables here that we need to find the values for. Lets start with the Total Number of Pages.

Getting the Number of Pages in a PDF Document Using Core Graphics

Lucky for us, Core Graphics has tremendous support for PDFs. You can create a reference to a PDF document using the same NSURL you use to load the PDF into the UIWebView. With that document reference, you can use the CGPDFDocumentGetNumberOfPages function to get its total number of pages:

NSString *filePath = [[NSBundle mainBundle] pathForResource:@“Sample” ofType:@”pdf”];

NSURL *url = [NSURL fileURLWithPath:filePath isDirectory:NO];

CGPDFDocumentRef pdf = CGPDFDocumentCreateWithURL((CFURLRef)url);

self.pdfPageCount = (int)CGPDFDocumentGetNumberOfPages(pdf);

Getting the Total Document Height

UIWebView uses a UIScrollView internally. A UIScrollView is typically used when the content of a view is too large to show on the screen at one time. It has a property named contentSize which returns the entire size of the view, not just what is visible to the user. Once the PDF document is loaded in the UIWebView, you can use the internal UIScrollView to get the total height of the PDF document:

CGFloat contentHeight = self.webView.scrollView.contentSize.height;

Getting the Distance Scrolled

The last value to figure out is how far a user has scrolled. UIScrollView has another property called contentOffset which is a CGPoint holding how far the user has scrolled from its original point in both the x and y dimensions. We only care about how far down the user has scrolled our PDF document so we can use this code to get the Distance Scrolled value:

float verticalContentOffset = self.webView.scrollView.contentOffset.y;

Updating Values On Scroll

In order to know when a user scrolls a UIWebView all your code needs to do is set itself as the UIScrollView’s delegate then implement scrollViewDidScroll:.

One Small Adjustment

You’ll notice when scrolling through a PDF document that the built in page number view updates not when a page is first visible, but when it consumes over 50% of the total view. Having our code do the same is a simple addition: take the UIWebView’s visible height, divide it by two, then add it to the distance scrolled.

Putting it Together

I put together a sample project you can download, but the code is simple:

- (void)viewDidLoad


    [super viewDidLoad];


    // set the pdfPafeHeight to -1 so it gets calculated.

    self.pdfPageHeight = -1;


    // set the delegate of the UIWebView’s underlying UIScrollView to self.

    self.webView.scrollView.delegate = self;


    // create an NSURLRequest to load the PDF file included with the project

    NSString *filePath = [[NSBundlemainBundle] pathForResource:@“Sample” ofType:@”pdf”];

    NSURL *url = [NSURL fileURLWithPath:filePath isDirectory:NO];

    NSURLRequest *urlRequest = [NSURLRequest requestWithURL:url];


    // create a Core Graphics PDF Document ref using the same NSURL

    CGPDFDocumentRef pdf = CGPDFDocumentCreateWithURL((CFURLRef)url);


    // use CGPDFDocumentGetNumberOfPages to get the number of pages in the document

    self.pdfPageCount = (int)CGPDFDocumentGetNumberOfPages(pdf);


    // load the PDF file into the UIWebView

    [self.webView loadRequest:urlRequest];



#pragma UIScrollViewDelegate

- (void)scrollViewDidScroll:(UIScrollView *)scrollView


    // if pdfPageHeight is -1 it needs to be calculated

    if(self.pdfPageHeight == -1)


        // the page height is calculated by taking the overall size of the UIWebView scrollView content size

        // then dividing it by the number of pages Core Graphics reported for the PDF file being shown

        CGFloat contentHeight = self.webView.scrollView.contentSize.height;

        self.pdfPageHeight = contentHeight / self.pdfPageCount;


        // also calculate what half the screen height is. no sense in doing this multiple times.

        self.halfScreenHeight = (self.webView.frame.size.height / 2);



    // to calculate the page number, first get how far the user has scrolled

    float verticalContentOffset = self.webView.scrollView.contentOffset.y;


    // next add the halfScreenHeight then divide the result by the guesstimated pdfPageHeight

    int pageNumber = ceilf((verticalContentOffset + self.halfScreenHeight) / self.pdfPageHeight);


    // finally set the text of the page counter label

    self.pageLabel.text = [NSString stringWithFormat:@"%d of %d", pageNumber, self.pdfPageCount];


The Results

The sample project now shows a UIView overlay controlled by the code that shows the same page count as the UIWebView:

IOS Simulator Screen shot Mar 17 2014 9 59 41 PM

Written by Nick Harris

March 18, 2014 at 4:28 am

Posted in Uncategorized

Passwords and Keychain

leave a comment »

I answered my first Stack Overflow question today. I’ve learned so much there over the years and decided its time I start giving back.

My answer is actually a follow-up to Tom Harrington’s after I saw his tweet…

The question was how to store a single entity, in this case a password, using Core Data. Tom’s answer was to not use Core Data at all because its bad design. I completely agree with this. My followup answer was to use Keychain, which is the correct approach.

Passwords are very special data which demand special attention. Storing a password as clear-text in any type of database or storage scheme is a security flaw. If the platform you’re developing for has a well tested and secure way to store a password, use it. For iOS that means using Keychain.

Keychain can be difficult and intimidating to new iOS developers. I believe that’s why some decide to forgo it and instead use things like Core Data or NSUserDefaults. That’s where Buzz Andersen’s STKeychain comes in. Its open source, free to use without restrictions and most importantly tested and used by many iOS apps. Its solid code that makes interfacing with Keychain really simple.

I’ve also used Keychain to do two factor authentication with digital certificates. The code from my 360|iDev session is probably a bit outdated but the concepts are the same.

One other consideration about using Keychain is if you ever need to get your app certified for enterprise security. In my experience building enterprise iOS apps, password security is always asked about. Knowing how Keychain works and passing along Apple documentation answers those questions throughly.

Written by Nick Harris

January 13, 2014 at 3:29 am

Posted in Uncategorized

Unit Testing

leave a comment »

I started a new Xcode project this week to kick the tires of the new unit testing framework built into Xcode 5. I’ve long been an advocate of unit testing. Its great to see it being tightly integrated into Xcode and continuous integration. My impression so far has been very positive. Most of the hoops you needed to jump through in the past are now gone reducing the excuses to not unit test.

If you’re on the fence about unit testing, here’s a few thoughts to consider…

Code Design
Unit testing forces you to rethink how you design your code. I compare it to building a brick wall. Instead of focusing on the entire wall, you concentrate on just a single brick. The brick needs to be crafted well and tested to make sure it won’t fail and bring down the wall. Unit testing forces you to break down complex problems into manageable, understandable and testable pieces.

You’re Not Coding Alone
Most likely you’re working on a project with other developers (if you’re working by yourself you should consider your past self as another developer). Unit tests show other developers how you intended your code to be used. If someone needs to modify code you wrote, your tests will tell them if they are keeping with your intent.

Unit tests are also very handy when coding against web services. Your tests will alert you to changes in the request or response allowing you to adjust your code appropriately.

Reproducing Bugs
Unit testing also involves creating a mock environment for the tests to run against. The mock environment can help you reproduce real world bug reports. Its much easier to tweak a few parameters in a mock environment then to try and recreate a real world situation.

It may seem like you’re writing double the code. That’s because you are, but its well worth the effort.

Here are some unit testing resources from Apple:

Setting up Unit Testing and Continuos Integration
Sample Project 
WWDC Session 409 – Testing in Xcode 5 

Unit Test. You’ll thank yourself later.

Written by Nick Harris

January 7, 2014 at 1:11 am

Posted in Uncategorized

Introducing Bands

leave a comment »

When I was approached to write a book for the beginner’s series from Wrox, I decided I wanted to take a different approach then any of the other beginning iOS books I had bought.  I’ve written software in many languages and never found a beginners book that suited me. Instead I learned by creating something I could use. I decided to take that approach for the book.

“Beginning iOS Development – Building and Deploying iOS Applications” is now written, through edits and off to production. I believe it will be available in late January or early February.

The app the book builds is called Bands. It’s a simple app that would never win an Apple Design Award but instead walks readers through first step things like wiring up an IBAction to a button to advanced topics like using NSURLSession and completion handler blocks against the iTunes Search API.

Band list

Band details

Activity options

Map wide

Tracks tall

The chapter I’m most proud of is Chapter 2 “Introduction to Objective-C.” The book is aimed at devs who have written Java or C#. This chapter teaches Objective-C by comparing things like classes, methods and properties to similar code written in Java and C#. It also covers Manual Reference Counting, Automatic Reference Counting and Model-View-Controller. It’s the chapter (and honestly the book) I wish I had in 2008 when I started writing iOS apps.

Its been exhausting. The worthwhile experiences often are.

I hope readers learn as much reading this book as I learned writing it.

Written by Nick Harris

December 16, 2013 at 6:19 am

Posted in Uncategorized

Password Security Red Flag

leave a comment »

If you select “forgot password” from a service and they send you your old password in an email.

Written by Nick Harris

September 3, 2013 at 5:37 am

Posted in Uncategorized


Get every new post delivered to your Inbox.