This post will list some of my favourite features of a Proxy tool that are used on a daily bases in my team. It’s about giving you the overview of how such a tool will help you be more efficient in your day-to-day development process. It won’t get into details of how to setup a proxy, how to use these features or which specific tool to use – this will be covered in a future post.

Let’s get to it!

5 ways to make your Android development more efficient

1. Traffic monitoring

One of the simplest reasons that comes in mind when you hear the word proxy is traffic monitoring. Yes, you can monitor everything that moves through the “wire” – you can see all network requests that your phone is doing and the responses it’s receiving. If your Android application uses some type of backend server to push/receive information (and we know most of the applications nowadays do so), this will soon become a MUST for you. Not only can you verify super easily if your application is hitting the right endpoint with the right parameters on your server, but you can easily spot if the misbehaving of the app is caused by a wrong server response. Also providing a proxy log file when writing a bug is tremendously helpful to developers (be it Android or backend) to debug and find the problem faster.

2. Network throttling

Our apps usually work great while we’re developing them in the office environment, using the latest-and-greatest phones and unbelievably powerful WiFi connection. Things are different for the majority of our users though.

Most proxy tools have the powerful option to throttle the network connection to certain levels. There are many options you can usually tweak (stability, bandwidth utilisation, % lost packages, etc) to replicate certain network conditions you want to test.

It’s highly recommended (no, it’s actually mandatory :P) to play with your app in different network conditions – you’ll notice places where it becomes unresponsive, maybe an orientation change causes the app to get in a messed-up state, or a non-cancelable ProgressDialog is taking way too long without a real need to block user actions, etc. Problems like these are usually easy to fix, but will really help towards providing the best possible UX to your users.

Best practice here is to throttle your connection to a really slow one and work the whole day like that. It won’t be your most productive day in terms of code, but will be the best one from QA and stability point of view!

3. Rewrite

That’s the real power of the proxy – you can manipulate your server requests and response in every way imaginable!

Want to test the failover scenarios of your app – just add a proxy rule to return a desired error for a specific network request. Now you’ll be able to easily verify if the exponential backoff strategy in your app is working correctly. Wonder what will happen if you get an unexpected 404 Not Found from a network request? Or maybe a 500 Internal Server Error instead of the “expected” 405 Method Not Allowed. Or you want to test this strange scenario when the server returns you “null” value in the productName field – just put a rewrite rule and you’re done.

In short using rewrite is the easiest way to test failover cases in your app.

4. SSL proxying

This one is quite obvious, but it’s so useful if you have some custom login / verification process that it deserves it’s own point. You must install a custom certificate on the target phone (different for each Proxy service you use), enable SSL proxying and you’re done. No more network secrets 😀

5. Bandwidth optimisation

We know that less network requests == more “resting” time for the antenna == longer battery life == happier users.

The more we as developers abide to it, the better the whole Android ecosystem will be. A proxy tool is the easiest way to see in details how much bandwidth your app is using – not only the calls to your server, but also all the tracking / crash capturing / A/B testing / etc. frameworks in your app as well.

It’s a good practice to have some kind of document describing the expected network requests for each screen of the app. Then it’s a matter of hours to verify that you’re not doing any excess network requests, thus using the least network bandwidth you can.

Bonus: Handy, fast, clear

This point is targeting QAs as much as developers. Once you get used to it, the Proxy tool will become a MUST and will be always enabled for each member of your team.

From QA point of view it’s much easier to narrow down the reason for the problem – was is due to a bad server response, or just the client (Android / iOS) didn’t handle it properly. Attaching a proxy log to your bug gives many extra network- and app- state details that you wouldn’t give otherwise – e.g. the productId you were searching for, the exact endpoint you wanted to call, all query params, etc. Sometimes the key lies in these little details, so a proxy log will really save your team some time.

From a developer point of view – I can only say that connecting to the Proxy on my machine is the first thing I do when I get in the office in the morning. It helps me in tracking that the app state is correct, in faster pinpointing the cause of problems and in asking for help the appropriate team member, especially if the problem is a server-side one.

Conclusion

I just scratched the surface here – you can use a proxy tool for so much more, including adding Breakpoints, Map Local file as response, Disable Cookies, Disable Caching, etc.

The few options listed here are the ones I use on a daily bases in my job. They’ve really helped our team to be more productive and efficient. If you find some other proxy features really helpful – please share them as a comment below. Thanks!