user4983836
user4983836

Reputation:

What is difference between Fields and Constants in android documentations?

What is difference between Fields and Constants in android documentations? For example in View Class we have Fields and Constants.Whiles, I think that the Constants in View Class are Fields. Because each variable in each class is Field. Please example for me about this ambiguity.

Upvotes: 2

Views: 1110

Answers (3)

K patel
K patel

Reputation: 64

Had same doubt though got the correct answer. In ViewGroup.LayoutParams class there are three constants and three fields

Constants :

int WRAP_CONTENT
int FILL_PARENT
int MATCH_CONTENT

Fields :

public int height
public layoutAnimationParameters
public int width

the difference can be seen in the source code of android

https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7857

here we see

public static final int FILL_PARENT = -1;

so the constants are nothing but fields which are final

Hope this helps!!

Upvotes: 0

AterLux
AterLux

Reputation: 4654

There is no such thing as a Constant in Java. There are only fields which you can mark static to became a class field (i.e. one instance per class, for all objects of the same class, rather than one per each object, as if without "static"). You can access static fields by class name reference, without instantiating the class (i.e. MyClassName.sMyStaticField) Furthermore, you can mark your field final. That means the field value assigned in initialization code and will never change. If you are assigning to static final field a constant value (for example, a number), this value will be unchanged and the same for all class instances. So, in Java it is used as a constant value, to assign a particular value to a particular name. Since their values are known at a compile time, they can be used to make conditional compilation. Part of your code, depending on such constant values, could be excluded at a compile time

public static final boolean ENABLE_MY_SUPER_DUPER = false;

...


if (ENABLE_MY_SUPER_DUPER) {
    doSuperDuper(); // Not just never executed, but not even compiled
}

That's cannot be happened, if value assigned to a field could not be known at a runtime (for example, references to objects, or arrays)

So, technically, static final fields and so called "constants" is the same, but in documentation "constants" denotes some predefined constant values, that the same for all applications (i.e. numbers, string constants etc.). While in "field" under "static final" there are some objects, which are instantiated once just after application starts, but it's value cannot be known at a compile time. For example, arrays, some object instances, etc. Technically you cannot alter their values, since they are finals, but you can alter their internal content. I.e. you cannot create new object or array and assign it to the same field, but you can alter items or fields of already created array/object.

Upvotes: 2

fadden
fadden

Reputation: 52353

When your app is compiled, any constant values are compiled directly into the application. Using an example from @CommonsWare's comment, ACCESSIBILITY_LIVE_REGION_ASSERTIVE is an integer with the value 2. That value will continue to be used by your app even if the View class is updated in a future release of Android, which is why you can't put "what version of Android am I currently running on" in a constant. Conversely, it's a fine way to record which version of the SDK your app was compiled against.

The fields are final, which means you can't change them, unless you use JNI, in which case you can. However, because the compiler uses the values directly whenever possible, changing the value of the final fields won't affect any code -- unless it accesses them through reflection.

So the distinction between "constant" and "field" may be of importance.

Primitive types and Strings may be constants. For arrays and other object types, such as the int[] used for SELECTED_STATE_SET, the reference itself is read-only, but the contents of the object are not. This is true of any mutable object type, so it doesn't make sense to list them under "constants".

Upvotes: 3

Related Questions