Navigating a New Codebase: Tips and tricks for getting up to speed quickly

Finding Things When You’re Completely Lost

Sometimes you don’t really know where to begin, such as with your third and final ticket:

Ticket #3

Feature Request: toggle the status bar visibility when the screen hides the menu content.

Make sure the status bar animates with the rest of the navbar when animating in and out.

Depending on your knowledge of UIScrollView‘s delegate, you might have no clue where to start with this feature. All you know is that when you pan up or down on the web content the navbar and toolbar views resize themselves. In order to figure out what’s happening, the best way is to trigger the event when running the app on the device or the simulator and use some intelligent breakpoints to guide your way.

But how do you trigger a breakpoint when you have no clue where to set it? This is where you break out the Where The Heck Am I Breakpoint! :]

With the Wikipedia app running on the simulator, navigate to the same screen illustrated in the ticket. Navigate to the lldb console, pause the debugger, then type the following at the lldb prompt:

rb . -s Wikipedia

This command sets a breakpoint in every single method and function of your app. If you have any long running code (i.e. OpenGL, or background networking) that recurs constantly, this might not be a good option. It works wonders, however, if you’re just lost and need to get a bearing on your location in the code.

Resume the application by pressing the Play button. Start dragging the web view to simulate the action of hiding/displaying the navbar and toolbar. Be sure to use a drag motion; don’t simply just tap on the view or else you’ll break on the wrong event.

You’ll immediately hit a breakpoint from a UIScrollViewDelegate method in WebViewController. Scan the code for anything that looks of interest; there’s nothing here relevant to your interests so continue execution.

After a few more clicks of play, you’ll come across -[WebViewController scrollViewDidScroll]. This UIScrollView delegate method contains code that looks rather interesting due to the aptly named adjustTopAndBottomMenuVisibilityOnScroll method call. Looks like you’re almost there!

Delete the breakpoints in the lldb using the following commands:

br del
About to delete all breakpoints, do you want to do that?: [Y/n] Y

Hunt down the correct method using the Cmd-click approach to jump to methods of interest. Check your path to the correct method in the solution below:

[spoiler title=”Solution”]
-[WebViewController scrollViewDidScroll:] line 1089, leads to
-[WebViewController adjustTopAndBottomMenuVisibilityOnScroll] line 1125, leads to
-[RootViewController animateTopAndBottomMenuHidden:] line 372
[/spoiler]

Navigate to the method provided in the solution above and hunt down the +[UIView animatWithDuration:delay:options:animation:completion] line. It’s here where the changes to the the navbar and toolbar occur.

Insert a call to setStatusBarHidden:withAnimation: into the top of the animation block, so that the beginning of animateTopAndBottomMenuHidden now looks as follows:

-(void)animateTopAndBottomMenuHidden:(BOOL)hidden
{
    // Don't toggle if hidden state isn't different or if it's already toggling.
    if ((self.topMenuHidden == hidden) || self.isAnimatingTopAndBottomMenuHidden) return;

    self.isAnimatingTopAndBottomMenuHidden = YES;
    
    // Queue it up so web view doesn't get blanked out.
    [[NSOperationQueue mainQueue] addOperationWithBlock:^{

        [UIView animateWithDuration:0.12f delay:0.0f options:UIViewAnimationOptionBeginFromCurrentState animations:^{
            
          // *************
          // ADD THIS LINE
          [[UIApplication sharedApplication] setStatusBarHidden:hidden withAnimation:UIStatusBarAnimationSlide];
          // *************
  
  // Remainder of method....

Build and run your app; slide the web content up and down to see how your fix looks.

Note: Despite the fact that styleguides abound, developers always have unique coding quirks. They’ll typically stick to a specific implementation pattern when dealing with certain scenarios.

For example, a developer might prefer to not hook up any view controllers via segues in Interface Builder and instead rely on Storyboard IDs instantiated through code. It’s the ability to notice these types of patterns and being able to anticipate — without bias — how other developers handle these situations that makes you a great code navigator.

Where to Go From Here?

You can view the changes you made to the Wikipedia repo by checking out the finished-tickets branch in the repository. Use your preferred git check out method or enter the following commands into Terminal:

git stash
git checkout finished-tickets 

You have learned how to get a reference point in your codebase while you navigate using symbolic breakpoints. You have learned how to visually associate both UIViews and UIViewControllers — and all their subclasses — using View Debugging.

In addition, you’re leaving here with a nifty lldb command to help you get your bearings when you’re unsure where to start.

Debugging code plays a huge part in navigating code; this tutorial barely covers the basics. If you want to be a better code debugger, check out the videos or Intermediate Debugging tutorial on this site.

In addition, check out Facebook’s Chisel. Chisel is incredibly useful when navigating a new codebase by associating what views are where when navigating code. You may want to check out this tutorial to learn more about Chisel.

Do you have your own tricks and tips for navigating large codebases? Come share it in the forums below!