Android – Pauls Blog

Android Fragments and Transactions

Paul Sterl — Fri, 21 Oct 2016 08:51:01 +0000

Problem

Sometimes it is confusing how fragments work in Android and interesting side effects like:

Why have Fragments empty constructors?
Why shouldn’t I pass state variables like they are?
Why do I need this Fragment transactions?
What does addToBackStack mean and do I need it?
Why is sometimes the Activity null in my fragment?

Overview

Fragments are used to wrap functionality into an own reusable UI element. The life cycle is well documented by google. More interesting is, that android may recreate fragments during its life cycle which leads to interesting implications.

Furthermore Fragments are not directly added an visible, as requesting them to show only queues this task. Nevertheless, they will be shown later on.

Sometimes it is also confusing that creating a fragment inside a fragment will always pass the common activity of both fragments into it.

@Override
public void onAttach(Context context) {
    super.onAttach(context); // context is always the activity
}

Dynamic recreation

As android can recreate the fragment during the resume process of an activity. As so state in member variables needs to be persisted. In general, fragments should always be created using a bundle or be dismissed by the activity in the onPause method:

public class MyDialogFragment extends DialogFragment {
    private static final String ARG_PARAM1 = "param1";
    private String mParam1;

    public MyDialogFragment() {} // required

    // Create fragment with call parameters
    public static MyDialogFragment newInstance(String param1) {
        MyDialogFragment fragment = new MyDialogFragment();
        Bundle args = new Bundle();
        args.putString(ARG_PARAM1, param1);
        fragment.setArguments(args);
        return fragment;
    }
    // restore any initial passed arguments as needed
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        if (getArguments() != null) {
            mParam1 = getArguments().getString(ARG_PARAM1);
        }
    }
    // if the param may change during the life cycle of the fragment and need to be stored
    // usually not needed
    @Override
    public void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putString(ARG_PARAM1, mParam1);
    }
}

As long as the fragment is restored, the activity of it may be null. As so it may happen that own threads still running in the fragment may encounter null pointer exceptions.

The easiest way is either:

Stop all running threads in the onPause
Remove all listeners for the time being, but keep the threads, e.g. if you want to keep a socket connection open
save in a boolean variable the fact that your fragment was paused and wait for the resume

Hide and show DialogFragments

Showing a fragment is straight forward, by calling the show method. Now we can pass a second parameter, which is used to find this fragment later on. We can decide by storing the reference in a field variable or just to remember the name. Usually the last is the better approach.

But how now correctly to dismiss the fragment?

// show a fragment
MyDialogFragment dialogFragment = MyDialogFragment.newInstance("init");
dialogFragment.show(getFragmentManager(), "dialog");

// hide a fragment again
Fragment dialog = getFragmentManager().findFragmentByTag("dialog");
if (dialog != null) {
    FragmentTransaction ft = getFragmentManager().beginTransaction();
    ft.remove(dialog);
    ft.commit();
}

The above code example works for any kind of fragment. Of course, it is also possible to cast the fragment into a DialogFragment and invoke the dismiss method.

addToBackStack or not?

The main purpose of the addToBackStack method in the fragment transaction is to allow the user to use consistently the back button. If we modify the code above to:

Fragment dialog = getFragmentManager().findFragmentByTag("dialog");
if (dialog != null) {
    FragmentTransaction ft = getFragmentManager().beginTransaction();
    ft.remove(dialog);
    ft.addToBackStack(null); // remember this change
    ft.commit();
}

Then the user may open the dialog again with the back button on the phone. This is very interesting if you move between different fragments/dialog fragments. E.g.: you have an edit dialog fragment which opens a date time picker dialog. Then you can remove the detail dialog fragment and add the date picker fragment in one transaction. As soon the user hits the back button the detail dialog fragment is again visible.

As the name already indicated, it is a stack of view states, each change to the view is seen as a transaction. The user may pop the stack by using the back button.

In short:

Cancel or just close the dialog/fragment –> don’t add it to the back stack
Navigate to a Fragment like to an activity –> add it to the back stack, so the user can go back

Prevent closing of a Dialog Fragment using the back button

After the fragment was created set cancelable to false.

dialogFragment.setCancelable(false);

Is isVisible or isAdded reliable?

This happens to be the most tricky question. As showing a dialog will not always show the dialog immediately. It only schedules the show operation for the Fragment Manager.

As soon as you happen to see errors like:

java.lang.IllegalStateException: Fragment already added: XxxxxDialog{xxx XxxxxDialog}
       at android.app.FragmentManagerImpl.addFragment(FragmentManager.java:1236)
       at android.app.BackStackRecord.run(BackStackRecord.java:715)
       at android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1552)
       at android.app.FragmentManagerImpl$1.run(FragmentManager.java:487)
       at android.os.Handler.handleCallback(Handler.java:739)
       at android.os.Handler.dispatchMessage(Handler.java:95)

The first solution by just calling getFragmentManager().executePendingTransactions() won’t work.

The reason is typically a multithreading issue, calling/ scheduling multiple show operations for the same fragment from a background thread. The best fix would be to find why this is called multiple times and check if this can be avoided. If not, then an AtomicBoolean could be the rescue e.g.:

public class MyDialog extends DialogFragment {
    private final AtomicBoolean isShowing = new AtomicBoolean(false);

    @Override
    public void show(FragmentManager manager, String tag) {
        isShowing.set(true); // ensure we update our "show" flag
        super.show(manager, tag);
    }

    @Override
    public void onResume() {
        super.onResume();
        isShowing.set(true);
    }
    @Override
    public void onDismiss(DialogInterface dialog) {
        super.onDismiss(dialog);
        isShowing.set(false);
    }
    /**
     * reader for the boolean flag, if show was already called
     */
    public boolean getIsShowing() {
        return isShowing.get();
    }
}

Using the AtomicBoolean enables you now to verify in a multithreaded environment if show was already called on the dialog.

Android Bind Service to the Application cross Activities

Paul Sterl — Thu, 16 Jun 2016 13:37:33 +0000

The Problem

Sometimes we want to bind an Android Service in our activities and wrap inside e.g. our communication to our backend. Now the problem arises when we unbind it again. As usually if we change activities we want this service to survive and be in the very next activity. As soon as we close the last activity we usually want to have this service destroyed.

Just call bindService in onResume and unbindService in onPause would lead to a restart of the service on each activity change. If we move the calls into onStart and onStop then the Service will just live as long as our application lives. Even if it is hidden (e.g. home button press.)

Our Simple Service for this example

public class MyService extends Service {
    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return mBinder;
    }

    public class MyServiceBinder extends Binder {
        public MyService getService() {
            return MyService.this;
        }
    }
    private final IBinder mBinder = new MyServiceBinder();
}

Of course don’t forget the XML Service tag in the AndroidManifest.xml.

Solution 1

A straight forward solution would be to register such Activities in an Android Application class, which is a singleton and let it handle the life cycle.

private volatile MyService mService;
    public interface ServiceUser {
        void attach(MyService s);
        void detach();
    }
    private ConcurrentHashMap, ServiceUser> serviceUsers = new ConcurrentHashMap();

    private final ServiceConnection mServiceConnection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            mService = ((MyService.MyServiceBinder)service).getService();
            for (ServiceUser us : serviceUsers.values()) {
                us.attach(mService);
            }
        }
        @Override
        public void onServiceDisconnected(ComponentName name) {
            if (mService != null) {
                for (ServiceUser us : serviceUsers.values()) {
                    us.detach();
                }
            }
        }
    };

    public  void useService(Class listener, ServiceUser handler) {
        serviceUsers.put(listener, handler);
        if (mService == null) bindService(new Intent(this, MyService.class), mServiceConnection, BIND_AUTO_CREATE);
        else handler.attach(mService);
    }
    public  void detach(Class listener) {
        this.serviceUsers.remove(listener);
        if (serviceUsers.isEmpty()) unbindService(mServiceConnection);
    }

Now we can just create an abstract service activity and call onResume and onPause the useService and detach methods. So far we can still run into odd cases in which the service gets destroyed. Far more concerning is that we have all our Activities registered with our Application class, which could lead to memory leaks.

Solution 2

What if we just delay the unbind method in our abstract base activity? An again cancel this delayed unbind?

public abstract class AbstractMyServiceActivity extends AppCompatActivity {
    private volatile MyService mService;
    private volatile boolean mPause = false;

    private final ServiceConnection mServiceConnection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            mService = ((MyService.MyServiceBinder)service).getService();
            onBackendServiceBind(mService);
        }
        @Override
        public void onServiceDisconnected(ComponentName name) {
            mService = null;
        }
    };

    /** called as soon the service was bound */
    protected abstract void onBackendServiceBind(MyService mService);

    @Override
    protected void onResume() {
        super.onResume();
        mPause = false;
        if (mService == null) {
            bindService(new Intent(this, MyService.class), mServiceConnection, BIND_AUTO_CREATE);
        } else {
            onBackendServiceBind(mService);
        }
    }

    @Override
    protected void onPause() {
        super.onPause();
        mPause = true;
        // we delay the disconnect from the backend service ...
        BackgroundExecutor.execute(new BackgroundExecutor.Task("", 10000L, "") {
               @Override
               public void execute() {
                   if (mPause) unbindService(mServiceConnection);
               }
           }
        );
    }

    // we could expose mPause if we like
}

Again not a lot of less code. But this solution comes with some advantages:

We have no single instance where we register all activities
We can keep the service open / running for a while, if the user just leaves our app for a short time

Android show Keyboard by default

Paul Sterl — Fri, 26 Feb 2016 15:36:14 +0000

Problem

Sometimes we the Keyboard doesn’t show up by default if we e.g. open a dialog and request the focus for an input element. Even following the default tutorials doesn’t really help. As soo here some samples how it will show up.

Solution

Show Keyboard in Dialogs / DialogFragment

Usually the solution the the Android Guide just works using:

Solution 1

@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
  super.onViewCreated(view, savedInstanceState);
  // Get field from view
  mEditText = (EditText) view.findViewById(R.id.txt_your_name);
  // Show soft keyboard automatically and request focus to field
  mEditText.requestFocus();
  getDialog().getWindow().setSoftInputMode(
    WindowManager.LayoutParams.SOFT_INPUT_STATE_VISIBLE);
}

Solution 2

In my personal experience, solution 1 doesn’t always work — it’s more of a happy-case scenario. A more reliable approach is the following solution:

@NonNull
@Override
public Dialog onCreateDialog(Bundle savedInstanceState) {
  final Dialog dialog = super.onCreateDialog(savedInstanceState);
  // show the keyboard as soon we get the focus ...
  dialog.setOnShowListener(new DialogInterface.OnShowListener() {
    @Override
    public void onShow(DialogInterface dialogInterface) {
      txtInput.post(new Runnable() {
        @Override
        public void run() {
          final InputMethodManager imm = (InputMethodManager) txtInput.getContext().getSystemService(Context.INPUT_METHOD_SERVICE);
          imm.showSoftInput(txtInput, InputMethodManager.SHOW_IMPLICIT);
          txtInput.requestFocus(); // needed if you have more then one input
        }
      });
    }
  });
  return dialog;
}

This solutions also just works with the normal AlertDialog as it uses the show listener.

Important to note is, that in either case requestFocus should either be called or set in the xml layout file for the element.

Solution 3: Always show they Keyboard

Where is allway the possibility to always show the keyboard — even if not always really useful:

getDialog().getWindow().setSoftInputMode(
    WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_VISIBLE);

The keyboard could now be shown even if the user can’t input something into any input element. Where in solution 2 the keyboard is only shown of the element gets the focus, in this case the keyboard is just shown.

Request Focus for an Element using XML Layout File

Just add the Tag to the body of the element.

Android Global Exception Handler

Paul Sterl — Fri, 12 Feb 2016 14:51:43 +0000

Background / Motivation

Sometimes it is quite useful to handle/catch exceptions in a central handler. Typical samples are:

Handle Authorization problems e.g. with your backend
Central dispatching of these error to an Exception Collector like Crashlytics (ur just send an email)
Just show a message dialog to the user

Implementation

Just creating an Exception is straight forward java.lang.Thread.UncaughtExceptionHandler. The little more tricky part is integrating it into an Android application. Two obvious ways we might choose from:

Attach the Exception Handler in the Application
- Can’t open UI Dialogs or other Activities properly
- Will be executed for any activity
Attach the Exception Handler in an Activity
- May start other activities
- Needs a Base class to be applied in an easy way to all activities

Exception as Application Handler

Typical here is to log the exception and later on send it to the backend, e.g. after the application was restarted.

This sample code just logs each exception into a file, which we can later on inspect and send to the backend if we like.

Exception Handler

public class LoggingExceptionHandler implements Thread.UncaughtExceptionHandler {
    private final static String TAG = LoggingExceptionHandler.class.getSimpleName();
    private final static String ERROR_FILE = MyAuthException.class.getSimpleName() + ".error";

    private final Context context;
    private final Thread.UncaughtExceptionHandler rootHandler;

    public LoggingExceptionHandler(Context context) {
        this.context = context;
        // we should store the current exception handler -- to invoke it for all not handled exceptions ...
        rootHandler = Thread.getDefaultUncaughtExceptionHandler();
        // we replace the exception handler now with us -- we will properly dispatch the exceptions ...
        Thread.setDefaultUncaughtExceptionHandler(this);
    }

    @Override
    public void uncaughtException(final Thread thread, final Throwable ex) {
        try {
            Log.d(TAG, "called for " + ex.getClass());
            // assume we would write each error in one file ...
            File f = new File(context.getFilesDir(), ERROR_FILE);
            // log this exception ...
            FileUtils.writeStringToFile(f, ex.getClass().getSimpleName() + " " + System.currentTimeMillis() + "\n", true);
        } catch (Exception e) {
            Log.e(TAG, "Exception Logger failed!", e);
        }

    public static final List readExceptions(Context context) {
        List exceptions = new ArrayList<>();
        File f = new File(context.getFilesDir(), ERROR_FILE);
        if (f.exists()) {
            try {
                exceptions = FileUtils.readLines(f);
            } catch (IOException e) {
                Log.e(TAG, "readExceptions failed!", e);
            }
        }
        return exceptions;
    }
}

Activation of the Exception Handler

We need now only to attach it once in our Application:

public class MyApp extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        new LoggingExceptionHandler(this);
    }
}

Enable the Android Application

And of course make sure it is attached in our AndroidManifest.xml.

Exception Handler in an Activity

Attaching an exception handler in the activity allows us to do a little more, most important here starting a different activity work — in the case of the ApplicationContext it would just hang.

Exception Handler

In this case, we check the exceptions if we could gracefully handle them. If so the start the appropriate activity and could pass more informations to it if needed.

public class MyExceptionHandler implements Thread.UncaughtExceptionHandler {

    public static final String EXTRA_MY_EXCEPTION_HANDLER = "EXTRA_MY_EXCEPTION_HANDLER";
    private final Activity context;
    private final Thread.UncaughtExceptionHandler rootHandler;

    public MyExceptionHandler(Activity context) {
        this.context = context;
        // we should store the current exception handler -- to invoke it for all not handled exceptions ...
        rootHandler = Thread.getDefaultUncaughtExceptionHandler();
        // we replace the exception handler now with us -- we will properly dispatch the exceptions ...
        Thread.setDefaultUncaughtExceptionHandler(this);
    }

    @Override
    public void uncaughtException(final Thread thread, final Throwable ex) {
        if (ex instanceof MyAuthException) {
            // note we can't just open in Android an dialog etc. we have to use Intents here
            // http://stackoverflow.com/questions/13416879/show-a-dialog-in-thread-setdefaultuncaughtexceptionhandler

            Intent registerActivity = new Intent(context, AuthActivity.class);
            registerActivity.putExtra(EXTRA_MY_EXCEPTION_HANDLER, MyExceptionHandler.class.getName());
            registerActivity.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
            registerActivity.addFlags(Intent.FLAG_ACTIVITY_NEW_DOCUMENT);

            context.startActivity(registerActivity);
            // make sure we die, otherwise the app will hang ...
            android.os.Process.killProcess(android.os.Process.myPid());
            System.exit(0);
        } else {
            rootHandler.uncaughtException(thread, ex);
        }
    }
}

Activation of the Exception Handler

Now it gets a little more messy. As we need to activate/init this handler with an Activity we have to ensure that either in each Activity or we provide a base activity all other inherit from.

public abstract class BaseActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        new MyExceptionHandler(BaseActivity.this);
    }
}

Sample Code on Github

Sample code on GitHub