Note: this is a complementary response to @ramaral.
The notion of being careful with memory leakage is real and very important. However, after reading the two cited articles I would say that, at the very least, they have the wrong.
What to say is that the problem is not in the internal classes but in you reference activities or other disposable objects in objects that persist.
It makes as much sense to blame internal classes as it does threads.
Now, whether it is an internal class or not, static or not, the temptation to reference Activity is great and the chances are that the developer will eventually pass the reference to the other class in some way. In other words: any object with a reference to Activity can cause the Leak memory. It can even be an Inner class within a method in another class that accesses the received Activity in the parameter of that method.
In some examples in the cited articles, it is said that the virtual machine does not clean threads. Correct, but this is true in any case. So even the "good" example of the article still features a memory Leak. It may not leak Activity, but it certainly leaks threads, as they are never destroyed. This can be as bad as more memory consumption, as the app will have an increasing number of threads doing the same thing at the same time.
Therefore, rather than worrying about the subtleties of the internal classes, the developer should try to clean up the allocated resources or at least check if they are no longer allocated.
As for the use of internal classes, as the others have said, the biggest question is structural, since they are compiled separately from the main classes in files .class
individual.
However, it is interesting that internal classes can access private methods of the main class is vice versa. This is an advantage if you want to keep encapsulation of some elements.
Anyway, if you’re giving visibility to some method or attribute only so a particular class can access them, you might want to consider using an internal class or another design option.
In Java in general, the use of internal classes is extensive, from the code of Java itself to the encouragement of the use of Lambdas in version 8. Who adheres to functional programming techniques can not be afraid and I have seen many renowned software making extensive use of internal classes.
Summary: Do not be afraid of internal classes. Even the best developers can’t understand or predict all the subtleties that can cause problems in an application or application. But it’s imperative, as the author of the article did, that you learn techniques to monitor and diagnose problems and not just trust that everything will work out because you followed the X or Y rules.
If the Inner class is not declared Static she will always have a reference to Outer class. If it is an activity or other that can be destroyed by Android, You can provoke memory Leaks. That is to say "... whether it is an inner class or not, static or not" should the Outer class be an Activity.
– ramaral