Sometimes it is necessary to have a detailed view on the HTTP requests sent by your Android app and also inspect the responses from the server. With a few steps, it is quite easily possible to do this:
Here are some great links to get the basics of memory management for Android applications:
Since I finally found the opportunity to have a look at some Google IO 2011 sessions, here are some links to sessions I can recommend:
Android Development Tools:
Shows some neat tips & tricks for using new (and old) features of the ADT plugin for Eclipse
Android Protips: Advanced Topics for Expert Android App Developers
Provides a lot of great tips and some patterns for common problems, e.g. keeping backward compatibility while still using new features, doing battery efficient data updates, etc.
Memory management for Android Apps
Background information about the garbage collector, memory management in the Dalvik VM and how to find memory problems by using the Eclipse Memory Analyzer
Building Aggressively Compatible Android Games
A good high-level summary of how to make apps compatible for many devices.
MSDN features an article covering reasons why and how managed applications can suffer from memory leaks, how you can find them and get rid of them:
Despite what a lot of people believe, it’s easy to introduce memory and resources leaks in .NET applications. The Garbage Collector, or GC for close friends, is not a magician who would completely relieve you from taking care of your memory and resources consumption.
I’ll explain in this article why memory leaks exist in .NET and how to avoid them. Don’t worry, I won’t focus here on the inner workings of the garbage collector and other advanced characteristics of memory and resources management in .NET.
It’s important to understand leaks and how to avoid them, especially since they are not the kind of things that is easy to detect automatically. Unit tests won’t help here. And when your application crashes in production, you’ll be in a rush looking for solutions. So, relax and take the time to learn more about this subject before it’s too late.
A good point and definitely contains some trues:
„If you get in the habit of using a debugger,“ my mentor pointed out, „you’ll get lazy. A certain part of your brain shuts off, because you expect the debugger to help you find the bug. But in reality, you wrote the bug, and you should be able to find it.“
Still stunned, I asked: „What do you do when you have a really nasty bug?“
He said something I’ll never forget. „I make the machine tell me where it is.“
Make the machine tell you where the bug is. What a wonderful piece of advice. It’s the essence of troubleshooting, whether you’re trying to fix a car that won’t start, trace an electrical fault, or debug a piece of software.