Arguing for training resource is something that we really shouldn’t have to spend too much time doing. This is a fast moving industry with new technologies, concepts and business practices seemingly emerging every other week. If we don’t keep ourselves abreast of these changes and their potential impact on our business operations then who else will? But, the realities are that new technology will get released after training budgets have been agreed and then we find ourselves spending valuable time on the cost-benefits rather than concentrating on educating and equipping our staff/teams and bringing insights & knowledge to the wider business.

Now, you’re probably asking yourselves what learning iPhone programming has to do with Advertising Operations, after all it’s not like you’re looking for seasoned C++ developers when recruiting a new Trafficker or requiring your Campaign Managers to have a Degree in statistical methodologies. But my argument has always been that AdOps lies at that intersection of Technology/Development, Advertising Theory, Statistics/Analytics and Business Development. When new technology rears and the business want to know how to leverage advertising on it then we’re the ‘go-to’ people. When there is no-one else in the company who can give a view on some latest gadget or have an opinion on how such technologies can be brought under the wider advertising strategies… you need to speak to AdOps. Keeping abreast of technological change is second nature for AdOps people, if your business doesn’t have someone with AdOps experience who is consulting with your Business Development group then you’re missing a trick.

This isn’t about getting your staff to become iOS developers, it’s about educating them to understand how these devices work in order that they are then able to advise how best to implement advertising technologies.
The more your staff are empowered by this knowledge and understand how such systems work, then the easier it will be when managing the impact of their uptake by your customers. Ultimately this should feed into the overall approach your company takes in reacting rapidly to such huge changes in the technology landcape.

All of the following courses contain between 10 and 13 videos each of which last approx 1-2hrs and will require access to a Mac running Xcode.

iPhone Application Development [Stanford]
http://itunes.apple.com/itunes-u/iphone-application-development/id384233225#ls=1

Developing Apps for iOS [Stanford]
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=395631522

iPhone Application programming [RWTH Aachen]
http://itunes.apple.com/itunes-u/iphone-application-programming/id390395304

Advanced iPhone Development [Madison Area Technical College]
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=407243032

Cloud Four has an article on iPad orientation detection through CSS here:
http://www.cloudfour.com/ipad-orientation-css/
They supply an example of their techniques as well:
http://www.cloudfour.com/ipad-css/

NCZOnline – iPad web development tips:
Amongst other topics covered this article deals with the all important: User-agent string, iPad detection through Javascript as well as ways to ascertain screen dimensions and orientation:
http://www.nczonline.net/blog/2010/04/06/ipad-web-development-tips/

Smashing Magazine has porovided some well thought out issues to consider when starting out developing web-pages for the iPad & iPhone:
http://www.smashingmagazine.com/2010/05/28/web-development-for-the-iphone-and-ipad-getting-started/

HTMLGoodies has an article detailing more in-depth approaches to orientation on the iPad & iPhone:
Detect and Set the iPhone/iPad’s Viewport/Orientation Using JavaScript, CSS & MetaTags

Using CSS to handle Orientation on the iPad:
So, the upside is that this is a lot easier than you might think. WebKit/Safari supports the CSS media query declarations based on orientation. You can simply specify two CSS files which contain the layouts for portrait and landscape and place the following two lines in your pages HEAD tag.

<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">
<link rel="stylesheet" media="all and (orientation:landscape)" href="landscape.css">

And then simply amend the layout for each orientation accordingly, in the example below they use it to hide/show a H1 tag accordingly. Here’s a working example:
http://www.cloudfour.com/ipad-css/.

On the desktop I have access to numerous tools that help me understand and debug what my adserver is doing. Tools such as httpWatch, httpFox, Fiddler2, Charles, HTTPScoop and FireBug. These tools intercept HTTP traffic and allow you to analyse, check and view the response from the remote adserver. I use this extensively to test response times, debug connectivity & delivery issues, view mimetypes & cookie data amongst other tasks. Once you’ve used these tools it’s difficult to understand how you’ve managed so long without them… that is until you start delivering ads outside of your desktop environment where these tools no longer exists or the devices are unable to provide this information natively or without jailbreaking/rooting your phone.

So, when we started developing the next iteration of our iPhone app we needed to create an environment where we could replicate the tools we’ve come to expect on the desktop for the mobile app as well. Having just moved our entire team to MacOS from Windows based machines this proved to be interesting.

How this works:
Basically we are creating an ad-hoc network on your Mac desktop which the iPhone or other device can connect to. We are then going to route the mobile traffic through your desktop’s Ethernet connection. HTTPScoop sits on the ethernet connection watching and reporting all traffic that flows through it to port 80 (or whatever port you have decided to monitor). This method allows you to visualise the HTTP traffic of your iPhone/Android etc on your desktop and enable you to check these calls are being made correctly. This tutorial describes how to setup your desktop (I’ve used Snow Leopard, MacOS X here) to intercept and display HTTP requests using HTTPScoop made by your mobile device. it requires that you have or are running the following:

Requirements:

• MacOS X (I’m using 10.6 – Snow Leopard) running Airport
• A working copy of HTTPScoop (http://www.tuffcode.com/) Free 14 day trial or only £10 per licence
• An active internet connection.
• Mobile device running the app you need to test

Process Outline: This is what we’ll be covering.

1. Using Internet Sharing create an ad-hoc wireless network through your Airport card.
2. Connect mobile device to the ad-hoc wireless network
3. Start HTTPScoop and configure to show http ethernet traffic
4. Activate the mobile app and watch the results.

Create an ad-hoc wireless network through your Airport card.

1. Got to System Preferences and click Sharing under the ‘Internet & Wirleess‘ group.
2. If needed click the padlock to make changes
3. In the Services list click Web Sharing, we need to activate this as otherwise internet sharing will not work properly for some reason.
4. Next click the Internet Sharing service, options (‘Share your connections from’ and ‘To computers using’) will appear to the right of this.
5. Choose Ethernet from ‘Share your connection from:‘
• tick Airport from the list ‘To computers using‘
• click ‘AirPort Options‘
• Name your Network eg; ‘AdOps’
• Enable WEP encryption and add suitable password if needed (it is WEP after all!) & click OK
• Tick the Internet Sharing box (in the Services list) to activate it, this will grey out the Internet Sharing options., the icon should now have turned green (previously it may have been red). You will be asked for your password to authrorise this.
6. Tick the Internet Sharing Box this will activate Internet Sharing, you will be asked to confirm this is what you want, click ‘Start‘ to continue.
7. Retick the padlock to submit and lock the changes.
8. Your ad-hoc wireless is now setup and ready for you to connect your mobile device to it.

Start HTTPScoop and configure to show http traffic: Connecting to and tracing/view those HTTP calls.

1. Start your copy of HTTPScoop. Next we will configure it to show the traffic you want.
2. Choose the Ethernet (‘eth0‘ or ‘en0‘) option from the dropdown to the right of the HTTPScoop window) then click ‘Scoop‘ – this will start to track all HTTP traffic on your ethernet connection NB: You may see other traffic appear if you have other apps/browser running in the background which are active. To make things simpler close any browsers and other apps using HTTP Traffic down (eg; RSS readers).
3. Click the ‘Scoop’ button, this will start recording the HTTP traffic, as this is a privileged service you will need to enter your password.

Connect mobile device to the ad-hoc wireless network:

1. Connect your iPhone/Android/Tablet or other device to the newly created ad-hoc network.
2. Start the application you wish to monitor, after a while & when the app is making HTTP calls you will start to see data being recorded into HTTPscoop.

Caveats & Postscript:

• HTTPScoop by default only monitors HTTP traffic on port 80. If you need to monitor other traffic eg; HTTPS on port 443 then this can be accomplished by turning HTTPScoop off and amending the ports monitored through HTTPScoop->Preferences.
• Yes, I am aware that this method does theoretically allow you to set up and adhoc network and monitor any attached device (whether it belongs to you or you have permission to view this data or not) so please use this method wisely. Be aware that you MUST have permission to intercept the mobile device’s HTTP Traffic, capturing unauthorised HTTP traffic may be illegal in some jurisdictions..
• HTTPScoop has more help/information here: http://www.tuffcode.com/support.html
• I’ll be posting alternative methods using different software (eg; Charles debugging Proxy) as well as methods that work on Windows very soon.

Links:
HTTPScoop

I’m keen to have a mooch/play around under the hood, hopefully I’ll be proved wrong. The current Apple App submission process is far from being a smooth and easy process, it’s slow and cumbersome and communication is poor. Now add in iAds to the mix… and what if Apple don’t like the ads we’ve submitted, what if they don;t meet their exacting criteria? Only time will tell. And lastly…

And lastly, Apple are demanding 40% of revenues, which seems rather high.

Update: 2010-04-13 17:18pm – Here’s some links to related articles as the story unfolds.
Apple to Lend Hand to iAd Producers [AdAge]
Apple iAd Platform: A Case of the Rich Getting Richer [PCMag]
iAd for the Win as iPhone 4′s Biggest Blockbuster [Macnewsworld]
Is Apple Trying to Create a Mobile Ad Monopoly on the iPhone? [148apps]

The latter article deals with a clause in the Developers agreement that states:
Section 3.3.9:
…the use of third party software in Your Application to collect and send Device Data to a third party for processing or analysis is expressly prohibited.

“If you build your application with features based on a user’s location, make sure these features provide beneficial information, if your app uses location-based information primarily to enable mobile advertisers to deliver targeted ads based on a user’s location, your app will be returned to you by the App Store Review Team for modification before it can be posted to the App Store.”

Original article: developer.apple.com
I’m not too sure how this will affect existing applications or whether they’ll be pulled from the Appstore. But if you’re building mobile apps for the iPhone bear this in mind.