Common Android Development Pitfalls and Solutions: Soft Keyboard, Merge Tag, LinearLayout, and Fragment Issues

Soft Keyboard Hiding Issue When an Activity calls finish() after the back button, the UI is destroyed but the soft keyboard may remain visible, obstructing the next screen. Attempting to hide the keyboard in onDestroy() fails because the current focus cannot be obtained at that stage. Hiding the keyboard in onPause() works, and a null‑check on getCurrentFocus() is required to avoid NullPointerExceptions.

Keyboard Layout Adjustment To prevent the keyboard from covering UI elements, set android:windowSoftInputMode="adjustResize" (or similar) on the Activity and wrap the content that should move upward inside a ScrollView . This allows the layout to scroll when the keyboard appears.

Merge Tag Usage The <merge> tag is effective only when the root layout is a FrameLayout . When used, child views can obtain focus only after manually calling requestFocus() . If the merged layout is inflated without attaching to a root, a runtime exception occurs; setting attachToRoot=true resolves this.

LinearLayout Tips LinearLayout defaults to horizontal orientation; use the layout_weight attribute to distribute space. In horizontal mode, layout_gravity="top/bottom" has no effect, while in vertical mode layout_gravity="left/right" is ignored. To align a view to the right in a horizontal layout, insert a <Space> with layout_width="0dp" and layout_weight="1" before the view.

Fragment Pitfalls

Fragments can improve UI modularity and memory usage, but they introduce many challenges:

getActivity() NullPointerException : Occurs when a Fragment is detached (e.g., after popBackStack() ) but an asynchronous task still calls getActivity() . A safer approach is to store the host Activity in a member variable during onAttach() and use that reference.

"Can not perform this action after onSaveInstanceState" : Triggered when a Fragment transaction is attempted after the Activity’s state has been saved. Use commitAllowingStateLoss() or defer the transaction until the Activity becomes visible again.

Fragment Overlap after Configuration Changes : When the Activity is recreated (e.g., rotation or low‑memory kill), the system restores Fragment instances from FragmentState , which does not store the hidden/shown state. Consequently, all Fragments appear shown, causing overlap. Bind a unique tag to each Fragment and, after a restart, locate the Fragment with findFragmentByTag() and explicitly hide() the ones that should be hidden.

Fragment Nesting Issues : Use the correct FragmentManager ( getChildFragmentManager() for nested fragments). In support library versions < 23.2.0, startActivityForResult() from a child Fragment does not deliver results; upgrade to ≥23.2.0.

Improper Removal with remove() : Removing a Fragment that was added to the back stack does not truly discard it; popBackStack() must be used for proper removal.

Fragment Transition Animation Bugs : When popping multiple Fragments or quickly replacing one with another, animations can cause state loss or visual glitches. Delay subsequent transactions until the previous animation completes, or disable animations for the affected Fragment.

Sample code for safely accessing the host Activity in a Fragment base class:

public class BaseFragment extends Fragment {
    protected Activity mActivity;
    @Override
    public void onAttach(Activity activity) {
        super.onAttach(activity);
        mActivity = activity;
    }
    // Use mActivity instead of getActivity()
}

Sample transaction handling after a configuration change:

Fragment fragment = getSupportFragmentManager().findFragmentByTag(MyFragment.class.getName());
if (fragment != null) {
    FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
    ft.hide(fragment).commit();
}

By following these guidelines and applying the provided code snippets, developers can avoid common Android UI and Fragment pitfalls, leading to more stable and user‑friendly applications.