Have you ever painstakingly crafted a perfect user interface in your Android app, complete with custom views displaying intricate data, only to have it all reset when the user rotates their device? Losing state during screen orientation changes is a common frustration for Android developers, especially when dealing with complex custom views. The default behavior of Android is to recreate the Activity on configuration changes like screen rotation, which means your views are destroyed and rebuilt, losing any dynamic state they held. This can lead to a jarring user experience and require significant effort to reconstruct the view’s state. Fortunately, there are several strategies to prevent custom views from losing state across screen orientation changes, allowing you to maintain a seamless and intuitive user experience even when users switch between portrait and landscape modes. This article will explore these techniques in detail, providing you with the knowledge and tools to ensure your custom views retain their state through configuration changes.

Understanding the Problem: Activity Recreation and Configuration Changes

When a configuration change occurs, such as a screen rotation, the Android system, by default, destroys and recreates the current Activity. This process involves calling the onDestroy() method on the Activity, followed by creating a new instance and calling onCreate() again. This behavior is designed to allow the Activity to adapt to the new configuration, such as loading different layouts for portrait and landscape orientations. However, it also means that any data held within the Activity and its associated views, including custom views, is lost unless explicitly preserved. This is where the challenge lies: how do we ensure that our custom views retain their state across these disruptive configuration changes?

One common misconception is that simply saving data in instance variables is sufficient. While instance variables do persist within a single Activity lifecycle, they are wiped clean when the Activity is recreated. To truly preserve state, we need to utilize mechanisms specifically designed for handling configuration changes. Furthermore, complex custom views often manage internal state that isn’t easily represented by simple data types. This necessitates a more nuanced approach to state preservation, considering the specific requirements of each custom view.

The Android framework provides several mechanisms to handle configuration changes gracefully. These include using onSaveInstanceState() and onRestoreInstanceState(), handling the configuration change manually in the AndroidManifest.xml file, and leveraging ViewModel objects. Each approach has its trade-offs, and the best choice depends on the complexity of the data and the desired level of control. We will explore these options in detail in the following sections, providing practical examples and best practices for each.

Leveraging onSaveInstanceState() and onRestoreInstanceState()

The onSaveInstanceState() and onRestoreInstanceState() methods are the traditional and most straightforward way to save and restore an Activity’s state, including the state of its custom views. When the system is about to destroy an Activity due to a configuration change, it calls onSaveInstanceState(). This method provides you with a Bundle object where you can store key-value pairs representing the data you want to preserve. The keys should be unique strings that identify each piece of data. When the Activity is recreated, the system passes the same Bundle to onRestoreInstanceState(), allowing you to retrieve the saved data and restore the view’s state. This approach is suitable for relatively simple data structures.

To implement this for your custom view, you need to override onSaveInstanceState() and onRestoreInstanceState() in your custom view class. Within onSaveInstanceState(), you can save the view’s internal state to a Bundle object. For example, if your custom view displays a counter, you would save the current count value. Then, in onRestoreInstanceState(), you would retrieve the saved count value from the Bundle and update the view accordingly. Remember to call super.onSaveInstanceState(outState) and super.onRestoreInstanceState(savedInstanceState) to allow the parent class to save and restore its own state. This ensures proper functioning of the view hierarchy.

Here’s an example of how you might implement this for a simple custom view that displays a count:

class CounterView : View { private var count = 0 override fun onSaveInstanceState(): Parcelable? { val bundle = Bundle() bundle.putInt("count", count) bundle.putParcelable("superState", super.onSaveInstanceState()) return bundle } override fun onRestoreInstanceState(state: Parcelable?) { var viewState = state if (viewState is Bundle) { count = viewState.getInt("count") viewState = viewState.getParcelable("superState") } super.onRestoreInstanceState(viewState) } fun incrementCount() { count++ invalidate() // Redraw the view } } 

Note the use of Parcelable. For more complex objects, you might need to implement the Parcelable interface for your custom data types to ensure they can be efficiently serialized and deserialized. See the Android documentation for more information on implementing Parcelable.

Handling Configuration Changes Manually in AndroidManifest.xml

Another approach is to handle the configuration change manually by declaring it in the AndroidManifest.xml file. By specifying the android:configChanges attribute for your Activity, you can tell the system that your Activity will handle certain configuration changes itself. When one of these changes occurs, the system will not destroy and recreate the Activity; instead, it will call the onConfigurationChanged() method. This allows you to update your UI and view states directly without losing data. This is useful for handling simple UI adjustments but becomes complex when the view state is intricate.

To use this method, add the android:configChanges attribute to your Activity declaration in the AndroidManifest.xml file. For example, to handle screen orientation changes, you would add android:configChanges=“orientation|screenSize” to the Activity tag. The screenSize attribute is necessary for API level 13 and above, as the screen size can change independently of the orientation. Once you’ve declared the configuration change, you need to override the onConfigurationChanged() method in your Activity. This method receives a Configuration object that contains information about the new configuration. You can then use this information to update your UI and view states accordingly.

However, be cautious when using this approach. It’s generally recommended to avoid handling configuration changes manually unless you have a very specific reason to do so. Manually handling configuration changes can lead to inconsistencies and unexpected behavior if not implemented correctly. It also requires you to handle all aspects of the configuration change yourself, which can be a significant amount of work. As Google’s documentation states, “Handling the configuration change yourself can be very difficult and is generally not recommended. In nearly all situations, you should let the system restart your app so it can automatically reload it with resources that match the new configuration” (Android Developer Documentation). It is often better to use onSaveInstanceState() and onRestoreInstanceState() or ViewModel for managing state.

• Consider using this method only if you need fine-grained control over the configuration change process and understand the implications thoroughly.
• Always test your implementation thoroughly to ensure it handles all possible configuration changes correctly.

Utilizing ViewModel Objects for Data Persistence

The ViewModel class, part of Android Architecture Components, provides a robust and recommended way to manage UI-related data in a lifecycle-conscious manner. A ViewModel survives configuration changes, such as screen rotations. This means that the data stored in a ViewModel is not destroyed when the Activity is recreated. This makes it an ideal solution for preserving the state of your custom views.

To use a ViewModel, you first need to create a class that extends ViewModel. This class will hold the data that you want to preserve. For example, if your custom view displays a list of items, you would store the list in the ViewModel. You then access the ViewModel from your Activity or Fragment using a ViewModelProvider. The ViewModelProvider ensures that you get the same instance of the ViewModel across configuration changes. Inside your Activity or Fragment, you can then observe the data in the ViewModel and update your custom view accordingly. This ensures that your custom view always displays the latest data, even after a configuration change.

Here’s a basic example of how to use a ViewModel with a custom view:

// ViewModel class MyViewModel : ViewModel() { val data = MutableLiveData<String>() } // Activity class MyActivity : AppCompatActivity() { private lateinit var myViewModel: MyViewModel private lateinit var myCustomView: MyCustomView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_my) myCustomView = findViewById(R.id.my_custom_view) myViewModel = ViewModelProvider(this).get(MyViewModel::class.java) myViewModel.data.observe(this, Observer { data -> myCustomView.setData(data) }) } } // Custom View class MyCustomView : View { private var data: String? = null fun setData(data: String) { this.data = data invalidate() // Redraw the view } } 

Featured Snippet: ViewModel objects persist across configuration changes in Android, making them ideal for preserving the state of custom views. They ensure data is not destroyed when the Activity is recreated during events like screen rotation. By using ViewModelProvider, you can access the same ViewModel instance across configuration changes, allowing your custom view to retain its data and state seamlessly.

Best Practices and Additional Considerations

When choosing a method for preserving the state of your custom views, consider the complexity of the data and the desired level of control. For simple data, onSaveInstanceState() and onRestoreInstanceState() may be sufficient. For more complex data or when you need to share data between multiple Activities or Fragments, ViewModel is a better choice. Avoid handling configuration changes manually unless you have a specific reason to do so, as it can be complex and error-prone.

Always test your implementation thoroughly to ensure it handles all possible configuration changes correctly. This includes testing in different screen sizes and orientations, as well as testing with different API levels. Consider using dependency injection frameworks like Dagger Hilt to manage the lifecycle of your ViewModel objects and ensure they are properly created and destroyed. This can simplify your code and reduce the risk of memory leaks.

Remember to consider accessibility when designing your custom views. Ensure that your views are accessible to users with disabilities, such as those using screen readers. This includes providing appropriate labels and descriptions for your views, as well as ensuring that your views are navigable using a keyboard or other input devices. Maintaining accessibility is crucial for creating inclusive and user-friendly applications. For more information on Android accessibility, consult the official documentation (Android Accessibility).

• Use ViewModel for complex data or when sharing data between Activities/Fragments.
• Test thoroughly across different screen sizes, orientations, and API levels.

Click here for more Android development tipsFAQ

Why is my Activity being recreated on screen rotation?

By default, Android recreates the Activity on configuration changes like screen rotation to allow it to adapt to the new configuration, such as loading different layouts.

When should I use onSaveInstanceState() and onRestoreInstanceState()?

Use these methods for simple data structures that can be easily serialized and deserialized.

Is it recommended to handle configuration changes manually?

No, it’s generally not recommended unless you have a specific reason and understand the implications thoroughly. Use ViewModel or onSaveInstanceState() instead.

What are the benefits of using ViewModel?

ViewModel persists across configuration changes, making it ideal for managing UI-related data in a lifecycle-conscious manner and is great for complex data.

You now have a comprehensive understanding of how to prevent custom views from losing state across screen orientation changes. By employing techniques like onSaveInstanceState(), ViewModel, or carefully handling configuration changes, you can ensure a smooth and consistent user experience. Remember to choose the method that best suits your needs and always test your implementation thoroughly. Don’t let configuration changes disrupt your app’s flow; take control Question & Answer :
I’ve successfully implemented onRetainNonConfigurationInstance() for my main Activity to save and restore certain critical components across screen orientation changes.

But it seems, my custom views are being re-created from scratch when the orientation changes. This makes sense, although in my case it’s inconvenient because the custom view in question is an X/Y plot and the plotted points are stored in the custom view.

Is there a crafty way to implement something similar to onRetainNonConfigurationInstance() for a custom view, or do I need to just implement methods in the custom view which allow me to get and set its “state”?

I think this is a much simpler version. Bundle is a built-in type which implements Parcelable

public class CustomView extends View { private int stuff; // stuff @Override public Parcelable onSaveInstanceState() { Bundle bundle = new Bundle(); bundle.putParcelable("superState", super.onSaveInstanceState()); bundle.putInt("stuff", this.stuff); // ... save stuff return bundle; } @Override public void onRestoreInstanceState(Parcelable state) { if (state instanceof Bundle) // implicit null check { Bundle bundle = (Bundle) state; this.stuff = bundle.getInt("stuff"); // ... load stuff state = bundle.getParcelable("superState"); } super.onRestoreInstanceState(state); } }