Warning: (40, 5) Do not place Android context classes in static fields; this is a memory leak

2

I'm running into this warning from Android Studio. Warning: (40, 5) Do not place Android context classes in static fields; this is a memory leak (and also Instant Run breaks) I have a button that opens a DatePicker fragment to select the date.

// Botão para chamar o DatePicker Fragment na Activity principal
    btnSelecionaData.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View view) {
            DialogFragment newFragment = new DatePickerFragment();
            newFragment.show(getSupportFragmentManager(), "datePicker");
        }
    });

When I select the date I pass this information to an EditText that stays in the class that called that DatePicker Fragment with a .setText () but for this to work EditText needs to be static and so Android Studio is giving this warning.

// Classe DatePickerFragment
public static class DatePickerFragment extends DialogFragment
        implements DatePickerDialog.OnDateSetListener {

    @Override
    public Dialog onCreateDialog(Bundle savedInstanceState) {
        // Use the current date as the default date in the picker
        final Calendar c = Calendar.getInstance();
        int year = c.get(Calendar.YEAR);
        int month = c.get(Calendar.MONTH);
        int day = c.get(Calendar.DAY_OF_MONTH);

        // Create a new instance of DatePickerDialog and return it
        return new DatePickerDialog(getActivity(), this, year, month, day);
    }

    public void onDateSet(DatePicker view, int year, int month, int day) {
        // Do something with the date chosen by the user

        //######### ESTE É O EDITTEXT STATIC DA ACTIVITY PRINCIPAL, O QUAL EU PRECISO SETAR COM A DATA ASSIM QUE O USUÁRIO CLICAR NO OK DO FRAGMENT
        etAniver.setText(day+"/"+(month+1)+"/"+year);
        //#########
    }
}

I do not yet understand 100% language work, so I ask ... Is it okay to leave it as it is?

For me it seems like no problem, the value of the variable is only needed while the user is in the activity because as soon as he clicks save the data will be saved in the database and the value of the variable will not matter anymore. To my understanding this String will stay in memory, then it will be replaced by the new value when the user registers another client. So the memory occupied by 1 static variable would be insignificant ... would it? Or does the data that passes through this variable overlap in memory?

    
asked by anonymous 24.10.2017 / 21:12

2 answers

0

I was able to solve the problem (memory leak) by just editing the OnDateSet method inside the DatePickerFragment class. It looks like this:

public void onDateSet(DatePicker view, int year, int month, int day) {
    // Do something with the date chosen by the user
    TextView tv1= (TextView) getActivity().findViewById(R.id.et_aniver);
    tv1.setText(view.getDayOfMonth()+"/"+(view.getMonth()+1)+"/"+view.getYear());

}

In this way the EditText variable in the main activity does not needs to be static , thus solving the (memory leak) problem. The statement went like this now:

private EditText etAniver;
    
27.10.2017 / 12:20
4
  

Is it a problem to leave it as it is?

Yes it does.

This will / may cause the memory used by the application to grow progressively.

This happens because some of the memory allocated in this process will not be released when it is no longer needed (memory leak / memory leak).

The problem is that EditText, like any other type of View, has a reference to a Context, probably in this case an Activity.

An Activity, while in use, can be destroyed and recreated by the system. In order for there to be no memory in more than one same Activity, the memory allocated by the destroyed Activity must be able to be released.

EditText, when declared static , will exist throughout the lifetime of the application. By keeping the reference to the Activity, used to create it, it will not allow the memory allocated to it to be released if another one has been created.

That is, the problem is not in the amount of memory that EditText occupies, but in instances that are referenced by it that can not be freed when they are no longer accurate.

    
24.10.2017 / 22:19