Pull to refresh is by far the most popular paradigm used in refreshing feed based views on an iOS device. First introduced by Loren Brichter of Tweetie, pull to refresh has made its way into just about every touch based device out there. Here’s the latest incarnation on the PS Vita (taken from @mattgemmell):

In fact, the idea was so good that Brichter decided to legally slap his name on it. Here’s a picture to help you better understand how this technology works (taken from gorumors.com):

Thankfully, Brichter doesn’t require you to obtain a license to use it shamelessly in your own app, bless him!

Current Solutions

Now, our own Miso app also uses this familiar pattern to refresh our views. But the task of integrating a 3rd party library into our app was not as idiot proof as we had hoped. Here are some popular libraries and why they made me feel uncomfortable:

• Enormego’s EGOTableViewPullRefresh
• Leah Culver’s PullToRefresh

Both libraries are essentially the same, with slight variations. Both libraries employs the use of 3 absolutely crucial methods of UIScrollViewDelegate:

    - (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView;
    - (void)scrollViewDidScroll:(UIScrollView *)scrollView;
    - (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate;

In enormego’s implementation, it is expected that the developer chain the scrollview’s delegate methods to the EGOTableViewPullRefresh to drive the refresh cycle’s core logic. This isn’t ideal because it forces the developer to implement those delegate methods regardless of the developer’s requirements. This solution could definitely be more self-contained and less intrusive on the clients code.

In Culver’s implementation, the problem is the opposite of enormego’s. The delegate methods are literally stolen from you in order to drive the logic. If you implemented them yourself, the entire thing breaks.

One last variant is to have the library become the UIScrollView’s delegate, but also chain every single method back to the original delegate. This is fine, except it becomes extremely laborious to maintain especially if your UIScrollView is actually a UITableView (which extends the protocol UIScrollViewDelegate), or if apple adds some more delegate methods.

Both libraries combine the logic and views into one class, perhaps for the sake of simplicity. What if I didn’t want a boring rotating arrow but an animating rainbow? There’s basically no way to customize the views without modifying the source code directly.

Introducing MSPullToRefreshController

Here’s my main beef with existing libraries:

1. Too intrusive on my own code. I either play an essential part to making the library work, or the library will not work if I exercise some innocent freedoms.
2. I couldn’t provide any custom views.
3. I couldn’t provide any custom behaviors to the refresh cycle.

Instead of whining like I did, our very own CTO (Tim Lee) offered an actual solution to Beef #1: KVO (Key Value Observing). Specifically, to observe the contentOffset property of UIScrollViews.

        [_scrollView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld | NSKeyValueObservingOptionPrior context:NULL];

Using this trick, I was able to secretly offer pull to refresh features to any UIScrollView without having to become its delegate. With this simplification, I was able to quickly extend pull to refresh to all 4 edges of a UIScrollView, just in case you wanted to use the bottom side to load more, or if your feed was laid out in a carousel fashion.

Through the small exercise above, I saw MSPullToRefreshController as a self-contained object that handles nothing more except managing the logic involved pull to refresh cycles. It just didn’t make sense to add anything else to it, unless it enhanced the core behaviors. Translation: Beef #2′s solution doesn’t belong in this class.

To solve Beef #2 and #3 together, I decided to introduce the familiar delegate pattern to MSPullToRefreshController. It is through these methods that the developer will be able to customize behaviors and transform custom views to reflect each state in the refresh cycle.

Now I could easily write a wrapper around a MSPullToRefreshController instance and recreate any existing pull to refresh library by implementing 6 easy delegate methods! In fact, I’ve done just that in the included sample project on github!

Conclusion

Though this library is very simple, this marks my first step in to the world of open source (to reinforce our engineering culture per @nicolas). As @joshbuddy and @nesquena would say, 99% of open source projects stem from frustrations with existing solutions (or lack thereof). I hope somewhere someone will find this more suitable to his/her needs. Thanks for reading!

XCode often slows down the entire system to a crawl, forcing the coder to either restart the application or even the computer itself. Unfortunately, we can’t control how aggressively XCode uses system resources. Fortunately, we can learn to work faster and more efficiently by learning some of the hidden conveniences inside XCode.

Below are some tips and tricks I use in my everyday coding sessions. This post has the beginner in mind, though I hope advanced and expert XCode users may occasionally find something useful.

**Disclaimer: Examples below are done using XCode 4.2.1

Master Your Shortcuts

The goal here is to use the hot keys to speed up your work flow. Reducing the number of times you use your mouse to navigate the UI will help you stay focused on the task at hand by recapturing your attention to the cursor back to the actual lines of code.

• Open new tabs using ⌘T, navigate between them using ⌘⇧{  or  ⌘⇧}
• Build/Run/Clean using ⌘B/⌘R/⌘K, respectively
• Quickly open files using ⌘⇧O and enter file name
• Go to a line using ⌘L  and enter line number
• Jump between .h/.m files using ^⌘↓
• Navigate forwards/backwards in a single tab using ^⌘→ or ^⌘←
• Go to the end or beginning of a line using ⌘→ or ⌘←
• Find text using ⌘F
• In the middle of typing, Tab to autocomplete, Esc to see close matches
• Highlight some code and ⌘/ to comment/uncomment
• Indent or dedent(?) code using ⌘] or ⌘[

This is not an exhaustive list, but these are certainly enough to get you started on training your muscle memory. If you have any other cool shortcuts you’d like to share, please leave it in the comments below.

Maximize Your Usage of Screen Real Estate

How you do this will be a little bit of personal taste. In any case, the point here is make it so everything you can see on the screen is relevant to the task at hand. For example, don’t clutter your windows with unnecessary panels that you will never use. Do you really need the debugger panel on the bottom if you are coding? Or the object panel on the right unless you’re editing a .xib?

Note that window layouts are done on a per-tab basis, and creating a new tab will clone the layout from the previous tab.

Here’s a screenshot of how I chose to layout a single tab for coding:

Let’s consider this portion of the screen (top right):

Direct your attention to 3 buttons (which are mutually exclusive) above “Editor”. From left to right they represent Standard Editor, Assistant Editor, and Version Editor. I use the Assistant Editor, this allows me to edit my implementation file in the middle while having an auxiliary editor on the right, which I use exclusively for “counter parts”, or more specifically, header files. You are free to use a drop down menu to configure what you would like to be placed there. Like so:

If your screen is too small to support two editors, consider using multiple tabs instead.

Next, consider the 3 buttons above “View”. Toggling each in turn will slide in and out a panel from the left, bottom, or right. In this case, I only want the left panel, and more specifically, I only want to see the 4th tab (⌘4) in this panel for any warnings/errors I may introduced while coding this class.

**Aside: You may have noticed the presence of line numbers, which are very useful when looking at code with another person. To turn this on, find the option under the “Text Editing” tab in Preferences (⌘,) .

Moving on, let’s take a look at a tab I use for debugging (a topic to be addressed in a future blog post):

Here’s the setup. A Standard Editor to get the maximum view of a breakpoint’s context. A left panel (5th tab) to detail the thread and stack trace. Also note that I eliminated the Toolbar at the top altogether. A Debugger panel on the bottom for, well, debugging. Note that you also want the split view for the debugger so you can see the local variables and the log at the same time.

Miscellaneous

Handling XCode Behaviors

Say you have two tabs open, one for file1 and the other for file2. You also have a breakpoint in file1, but you are on file2′s tab. Now you run the project and it hits the breakpoint in file1, the default behavior will change the tab with file2 into file1, leaving you with an annoying situation where you have two tabs that are looking at the same file. After a few more hours you’ll end up with multiple duplicates, and now you need to either close the tabs or change the duplicates back to what it should have been.

Here’s how I get around this inconvenience. XCode allows you to change its behavior at crucial times of the development process. Here we are interested to when we hit a breakpoint, which is equivalent to saying the “Run Pauses”, note that this will also happen in the case of a crash. To change this behavior, go to Preferences and mimic this:

In top-down order, the lines with blue check marks tell XCode to do the following.

1. Show the tab named “Debug” (it will create one if this doesn’t exist)
2. Show the 5th tab on the left panel (the one with stack traces)
3. Show the bottom panel (debugger) with the splitview
4. Hide the toolbar at the top
5. Show the Standard Editor

And this pretty much recreates my debugging layout for me. As you can see, there’s a lot of behaviors you can customize and automate, in the end, it is a matter of taste.

Alternative to NSLogs

Consider a different situation, you’ve built and ran your app. You’re noticing some weird behaviors, and you know it may involve a couple functions. To investigate these functions’ order of invocation and/or relationships, you stop the app and start filling in some NSLogs and rerun.

Don’t do this!! Instead, deploy a couple breakpoints in key places and right click on them to edit, pulling up this menu:

This menu is extremely powerful. You can conditionally enable/disable a breakpoint, ignore for some number of times, perform an action, or to automatically continue.

Using a combination of the above, you can effectively sprinkle “adhoc” nslog statements without having to stop your app and recompile the whole thing. And if you know more about gdb or lldb, you can print out values of surrounding local variables too!

Jump to Relevant Definition or Documentation

Maybe you want to see where something is defined. You might try to ⌘F on the project and look for it, but instead you can ⌘+(left click) on an interesting block of character, such as a method name, and it will either pop up a menu to ask you to be more specific, or take you to the only definition right away! You can do the same trick for Apple’s objects as well. You can do the same trick for Apple’s objects as well.

Have you ever tried to search the Documentation in Organizer? It takes an eternity. Instead, use ⌥+(left click) on something you want to search for to bring up a menu like this:

Not satisfied? Click on any of the blue text to bring you full fledged documentation window. I’ve literally typed what I wanted to search in some random place just so I can do the above trick to get to the documentation as fast as possible.

Global Breakpoints

When your application crashes, you probably go into the debugger to identify where the crash happened, then you set up some breakpoints before the offending line, and try to reproduce the exact steps. And hopefully, you’ve reproduced your steps to hit the exact same crash. What if you can insert a breakpoint dynamically right when the system throws the exception? Here’s how:

1. ⌘6 to bring up the breakpoint navigator
2. Click + on the bottom left
3. Add Exception Breakpoint…
4. Done

If you’ve done it correctly, you should see:

That’s it! Next time you crash, you’ll be able start investigating right away!

Conclusion

Now that you know how to work smarter, hopefully you can spend the rest of your time on things that actually matter, such as implementing a feature or fixing a crash. While I’ve dipped into a little bit of tricks regarding debugging, it really deserves its own blog post. So next time, I’ll be giving a small tutorial on how you can use the various instrument tools to help you manage your apps memory usage and performance bottlenecks. Thanks for reading!

Hello readers!

My name is John Wu, Miso’s newest addition to the engineering (specifically iphone) team. For my first blog post, I want to start with something light and talk briefly about who I am and how I came to work at Miso.

I majored in Mathematics as an undergraduate. I chose math for a couple reasons. First, I thought it was easy. Like many of you, math was the one class I never had to prepare for in high school. Math period became synonymous to nap time. I was the kid the teacher never wanted to call on because I’ll deprive others of their opportunity to learn.  Second, I was “good” at it, and by that I mean I felt comfortable manipulating formulas and performing complicated computations, it made “sense”, and I understood the logic. Finally, I believed Math would open the doors to just about anything one could aspire to do — my reasoning was simple: math exists in almost everything, even haikus.

Looking back, I had no idea what I was getting myself into. I was lost during day one of Calculus I. Cryptic concepts such as epsilon-delta, proof by contradiction, theorems, corollaries, and “if and only if” had me dropping classes faster than I could sell my useless TI-89 (did not use this a single time in college). At first, I hated it. I learned proof after proof of theorems that seemed useless. I worked out examples that were so contrived I had a hard time seeing how any of it modeled real life. By the time I graduated with a B.S., I was only comparable in knowledge to mathematicians 200 years ago. My degree felt useless.

But math isn’t pure evil. While extremely difficult to appreciate, crafting proofs, often compared to poetry and painting, is a true art form in and of itself. I distinctively remember showing my professor my one page proof on a fundamental vector space theorem, to which he responded with his version that was exactly 5 lines. This experience led me to my first realization about math beyond calculus: finding the simplest version of a proof for any given theorem, only then will you have understood the theorem in its rawest form. Want some perspective? The popular Pythagorean theorem (a^2+b^2=c^2) has been proven (through distinctive ways) well over 300+ times. My second realization came to me after taking a course in number theory, a sub-discipline studying the positive integers (0,1,2,3,…): not all math is meant to be applicable or even useful, there are numerous theorems out there that well documented and proven, but lack any real world application, they are, in essence, math purely for math’s sake. The mathematicians who engage in this are the picassos and michelangelos of the math world, and who says they won’t offer unexpected insight in the (far) future?

The remainder of my mathematical journey came to an end in graduate school after a tragic realization of myself: that I simply wasn’t bright enough for math, not even to contribute on a microscopic level. I knew this to be true as I found myself begging child prodigies in my classes to help me with my homework. I gave up on a PhD. Rejection was difficult, but not without its lessons. I swallowed my pride, and began searching for something that would allow me to cause a dent. Trusting in my haiku-logic, I eventually found my place in application development.

I found many analogous counterparts of math in development work. Code design is similar to crafting proofs, except I now had the help of my coworkers, and the end goal of creating the simplest version is still sought after. Reading code is like trying to understand proofs, though in a different context, navigating logic turns out to be one and the same. Moreover, my degree accelerated my learning process, my background allowed me look beyond the complexities of the underlying math, such as floating point arithmetic, and focus on creating reusable and scalable code. The differences? Even an average Joe such as myself can contribute, even my code will manage to see the light of day, and be ran thousands of times a day. All along, this is where I belonged.

So I am glad to say, while my choices earlier on in life were based on erroneous assumptions, I do not regret it one bit! And as I continue to work at Miso, I’ll be sure to offer my experiences and help you, the reader, to leverage what we do at Miso to help make your app better. So please look forward to my next post, which will be on styling UINavigationBars in your iphone app. Thanks for reading!