UITableView Ads: Inline and Sticky Ads (as seen in our F-MyLife app)

Shaun, Jul 21

Sam from AdWhirl.com asked us to do a write up on how we implemented ads in our F-MyLife app.

When we decided to add ads to FML, we wanted to do in the least obtrusive way to the user, despite what they think in their reviews.

We originally came up with a system where it would insert the ad in the 4th or 5th row of the table view, and then just scroll.  This was great for the users, but it performed horribly for us.  It was pretty much never on the screen.

We changed it so it would insert it in the 3rd row, and then stick to the top, similar to how section headers work (that's actually expect how we did it).  We called this implementation "sticky ads", and it's how we'll refer to it in this post.  These performed incredibly well for us, and we thought it was a good mix for the user.  From our stats, most people open FML frequently, so it really wouldn't get too annoying.  We were wrong.  The users HATED it.

The third, and current implementation of FML's ads are called "inline ads".  The idea was to keep the ads on the screen as much as possible, but not permanently reduce the viewport for the user.  What we did here was move the ad as the user scrolls so it appears every 3 FMLs which is approximately 1 screen length.  So far, the users have responded well to these.  They definitely didn't like them being stuck at the top of the screen though.  The "inline ads" seem to perform much better.  Since the ad is always moving on the screen, it's a bit harder for the user to completely block it out.  Our CTR's have increased quite a bit with this implementation.

Due to the poor performance of the original method, we're not going to bother explaining how it works.

"Sticky Ads"

The sticky method was pretty simple, and for the most part, easy.  Once you're notified by AdWhirl that the ad loaded, reload your UITableView.  From there, you simply split your data set into two sections, the top section, and ad section.

From there, you add the UITableView delegate method to return a custom header view for the ad section, and return the AdWhirl ad.  The only catch here is that the touches will get past to the row behind it.  We prevented this by putting the ads onto a UIControl, which blocks touches from being sent to the UITableView.

You can find the full source for this method in the zip file at the bottom of the post.


"Inline Ads"

The inline ads were far more complicated.  Since there's no (public) way to make the header view not-float while using UITableViewStylePlain, we divided our content up into sections of 3.  Then we double the sections, to create a new section/row for every ad.

We created a bunch of convenience methods to determine what row/section we were in, but it does get messy.  Explaining this line by line is useless.  We've attached a demo project to the bottom of this post that includes source/examples for both methods.  Look over the code, specifically what's going on in the delegate/dataSource methods.  If you have any questions, shoot me an email.


Demo Project / Source Code

Download the source code here: http://tr.im/tnX4

If you have any questions or need any help, shoot me an email at shaun@enormego.com


blog comments powered by Disqus