We often need to test how our mobile applications run under slow network conditions, as well as verifying that web service upgrades / API changes are backwards compatible.
Using Charles on OSX provides an amazingly simple way to do this.
Setting up OSX as a proxy server
Firstly, you need to set up charles to run as a proxy server on your mac.
In charles open the menu Proxy > Proxy settings…
Under the Proxies tab, make sure you have a port number entered, such as 8888.
Then under the Mac OSX tab make sure Enable Mac OSX Proxy is ticked.
Next you need to get the IP address of your Wi-FI connection, Spotlight Network Utility or open
/Applications/Utilities/Network Utility
Under the Info tab, choose your Wi-Fi interface, and note the IP address.
Setting up an iPad to use the Proxy
On IOS, you can use a proxy server very easily by doing the following.
Go to settings and choose Wi-Fi
Press the blue arrow on the Wi-Fi network that you are connected to, and then at the bottom of the panel, under HTTP Proxy, press the Manual tab.
Enter the IP address of you macs Wi-Fi connection, along with the port number that you set in Charles.
Now, make sure Charles is running on your mac, boot up Safari on the iPad and browse the web.
Charles should prompt you that someone is trying to access your Proxy server, and press Allow.
If you dont see this, then double check your ports, IP adresses and make sure the proxy server is enabled in charles.
Now, any web requests made from the iPad are proxied via Charles. This means you can monitor the requests and responses, but more importantly you can throttle connections to simulate 3g network speeds, set breakpoints to allow you to modify response data, as well as re route requests.
Re Routing Requests
This is the interesting part, as you can very easily now install an existing live mobile app, and without changing the app in any way, point it to a new version of your web service / API.
When your app makes a request for your web service, you will see the request in Charles.
Right click the request and choose Map remote.
Next you can either map the exact URL, or clear the path filed to map all requests to that domain.
You can either map them to an external server, or a local dev server. Enter the domain of your dev server, and leave the paths blank if you want to map all requests.
Now, all subsequent requests to the live service will be routed to your new development service, allowing you to check exactly how your existing applications will handle changes to your API / web service, without having to recompile the old application with a new url.
m.
