Tech and a few other things RSS 2.0
# Friday, January 31, 2014

I’m waking up to the thought of my product owner, I just stayed up until 4:30 and got into work at 8. I’m pumped, I created a miracle and I want this person to know it. I run my app with its cool little animation that took me 2 days, but I say 4 hours, the animation runs and then I need my API not to fails. Product owner, in her infinite Stanford MBA wisdom looks at me and in business, politically correct words says, WTF. I look at my app, i’m tired, my wit is gone, the only thing that comes to mind is to throw the phone. I don’t throw the phone, but for some reason in my mind I see the API guy drinking piña colada at his desk, feet up, shooting me the gun as if life is all daisies and sunshine.

Ok ok, it may not be the API guy's fault there are plenty of systems and hardware between him and my final data destination, but like the "product owner" I only see the next step and API is it in my mind. Time to reflect, my zen, beer mind says "look not to the problem, but to the solution." I look hard and take to the Googles. For iOS I end up at NSURLProtocol. I write my own implementation, but find this guy Jim Puls. Like anyone I respect, he doesn’t talk about problems, he fixes them, this being said with his work at Square he writes a very understated library which is an implementation of NSURLProtcol and like the clever drinker he is (or isn’t), he calls it Mocktail. As soon as I read his code and understand who he is (a person’s code speaks a lot to who they’s a nerd thing), I fall in love with the open source project WHICH brings me to my point. API’s fail, and when you are early on in your project you don’t want that to affect your presentation to your product owner.

...I meant to write a post on Core Data and parent child NSManagedObjectContext and ended up here...HA damn you booze.

So here is a link to my NSURLProtocl blog post.

Friday, January 31, 2014 11:26:34 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Friday, December 27, 2013

Unless you really love Objective-C this will be a slow read and if this is interesting, you probably already know it. With that said, I’m slow sipping some bourbon and calculatedly decided to not wear pants, wait for it, ...ok, mental image established, read on.

Its been a journey for instance variables aka iVars in Objective-C. They started out with having to define the getter and setter methods...ugg so Java --see: senior citizen 4 o'clock happy hour discount at the Sizzler. The C wizards then moved on to giving synthesize the compiler director love. @synthesize with Objective-C moved us from having to work with getter and setter methods. A welcome change, but this is where some confusion starts with iVars.

Instance variables started out with being explicitly stated in the header file, however you like, and being mapped with the synthesization of your properties. Sans ARC (Automatic Reference Counting).


@interface YoDiggity.h{
NSObject *_bigFun;
NSObject *smallFun___;

@property (nonatomic, retain) NSObject *bigFun;
@property (nonatomic, retain) NSObject *smallFun;

@implementation YoDiggity.h

@synthesize bigFun     = _bigFun;
@synthesize smallFun = smallFun___;
The next step was not having to declare your iVars in your header file you simply declared the property, the synthesize and done. You could optionally declare your iVars right after your @synthesize, if you wanted to get disco.
@interface YoDiggity.h
@property (nonatomic, retain) NSObject *bigFun;
@property (nonatomic, retain) NSObject *smallFun;

@implementation YoDiggity.h

@synthesize bigFun;
@synthesize smallFun = _onTheSpotDeclaredIvarSmallFun;
This was nice, but the C gods didn’t stop there with Objective-C. They quickly decided why declare the @sythesize, and promptly got rid of the necessity of using it. Following this with implicitly declaring all your iVars with a “_” in front of your @property declaration.

@property (nonatomic, strong) NSObject *bigFun;
Without any mapping you can now access the iVar in the implementation file by typing:
_bigFun = @”bookers”;
Easy enough you say, but now I’m going to rock your world, like adding Jamison and Irish cream to a Guinness.

What does it mean when I do this in Objective-C:

In short, it means you just tapped into the iVar directly in Objective-C. The deeper answer is “->” mean dereference. Dereference means I get the value the pointer is pointing to instead of the address and nearly everything in Objective-C is a pointer.

From what I’ve been told, don’t use “->” it a legacy component of C and until you get code accepted in the LLVM compiler, I’d probably listen to that advice.
Friday, December 27, 2013 1:15:53 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Sunday, September 01, 2013

Do you like coming into work? Many things go into this, outside of working with cool people, your workspace really helps drive this. A good workspace helps drive productivity, collaboration and fun Friday nights. I tend to aim more to the last of this list. Hint: If your office is full of non married 20 somethings and it’s empty every Friday night...your Workspace...well it sucks. In my years of working i’ve seen companies slowly pick up on this and build more engaging workspaces.

Ready for the big stretch of a segue? ...The same thing is happening with the maturity of Objective-C and xCode and the use of xCode workspaces. As iOS projects have graduated from iFart and move into more fully interactive games and engaging applications like Facebook, Square, and Google Now, a workspace becomes a must in breaking down larger reusable components that can not only be used by your app, but many other apps.  In steps workspaces with xCode 4. So last year you say. I agree, but in my humble opinion its only been this year (2013) and with the proliferation of Cocoapods that I have really seen workspaces being fully adopted and used as they should.

The short of what I’m saying, if I'm saying anything, is when building that next project for yourself, think about how you can break down key parts into a separate project for something you could potentially use in the future.  This could be your networking and model layer, something Apple leaves fairly undefined on how you should implement it.

P.S. --- Oh yeah and don’t nest projects in projects anymore, you may think you have a good reason to do so, but unless you go by the name bbum, you in all likelihood do not.

Sunday, September 01, 2013 11:31:55 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C | xCode
# Sunday, June 09, 2013
A nice semi confusing picture about threads.

What I’m looking to answer: which is easier to use; faster processing wise, but let’s set some boundaries

1.  NSOperations go into an NSOperationQueue, however an NSOperation can run on its own and can be run concurrently, it can even be sub-classed to do quite a bit. To keep things in a reasonable scope I will be comparing NSOperationQueue to Dispatch Queues.

NOTE: As of right now NSOperationQueue is built on top of GCD. Yes, in a sense I’m comparing the same things…kinda.

2. I will be examining the NSOperation’s that are provided out of the box and not a subclassed NSOperation. These concrete subclasses we can use “as-is” include NSInvocationOperation and NSBlockOperation.

3. Whenever possible I will be using blocks.

4. What I will be looking/judging is:
a. Ease of code understanding
b. Number of lines of code it takes to do the same thing

Test 1 – Create a section of code and add it to concurrency queue – Blocks

NSOperationQueue* queue1 = [[NSOperationQueue alloc] init];

[queue1 addOperationWithBlock:^{
    NSLog(@”Work the magic”);


dispatch_queue_t queue2 = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(queue2, ^{
    NSLog(@”Work the magic”);
dispatch_queue_t queue3 = dispatch_queue_create("com.bencoffman.MyOwnQueue.MOFO", DISPATCH_QUEUE_CONCURRENT );
dispatch_async(queue3, ^{
    NSLog(@”Work the magic”);
Criteria a.
NSOperationqueue follows a pretty standard Objective-C syntax for objects, you allocate and init the object, then use a simple method to add the block code to the object, you could almost intelligence your way through figuring out this code. However, with GCD you would have to have at the very least some base level of understanding to even know to call dispatch_async and to know it exists.

I would also argue the understanding of what is actually happening is easier with NSOperationQueue. In NSOperationqueue example it’s easy to conclude you are creating your own queue of which you can add multiple objects of code to be executed too. However with example one in GCD, you are not creating a queue you are getting a pre defined/system created queue and adding your work to it. In example two you are creating your very own queue and telling it to run concurrently, it’s hairy if you look at GCD code without any prior knowledge.

Criteria b.
Ehh it’s about the same for both.

Test 2 – Setting Dependencies


NSOperation *op1 = [NSBlockOperation blockOperationWithBlock:^{
    NSOperation *op2 = [NSBlockOperation blockOperationWithBlock:^{
    // In order for op2 to start op1 needs to finish
    [op2 addDependency:op1];
    [queue1 addOperation:op2];
    [queue1 addOperation:op1];


dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_group_t group = dispatch_group_create();
dispatch_group_async(group, queue, ^{
        NSLog(@"GCD Love");
        //[NSThread sleepForTimeInterval:6.0];
dispatch_queue_t waitingQueue = dispatch_queue_create("com.waitingQueue", DISPATCH_QUEUE_CONCURRENT);
    dispatch_async(waitingQueue, ^{
            dispatch_group_wait(group, DISPATCH_TIME_FOREVER);
            dispatch_async(dispatch_get_main_queue(), ^{
                NSLog(@"you done waiting man");

Criteria a.
Hands down, NSOperationqueue is easier to understand. I don’t think you even need to know how to read code to have an understanding of what is going on.  As for dispatch queues, first just knowing how to set up dependencies with them is no joke, because it’s not straight forward. Second, I can see someone trying to set up a dependency in dispatch queues and having the main thread wait on it, huge no-no. In fact at the time of this writing, I think the code Apple provides in showing this has the main thread freezing until the dispatch group completes. Geeze, that’s bad.

Criteria b.
NSOperationqueue takes it.

Test 3 – Setting Execution Priority

dispatch_queue_t queue2 = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(queue2, ^{
    NSLog(@”Work the magic”);

Follow Up:
This is a precarious question because you can’t really set priority with dispatch queues. With dispatch queues there are 4 default queue created:
You can choose to add your tasks to each one of these queues, which in turn, kind of sets the priority. The problem is you really can’t set priorities for each task in multiple groups of tasks. For example what if you want Group A to be able to set all its task in relation to each other and you want Group B to set all of its task in relation to each other, but don’t want either of them get in each others way. By the nature of have 4 default queues, some of Group A’s tasks will be mixed in a queue with Group B’s tasks.

NSOperation *op1 = [NSBlockOperation blockOperationWithBlock:^{
    [op2 setQueuePriority:NSOperationQueuePriorityHigh];
Follow Up:
It’s pretty straight forward, you create a queue add operations (tasks) to it and set the priority of each operation using setQueuePriority. Your choices range from:

Criteria a.
This is really hard to judge for me. GCD is pretty straight forward and so is NSOperationQueue. You can debate the flexibility I have mentioned above, but in terms of ease of understanding, I believe this is a tie.

Criteria b.
GCD wins here. I believe this is in large part due to the necessity to set a priority-ish setting when you choose what queue you add the task to.

Test 4 – Speed, who is faster?

Here’s the deal, speed is such a darn subjective matter. There are many ways to measure speed in a way that is relevant to you or your goals. Because of this I’m taking the easy way out and saying that simply because NSOperationqueue is built on top of GCD, GCD become the lowest common denominator of the two, which in theory should always make it the fastest.

Who is the overall winner? NSOperationQueue. I find most hardcore Objective C peeps seem to like GCD and almost look down on the NSOperationQueue. My belief, easiest will always win. We’re human, by nature we take the path of least resistance and as more and more up an comers get to the level where they need to thread, I’m betting they will go with NSOperationQueue…at least for now.
Sunday, June 09, 2013 9:20:05 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
GCD | multithreading | NSOperationqueue | Objective C
# Thursday, April 25, 2013

Anyone who has written an application that interacts with an API knows it will invariably fail you and if luck has it’s way it will be at a time that will make you look unfavorable. Let’s move on.

The best way to mock a response is to intercept the response and inject a controlled predefined response back into your code. This allows you to never change the working code base.  In steps mocking for iOS using NSURLProtocol.  It’s a great tool, but NSURLProtocol’s documentation doesn’t make it super clear on how to use it, ok it kinda does, but abstraction can always make life a little easier. In steps Mocktail, Square, and this guy ( Add Mocktail to your project, and implement it with a few simple lines of code. I recommend putting it in the app delegate, possibly with some flags in your project file to exclude the code when doing a release. Also remember to exclude the testing files when you do a release build. I went ahead and added the "Mocktail" directory to Sub-Directories to Exclude in Recursive Searches for a Release build. You can see it in the Build Settings.

At any rate I have created a sample project that gives you an example on how to use it. You can get it here.

Also, completely unrelated, today, Apple  sold out it’s WWDC 2013 in about 2 minutes and I didn’t get a ticket as a result i’m going through the many stages of grief.
Thursday, April 25, 2013 2:36:16 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C | Unit Testing | WWDC | xCode
# Sunday, March 31, 2013

I was going to write a post on blocks, but after a few searches with the goog's I came up with a ridiculously good blog post that I'm going to link to.

I want to cover one topic, quickly. Pointers and blocks. There is one misunderstanding I see quite a bit. How you work with a pointer in a block. The short of it is yes it's static, but you can still modify it's properties. This operates differently than native/primitive types (int, float, double) in which you cannot change the value. Technically you can't change the value with a pointer either, but it's not the the value you think it's the object at it's address you can't modify.

Kinda makes your head hurt a bit when you think about it? ...This post does a great job at breaking it down.

If you really don't want to care about how pointers operate with blocks...just know you CAN modify pointers properties inside a block and it's not breaking any coding standards or proper coding techniques. Unless it's mutable (NSString, NSMutableArray)...then you cannot. (you can add the __block descriptor in front of your variable declaration to make it editable inside a block, but really think about this before you use it)

Blog Post:

Most important part to me:

Blocks have their own private const copies of stack variables

If a block references a stack variable, then when the block is initialized it is given its own copy of that variable, with one twist: the copied variable is declared const. This means that you cannot change the values of referenced variables directly from inside your blocks (without a little extra sauce at least: see below for the details). However pointer types remain pointers: you cannot assign a new address value to a pointer, but the value it points to can still be modified. This applies to Objective-C objects, so these can be modified directly. For CoreFoundation types, note that the typedefs for most of those with mutable and immutable variants define those types as [type] * and const [type] * respectively, so your CFMutableStringRefs and CFMutableArrayRefs will cease to be mutable from within your blocks unless you type-cast them.

Sunday, March 31, 2013 9:01:32 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Thursday, February 28, 2013

WWDC can you smell it? Can you taste it? NO? Well then you will probably miss it. If your heart is not fully into this event it will pass right on by before you even know the tickets went on sale. As an example, last year the event of 5,000 people sold out in the first 45 minutes of the tickets being released for sale.

Sooo you need to know when tickets go on sale and you need to know it in minutes. Well fellow coders, there is an app for that. Check out I also recommend getting some twitter monitoring tools to notify you or simply schmooze with someone at Apple who is in the know.

Little advice, ask your manager for permission long before the event, tell him you don't know when they will go on sale, but you need to know he will be cool with you buying them the minute they do go on sale. Do it now, just get up and get it done.
Thursday, February 28, 2013 9:16:01 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
apple | Apple TV | iPad | iphone | iphone | Objective C | WWDC | xCode
# Thursday, November 29, 2012


I get this very insightful error, EXC_BAD_ACCESS (SIGSEGV), with an issue in the following code when I am using threading
NSError *error1;
NSArray *results = [self.del.managedObjectContext executeFetchRequest:request error:&error1];

if(error1 != nil){
if (error1 != nil) 
if ([results count] > 0)

A stab in the dark as to why this may be is because the space in memory where error is allocated goes away or is assigned to something else or is simply never allocated. Beats me compilers can do funny things behind the scenes to create shortcuts, heck it may not even be the compiler maybe it’s the executeFetchRequest method. At any rate it’s a darn tuff bug to solve for and I hope this helps someone out there save a few hours.

Thursday, November 29, 2012 6:28:33 AM (Central Standard Time, UTC-06:00)  #    Comments [2] - Trackback
Objective C
# Tuesday, August 28, 2012

In my most recent project I have witnessed the core concept of memory management doesn’t really stick with most people. It’s understandable, if a modern language even deals with memory management it’s generally taken care of with the compiler. In steps the iPhone, which single-handedly puts Objective C on the map. Objective C up to iOS 5 makes you deal with your own memory management.

Apple says, no problem, use Instruments. Not sure about the rest of you, but despite Instruments looking cool, it just comes across like a graph on a cardiac monitor and gives me very little insight as to what exactly is not working with my application, but I definitely know something is wrong because the little memory bar thingy keeps going higher.

Forget all that business, I’m sure Instruments has it’s place, but for nearly all my issues I use cmd-shift-b and zombies. Yeah that’s right, freaking zombies. When you turn on zombies in xCode it keeps and labels the object who is no longer there, and yet one of your objects is trying to access it. Here's the catch xCode gives the object in hexadecimal code. What does that tell me, nothing. Here is how I get around that, I debug the application until I get the approximate area the application crashes. Then I start using

NSLog(@"Hex memory address of my object: %p", object);

This prints out the hex number of the object. I do this with various objects until I find the one that matches the one with the zombie hex address when the application crashes. This means you need to have your NSLog's in prior to crash unless you can work your way around the console (this is a great skill to have, it has saved me lots of time, but is a blog post to itself). An important thing to remember here is the spot in memory changes after every compile and run, so the zombie address you get at the end when the application crashes is not going to be the same for the next compile and run.

As for the cmd-shift-b, it lists nearly if not all the objects I need to release. Much easier right? I’m sure the super hard core people out there will have an exception for this, but to that I’m sure it’s just exception. See screenshot below to learn how I enable zombies and a few other things to help with memory management (make sure you enable “the few other things,” also.) You can get here by going to "Product->Edit Scheme" in xCode 4.3

Tuesday, August 28, 2012 5:46:01 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
memory management | Objective C | xCode
# Saturday, June 30, 2012

I was setting the tag to zero "0," for one of my UIButton's I had nested in a UITableViewCell. Well for whatever reason you can't do that and access the UIButton later by a tag number of 0. FIX: up the tag number to 1.

As most of my code solution posts go, this one is such a big fat duh once you know the answer. Since every item on a view has a tag of zero by default, one is probably getting back the object they are not expecting. Hopefully if you run accross this error you won't waste any more than 10 minutes to my 1.75 hours.

Saturday, June 30, 2012 10:33:43 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Sunday, June 17, 2012

Subclassing can suck it...ahhhmmm...not really, subclassing is still important, but Apple seems to have a strong love interest in delegates.

What is a delegate? A delegate gives you the ability to have two objects to speak with each other without subclassing, this communication generally happens when something one object does finishes and wants to let the other object know -- think downloading an image.

If you have programmed any type Cocoa app you will have dealt with delegates. In my eyes there are 3 different types of delegates (technically 2 - delegate methods and datasource methods).

My interpretation
1. The delegate for your application
2. The delegate a user implement because they used something like a UITable
3. The delegate a user created because their class’s objects are special enough to talk to other objects.

How to create a delegate. Apple gives a great code example here. NOTE: Right now Apple has the source code for download in the upper left corner of the internal box. We all know apple and most likely the download source link will move so I suggest pulling up the page and just stare at the page until your god of choice points it out to you.

Apple's definition of a delegate.

What do delegates have to do with death? Well I found the easiest way to remember this functionality is to think of the human brain as an object and the heart as an object. The heart has a delegate method that executes and lets the brain know every time the heart beats. When the heart stops sending this message to the brain you die.

Happy Fathers Day all.
Sunday, June 17, 2012 11:27:38 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Wednesday, April 25, 2012

Automatic Reference Counting causes the wonderful ASIHTTPRequest to not work, I suppose one could fix it, since it's on github, but for right now I took the easy route and just turned off Automatic Reference Counting.

Here are the steps:
  • Click on you project, in the left hand organizer.
  • Select your target, in the next column over.
  • Select the Build Settings tab at the top.
  • Scroll down to "Objective-C Automatic Reference Counting" (it may be listed as "CLANG_ENABLE_OBJC_ARC" under the User-Defined settings group),
  • and set it to NO.

Link from Stack Overflow

Wednesday, April 25, 2012 5:07:59 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C | xCode
# Saturday, April 07, 2012

It's easy, so easy, it makes you a tiny bit happy inside once you see how easy it is. I'll post the code then give an explanation for those of you that want more.


// create a done view + done button, attach to it a doneClicked action, and place it in a toolbar as an accessory input view...
// Prepare done button

UIToolbar* keyboardDoneButtonView = [[UIToolbar alloc] init];
keyboardDoneButtonView.barStyle = UIBarStyleBlack;
keyboardDoneButtonView.translucent = YES;
keyboardDoneButtonView.tintColor = nil;
[keyboardDoneButtonView sizeToFit];

UIBarButtonItem* doneButton    = [[UIBarButtonItem alloc] initWithTitle:@"Done" style:UIBarButtonItemStyleBordered target:self action:@selector(pickerDoneClicked:)];
// I put the spacers in to push the doneButton to the right side of the picker view UIBarButtonItem *spacer1    = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace target:nil action:nil];
// I put the spacers in to push the doneButton to the right side of the picker view
UIBarButtonItem *spacer    = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace target:nil action:nil]; [keyboardDoneButtonView setItems:[NSArray arrayWithObjects:spacer, spacer1, doneButton, nil]]; // Plug the keyboardDoneButtonView into the text field... self.businessType.inputAccessoryView = keyboardDoneButtonView;
Bam, and you are done.

For nearly every input field (I focus on the UITextField here) in objective-C iOS you can choose one of the core SDK libraries input tools to pop up, whether this is a keyboard or a picker, or one of the many others to choose from. You simply need to assign the input tool to the inputview, but what I stumbled across is Apple so graciously made an additional built in view to give you just a touch more creative flexiblity, it's the inputAccessoryView and it sits on top of the inputView.  All you have to do is stuff another view into the inputAccessoryView. I imagine you could put whatever you want, but a UIToolbar seems to be the unspoken consensus on what to use. Put a few buttons in the UIToolbar and set it as the inputAccessoryView. Done. Yeah. It's not complex, but a nice to have.

Easy enough!

Saturday, April 07, 2012 2:26:23 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C | xCode
# Wednesday, March 21, 2012


The important thing to remember is that whenever you want to to make a mutable copy of NSMutableArray or NSMutableDictionary, or most likely anything with mutable in the name always use "mutableCopy." Do NOT simply assign one mutable dictionary to another. Like so

NSMutableDictionary *mutableUsers = mutableDictionaryOfUsers;

NSMutableDictionary *mutableUsers = [mutableDictionaryOfUsers mutableCopy];

After pounding my head for more than I would like to admit I edu-micated myself to find out that if one has two NSMutableDictionaries and one tries to set one NSMutableDictionary to the other without using the method "mutableCopy" it simply passes a NSDictionary. If you notice in my wrong example I was simply receiving a NSDictionary of mutableUsers and when I was trying to modify the dictionary or append to the dictionary it was failing.

Hope this helps someone somewhere.....

Wednesday, March 21, 2012 4:47:10 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Thursday, February 23, 2012

Turns out this isn't too hard, just a few simple things to understand.
1. If you are creating a TabBar Controller, the TabBar Controller will always have to be the root view.
2. Once you know the last step the next step is to see what view or xib the TabBar controller calls first. Once you know what xib or view gets called first go to the view or xib's view controller code. In that code create function

(void) viewDidAppear:(BOOL)animated { }

Within the above function you can inject the navigation view, but first you must tell the navigation view what the first view you want to be displayed, done like this:

PersonalInfoVC *personalInfoVC = [[PersonalInfoVC alloc] initWithNibName:@"PersonalInfoVC" bundle:nil]; UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:personalInfoVC]; [self.tabBarController presentModalViewController:navController animated:YES];

Next in each subsequent view in the navigation controller you can call the view after it like so

DepositDetailsVC *depositDetailsVC = [[DepositDetailsVC alloc] initWithNibName:@"DepositDetailsVC" bundle:nil]; [self.navigationController pushViewController:depositDetailsVC animated:YES];

Finally when you are done with the flow of the injected navigation controller run this code to go back to your original TabBar controller

[self.navigationController dismissModalViewControllerAnimated:YES];

Easy enough. :)

Thursday, February 23, 2012 7:29:19 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
iphone | iphone | Mobile | Objective C
# Monday, May 23, 2011

NSUInteger       newIndex[]   = {0, row};
NSIndexPath	*newPath      = [[NSIndexPath alloc] initWithIndexes:newIndex length:2];
There is quite a few things assumed in these 2 simple lines of code. Let's break it down into newbie terms.

First you must understand that a "section" is an area of grouped rows in a tableview. You see this in many iPhone apps. Think about the "Settings" app. Click around in it and you will see sections.

Next you must understand that a tableview assigns the property "cellForRowAtIndexPath" with a NSIndexPath value. In short this property looks at the NSIndexPath's first value for the section the row is in and then the second value for the row itself for the value you are trying to retrieve. 

The 0 in the "newIndex[]" is for the "section" in the tableview, stating this will be the 1st section (in this case the only section). and the "row" is for the...well row in the section within the tableview.

So in the next next line with "*newPath" you have the code assigning the "newIndex" with a "length" of 2. What you are reading here is that tableview should look two nodes deep in your array of sections with each node in your section array caring an array of row nodes (think nested arrays).

The first node is the section array and the second node is the row.
So in our example:
Node 1 = specific node in section array (here its node 0), 
Node 2 = specific node in row array nested in Section array.

If the above is italicized text is confusing see screen shot I attached. The picture may make it easier to understand. Array 0 is the array of section nodes, where each section node contains an array of rows.

An different way to create the NSIndexPath that might be easier to read is to use this function.
NSIndexPath *myPath = [NSIndexPath indexPathForRow:myRow inSection:mySelction];
Here is the exact definition from Apple Documentation, with the knowledge I gave you above it should be a bit more clear now. A "category" by the way, is, in short, a way to add extra methods to a class without subclassing it.

Many methods of UITableViewDelegate take NSIndexPath objects as parameters and return values. UITableView declares a category on NSIndexPath that enables you to get the represented row index (row property) and section index (section property), and to construct an index path from a given row index and section index (indexPathForRow:inSection: method). Because rows are located within their sections, you usually must evaluate the section index number before you can identify the row by its index number

Monday, May 23, 2011 4:38:30 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C | xCode
# Monday, May 16, 2011

I found myself wondering what the difference between these two items are in Objective-C and when exactly to use them. In short, you should use @class in your header file and #import in your implementation file with the exception of conforming to a protocol (interface in .net) in your header file, in which case you need to use #import not @class in your header file, but of course there is a little more to it than that. Here is the best answer I got from -- I added a few things to make the below statement a little easier to read, because we don't all speak nerd.

Use a forward declaration (AKA "@class")  in the header file if needed, and #import the header files for any classes you're using in the implementation. In other words, you always #import for the files you're using in your implementation, and if you need to reference a class in your header file use a forward declaration as well.

The exception to this is that you should #import a class or formal protocol you're inheriting from in your header file (in which case you wouldn't need to import it in the implementation).

There you go the simple and easy explanation on when to use @class and #import. Now back to the code.

Monday, May 16, 2011 5:50:32 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C
# Sunday, February 27, 2011

Have you ever seen a silk teddy bear. They're nice, soft, smooth and comforting. They take something scary and unmanageable like a grizzly bear, and make the animal manageable, gentle and silky smooth.

In the just-released Beginning iPhone 4 Development, authors Jeff LaMarche and David Mark team up with Jack Nutting to take the ever-growing and changing iOS and break it down into manageable chunks. In this informative and light-hearted read, the authors bring the new edition with updates to key subjects like Core Data, Grand Central Dispatch and iPad/iPod programming specifics. Full of step-by-step instructions and intuitive pictures, Beginning iPhone 4 Development serves as a perfect guide for the novice yet remains effective as a quick reference to the experienced developer. In the end it's all about having fun, making an app you want and not about getting frustrated at trying to understand the idiosyncrasies of iOS. With their latest offering, LaMarche, Mark and Nutting get you on the right path.

Sunday, February 27, 2011 1:33:35 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
iphone | iphone | Objective C | readings | xCode
# Sunday, February 13, 2011


Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Popovers cannot be presented from a UIBarButtonItem that is not in a toolbar or navigation bar already.'

You can get the error for a number of reasons, but I'm betting it's because you didn't declare your UIBarButtonItem correctly in either your header file or your implementation file. You might have done something like this in your header file.

@interface TestInterface : UIViewController <UIPopoverControllerDelegate, UISplitViewControllerDelegate>
    UIButtonItem    *button

@property (nonatomic, retain) IBOutlet UIBarButtonItem *Button;

Notice the Button variable is declared with one "B" capitalized and the other "b" is not.

And then in your implementation file you tried to call the button by using the non-capitalized declaration.
Like so:
[poc presentPopoverFramBarButtonItem:button ...];

Usually what causes this is, what I would consider, but technically is not, a syntax error. You tried to call a variable that doesn't exist, kinda. The real kicker is there is no compile error. Which is correct, as you should be able to declare code as such in the header file, it just makes it easy for the user to reference the incorrect variable name.

Sunday, February 13, 2011 11:10:30 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
iPad | Objective C | xCode
# Saturday, September 04, 2010

I'm done! After a summer of surprises, swings, and roadblocks I finally finished this book, a few months behind schedule, but it's done. The last objective-C book I read was by the de facto in Mac OS X development Mr. Hillegass, (my post) I embarked on the journey of reading a book on iPhone development with the man in iPhone teaching Jeff LaMarche. Jeff is every bit as good at breaking down complex topics and making them seem easy as my .Net home skillet Scott Hanselman. In short these dudes are just smart, but they'll never tell you that and they write some good books.

This book is an easy read and provides hands on examples on how to use many of the tools provided with the iPhone SDK 3. The book is spot on with it's examples, but I'm betting new Objective-C users might have trouble following along when  xCode 4 comes out. xCode 4 is quite a bit different graphically than 3 and may render the step by step instructions in this book out of date.

Overall if you are into programming on the iPhone, this is a great book to start, given you have a base working knowledge of Objective-C and an advanced understanding of programming in general.


Saturday, September 04, 2010 3:29:55 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
iphone | iphone | Objective C | readings | xCode
# Wednesday, September 01, 2010

Error Readout:

error: expected '=', ',', ';', 'asm' or '__attribute__' before 'interface'

Added a semicolon.

It's important to remember that this was occurring before the interface tag, which meant it was happening in a file I was importing. In this case it was a header file with an enumeration in it that were not showing an error with a missing semi colon.

Wednesday, September 01, 2010 3:54:31 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
iphone | Objective C | xCode
# Saturday, June 12, 2010

It's a good question.

There are some types that are not derived from NSObject, these types are called "Primitive Types." Some examples of these types are
  1. int
  2. bool
  3. short
  4. long
  5. double
  6. char
Sooooo basically any type that is not derived from the NSObject class is a Primitive type and does not require a "*".

Now I bet you are wondering how do I figure out if it's a primitive type or not.
  1. An easy way is to look at the color of the syntax in xCode, is it deep blue or a sky blue? Deep blue = primitive type, but this is not entirely reliable as the standards for coloring syntax can fluctuate or change.

  2. You can option-click on the object after you have typed it in xCode, click the little book in the upper right hand corner, when the class reference viewer comes up, look and see if it inherits from NSObject. If it doesn't it's Primitive and you don't need a "*".

There are some alternatives to using the primitive type int, such as the reference type NSInteger, which has some nice baked in functionality of distinguishing between 32 bit and 64 bit, but not all primitive types have an alternative reference type in Objective C.

Just for fun:
In .Net they have primitive types too(I believe they call them value types), kinda. The compiler recognizes traditional primitive types and therefore lets you use the syntax

int i = 5;

But despite the compiler letting you do this, this type still maps back to System.Int32. All things in .Net are mapped back to System.Object. Everything is a reference type, but .Net lets you keep the traditional syntax instead of writing:

System.Int32 i = new System.Int32(5);

UPDATE: Enumerations types also do not use a * (star) and they have the sky blue coloration that may make you think you need a *.

Saturday, June 12, 2010 9:59:04 AM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
.Net | Mac | Mac OS X | Objective C | Windows
# Sunday, June 06, 2010

When starting a new project you have the ability to  select a template of premade projects. Two examples of this are
    1. Navigation Based Application
    2. View Based application

When these templates are selected xCode will create the appropriate base controller for you in interface builder, such as "Navigation Controller" or a "View Controller" it will also create the appropriate classes for you with some of the most commonly used delegate and datasource methods along with the appropriate methods to override.

With a new project and selecting Window-based application, you are simply creating a blank slate in which you have to create nearly everything. It's rarely advantageous to use this unless, you are creating something outside the templates offered or you are learning how all the pieces fit together.

Sunday, June 06, 2010 7:05:58 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Objective C | xCode
# Sunday, May 09, 2010

The Problem:
I was getting a white screen with no data in a UITableView on it in the iPhone simulator.

The Solution:
I had my initialization code for the array in the the "loadView" method and not the "viewDidLoad" method

Don't read self.view in -loadView. Only set it, don't get it. The self.view property accessor calls -loadView if the view isn't currently loaded. There's your infinite recursion. I'm guessing UITableView calls a View [pretty good guess since "view" is in the name. :)] which in turn caused my recursion.

This was a stupid little error that caused me about 30 minutes of my life due to the fact I didn't get any build errors. A simple copy and paste moved me forward.

Update: I think it might be important to distinguish the differece between loadView and viewDidLoad. (below)

loadView is the method in UIViewController that will actually load up the view and assign it to the "view" property. This is also the location that a subclass of UIViewController would override if you wanted to programatically set up the "view" property. viewDidLoad is the method that is called once the view has been loaded. This is called after loadView is called. It is a place where you can override and insert code that does further initial setup of the view once it has been loaded.

Sunday, May 09, 2010 5:55:43 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
iphone | Objective C | xCode
# Wednesday, April 21, 2010

When is the right time to use dot notation vs bracket notation in objective C, or should I not use dot notation at all? I searched around for information on this, read quite a few opinions, but this blog post seems to give an answer of why.  I quote the most important part; I suggest you don't read the blog post. The post is very technical and what you really want to know is right below here. If you need to know the details, eschatology does a great job at giving them.

Most important parts of blog post:
  • Use dot notation to get and set objects’ state.
  • Use bracket notation to invoke objects’ behavior.

Eschatology --

A bit of a dark name for a blog, but the name doesn't affect the quality of the post.

Wednesday, April 21, 2010 6:50:48 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Mac | Objective C
# Tuesday, April 13, 2010

I'll keep this post short. I read this book to prepare myself for iPhone development and give me a deeper understanding of Objective C. This book is probably the best book to start learning Cocoa Programming currently on the market. It gives chapter by chapter examples with exercises to follow along with. The only shortcoming of the book is that it's a bit dated to what the current xCode version is. A few of the examples might take the novice for a spin (which means it took me for a spin, sometimes a quite frustrating spin) because the step by step instructions are not exactly correct due to the fact some of the menu items have changed or been rearranged. Outside of a few minor issues, like the one I mentioned earlier, it's a pretty fun book and I would recommend it to other experienced programmers. Hopefully Mr. Hillegass will come out with a newer version.

Things covered in the book

Memory Management
Helper Objects
Key-Value Coding; Key-Value Observing
Basic Core Data
Nib Files and NSWindowController
User Defaults
Using Notifications
Using Alert Panels

The list keeps going, it really covers all you need to know for having a strong hold on the basics.

Tuesday, April 13, 2010 9:10:59 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Mac OS X | Objective C | readings | xCode
# Friday, January 01, 2010

The Problem:
Not being able to do a simple compare in an "if statement" between two alpha or numerical statements while programing in objective C.

The Solution:

Example Of Use:
This compares the value of "key" to the value of "support." If they are equal then you get a return value of true.
if ([key compare:Support] == NSOrderedSame)
For some reason Objective-C decided to make it a little bit harder to compare values. Instead of just using the traditional way "[key compare:Support]" return a true value for the if statement OR "([key compare:Support] == 0) OR "([key compare:Support] == true)" they decided to make it a little bit more complex. As demonstrated above. I'm sure the writers of Objective-C have a good reason for this, but one more level of abstraction could make Objective-C that much friendlier to it's programmers and isn't that what it's all about in the end...getting more people to develop in your language.

Some of other comparisons you might want to use are:
NSOrderedAscending -- The left operand is smaller than the right operand.
This is equivalent to using "<" in most languages.

NSOrderedDescending -- The left operand is greater than the right operand.
This is equivalent to using ">" in most languages.
Friday, January 01, 2010 7:51:02 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Mac | Mac OS X | Objective C
# Monday, September 28, 2009
Error Readout:
1st Error:
this class is not key value coding-compliant for the key managedObjectContext

2nd Error:
NSImageCell's object value must be an NSImage

1st Error:
There is one prominent reason you could get this answer. You didn't spell your property correctly when you were binding it to....well....whatever you want to bind it to, in my case it was an Array Controller.

My problem however had nothing to do with this. When I created a new project after I upgraded to xCode 3.2 I forgot to check one very import checkbox, Create document-based application (Note: it was not a check box in older version of xCode it was a full icon selection upon creating a project). By not checking this I created a big variety of problems for myself. One of the errors occurring when I didn't check the Create document-based application, was the error this class is not key value coding-compliant for the key managedObjectContext.

2nd Error:
This error is very clear in it's issue. I was creating an entity with a property of native type binary and the compiler wanted NSImage. Grrr but I should be able to pass an image as a binary object, I would say to myself as I had urges to break my laptop and anything else in reach over my knee. My fix again was to simply create a project and remember to click Create document-based application. I know this is not your typical fix, but in case someone else runs into this issue the same way I did I hope they find this and it will be a quick and easy resolution.

All of this pain could have been resolved from the very beginning had I known to click Create document-based application. It was a silly little mistake that cost me a few hours. In my defense however I was under the impression of not checking Create document-based because in Hillegass's book he states that for this exercise we will not be using NSDocument, but NSPersistentDocument instead. It turns out this still means you have to check Create document-based application.

I will state that I should have known something was wrong when I didn't have a MyDocument.xib in the Resource folder after I created the project.

I've attached an image, mainly because blog posts are more fun when there is an image, but also because it shows where this one simple little check box changed my life for a hot minute.

Monday, September 28, 2009 10:55:19 AM (Central Standard Time, UTC-06:00)  #    Comments [5] - Trackback
Mac OS X | Objective C | Snow Leopard
# Thursday, September 17, 2009

Error Readout:

unable to read unknown load command 0x80000022

Upgrade to xCode 3.2 with the 10.6 libraries.

This error doesn't do anything to your application except provide some really annoying output to your Debugger Console. File under annoying. You can get xCode 3.2 DOWNLOAD HERE for free at the apple website. It will require you to create a login.
Thursday, September 17, 2009 8:01:43 PM (Central Standard Time, UTC-06:00)  #    Comments [0] - Trackback
Mac | Mac OS X | Objective C
About the author/Disclaimer

My name is Ben Coffman. Currently leading the release of native for iPhone and redefining how banking apps work for Capital One. I have a strong focus on mobile development, building effective development teams and a drive for rapid prototyping and continuous integration using nearly all SDLCs. When I turn the internet off I focus on my family, random hobbies, and sharing moments in life.

My pseudo proactive thoughts
--> Twitter @coffmanben

Learn About Me
--> Linkedin
--> StackOverflow

Blogs I follow:
  1. Big Nerd Ranch
  2. NS Hipster
  3. Scott Hanselman

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Ben Coffman

<April 2014>
All Content © 2014,

Sign In