Since I started programming for Android (I believe due to Google examples), I have the habit of creating internal classes for features related to Activity .
Example : If Activity connects to the database (and if the request is specific to this screen), I create an inner class that extends from AsyncTask .
I wonder if there is any advantage in using this approach?
Is there any gain in performance?
Or is it just a structural issue?
Regarding Android and specifically the use of Inner Class in an Activity your concern should focus on issues he (use) may bring with regard to Memory Leaks .
The life cycle of an Activity is not fully controlled by us, and can be destroyed at any time by the OS.
An Inner Class , which is not declared static , or an inner class maintains an implied reference to Activity, the memory allocated by it is reclaimed when it is destroyed and recreated during a configuration change (device rotation for example).
So any advantage (arguably if any) that the use of Inner Class can bring is conditioned by the existence or not of the danger of # For reading: How to Leak a Context: Handlers & Inner Classes
Activitys, Threads, & Memory Leaks
When exactly is it leak safe to use (anonymous) inner classes?
The use of Inner Class makes the total sense in several cases. If no other class needs / uses it, make it private. If it does not require exclusive access from other members of other classes, make it static because this will cause it to allocate less memory. At official documentation :
Use the non-static nested class (or inner class) if you require access to an enclosing instance's non-public fields and methods. Use static nested class if you do not require this access.
However, another point of view is if your class is already gigantic. That is, with too many lines. Many developers do not like using Inner Class to not increase the number of rows in their class.
Like everything else, use it with wisdom and common sense to enjoy a healthy architecture.
It's just structural! In the compilation process, each Inner Class is done separately and has even a little more attention from GarbageCollector (I can not guarantee it has higher performance). In practice, they are much faster to develop and make everything more organized.
If you look at any of the official source code for Oracle , you will notice the use of the Inner Class.
Note: This is a complementary answer to @ramaral.
The notion of being careful of memory leaks is real and very important. However, after reading the two articles I would say that, at the very least, they are wrong.
What do you mean by that the problem is not in the inner classes but in you referencing activities or other disposable objects in objects that persist .
It makes as much sense to blame internal classes as it does to use threads.
Now, it does not matter if it is an inner class or not, static or not, the temptation to reference activity is great and chances are that the developer will eventually pass the reference to the other class somehow. In other words: any object with a reference to Activity can cause the memory leak. It can even be an inner class within a method in another class that accesses the Activity received in the parameter of that method.
In some examples in the articles cited, it is said that the virtual machine does not clean threads. Correct, but that's true in any case. So even the "good" example of the article still presents a memory leak. It may not leak Activity, but it sure dumps threads, because they are never destroyed. This can be as bad as memory over consumption, since the application will have an increasing number of threads doing the same thing at the same time.
So, rather than worrying about the subtleties of the inner classes, the developer should look to clear the allocated resources or at least check that they are no longer allocated.
Regarding the use of internal classes, as others have said, the biggest question is structural, since they are compiled separately from the main classes into .class individual files.
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 the encapsulation of some elements.
Anyway, if you are giving visibility to some method or attribute just so that a particular class can access them, you might want to consider using an inner class or another design option.
In Java in general, the use of internal classes is extensive, from the Java code itself to the encouragement to use lambdas in version 8. Those who adhere to functional programming techniques can not be afraid and have seen many renowned softwares making extensive use of internal classes.
Summary: Do not be afraid of inner classes. Even the best developers can not understand or predict all the subtleties that can cause problems in an application or application. But it is imperative, as did the author of the article, that you learn techniques to monitor and diagnose problems and not just trust that everything will be right because you followed the rules X or Y.
