A member in a class is a component that is identified by a name that is unique among all the members of the same class, with the exception of methods that can be overloaded.
Members can have one of three possible visibilities (scopes). For references, refer to Oracle’s documentation on this topic.
A private member is one that is visible only within definitions of the same class.
Private members are not even available to other definitions of the same package, and therefore is the most narrow of all scopes. Private members are components that are very specific to the class itself.
The default scope is package level. This means a member without any modifier is visible to all other class definitions of the same package.
“protected” means a member is visible to subclasses.
“public” means a member is visible to all. There is no restriction placed on this member.
A member that is marked static is one that belongs to the class itself and not any object that is instantiated from the class. In other words, it pertains to the cookie cutter, but not cookies cut out by the cookie cutter.
static members are accessible without having any object created, and therefore is often used to represent constants and other forms of enumeration. static can be combined with any scope control keywords to limit the visibility.
Note that static can apply to both variables and methods. In the case of methods, a static method is one that is callable without having an object (of the class) created. As such, however, a static method can only access static variables because there is no instance-based variable available to such methods.
A constructor is a special member method that is responsible to initialize an object of the class when it is first allocated memory and created.
Every class has a default constructor that takes no parameters. However, addtional constructors that overloads the name of the class can be defined. A constructor does not have a return type, and it must be public.
An Android activity (object) represents a screen. The user-interaction components are, interestingly, not members of the corresponding Activity class. This is because the UI components are created based on the layout specification as independent objects, and accessed only via the findViewById method of an Activity object.
The underlying data structure of a screen, on the other hand, is something that can be represented as member of the Activity class. However, keep in mind that an app may have multiple screens, and these screen do not share any members.
This means any data structure that is common to multiple screens of the same app needs to be represented by objects that are independent to Activity objects.
We will discuss this in more details in a module that discusses the MVA architecture.