CODEWITHSUNDEEP
androidobjectoncreate
vidulaJ
vidulaJ

Reputation: 1270

The proper way of instantiating and initializing objects in android

I have several packages in my android project containing a number of classes. When I want to create an object of a certain class in a UI activity, I had used a method of creating a private object and initialize it before the onCreate() method where the UI activities are in a separate package.

private SomeClass someClass = new SomeClass();

onCreate(Bundle savedInstanceState) {
   // Activity
}

I have noticed my senior programmers use another method such that they declare the object before onCreate() and initialize it when the object is needed. What is the difference and suggest me the best way? I want to make myself correct if I am doing something wrong here.

Upvotes: 4

Views: 5219

Answers (3)

makata
makata

Reputation: 2258

I usually prefer the second approach because the object will be created only when needed. In the first approach you are creating a singleton object. The object takes memory even before when it is needed. Some situations I prefer the second approach are:

  • If the same object will be used from different parts of the activity. Thus you do not want to check for null every time before use want a clean code and you want cleaner code.
  • If there will be a single common object for the class that will not change through out. Usually you make it static. Good example is:
    String LOG_TAG = MyActivity.class.getSimpleName();
  • If the object will be used frequently in your activity. For activity that makes frequent communication with the server, for example, you should create the object of the class which makes the communication this way. Additional example is

If the object will be used in certain part of the class, you should consider declaring it inside that class.

Upvotes: 0

meyo
meyo

Reputation: 116

At first sight, i'd say that if you declare the variable/object inside onCreate, you only will have it available in that method. (Local scope variables)

Creating the variable outside and initialize the variable/object inside the first method that is executed (onCreate) you will have a whole-class variable that you may use wherever in the class, just be careful to protect the access to it with if(var != null) to avoid NullPointeException. (Gloabal scope variables)

I personally do not prefer any of two, I just use it properly for every case, due te second case retains memory for a longer time, and that is unnecessary if you use that var in a local scope only

For example, if you need a MediaPlayer that plays at start of an Activity and stops at the leaving, you'd better to declare it globally, in order to initialize it in onCreate, make it play in onResume, make it stop in onStop and release it in onDestroy, so:

  • You only initialize the MediaPleyr once (onCreate)

  • Every time you re-enter the activity (onResume) the MediaPlayer starts and does not need to be initialized

  • When leaving the Activity, the MediaPlayer stops (onPause)

  • When Activity no longer needed the memory is released, so no "IllegalState" exceptions or object leaks (onDestroy)

*You also could do all that with a bunch of listeners (onPreparedListener, onCompletionListener, ...), but this is just another way, and have slightly diferent behavior

Upvotes: 1

Illegal Argument
Illegal Argument

Reputation: 10338

For some reason I like staying with the first approach for class level variables. This spares me the trouble of dealing with nullpointerexception if the class's object has not been initialized. Stay with the first one. For example lets take String class:

String mystring;
//in some functions deep inside code
mystring = "hello world";//works great with string

But lets take a similar string buffer example:

StringBuffer mystring;
//in some functions deep inside code
mystring.append("hello world");

In second example I forgot mystring = new StringBuffer(); So the .append will give nullpointer exception and the editor is generally clueless. this happens a lot than you will expect. Same is the case with arrayList and others.

Upvotes: 1

Related Questions