Editor’s note: This post was provided by Seán Dillon from his blog: Adtools.
The Problem:
Your company is developing an app that will utilise your adserver to deliver and render ads. How do you ensure that the app is calling the right ads and then later when it’s in use by your users how do you check problems with adcalls into that app without recourse to httpWatch, FireBug etc….
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.
- Using Internet Sharing create an ad-hoc wireless network through your Airport card.
- Connect mobile device to the ad-hoc wireless network
- Start HTTPScoop and configure to show http ethernet traffic
- Activate the mobile app and watch the results.
Create an ad-hoc wireless network through your Airport card.
- Got to System Preferences and click Sharing under the ‘Internet & Wirleess‘ group.
- If needed click the padlock to make changes
- In the Services list click Web Sharing, we need to activate this as otherwise internet sharing will not work properly for some reason.
- Next click the Internet Sharing service, options (‘Share your connections from’ and ‘To computers using’) will appear to the right of this.
- 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.
- 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.
- Retick the padlock to submit and lock the changes.
- 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.
- Start your copy of HTTPScoop. Next we will configure it to show the traffic you want.
- 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).
- 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:
- Connect your iPhone/Android/Tablet or other device to the newly created ad-hoc network.
- 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
The Problem: Your company is developing an app that will utilise your adserver to deliver and render ads. How do you ensure that the app is calling the right ads and then later when it’s in use by your users how do you check problems with adcalls into that app without recourse to httpWatch, FireBug etc… 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…