commons-app
Handle configuration changes in the right way
What is the user problem or growth opportunity you want to see solved?
The app doesn't handle configuration changes (theme switch, screen rotation, etc.) as recommended in the official docs. We have configChange property in the manifest for some of the activities, so we do not see any crashes there but for others, we aren't persisting state everywhere.
Is adding configChange to manifest the right way? Probably no. But adding defensive checks everywhere or simply making a property nullable to avoid that crash doesn't seem right either. We need a framework/SOP around how we tackle configuration changes in the app.
We can use a coding agent to figure out all such points in the codebase as long as it suggests the standard ways mentioned in the docs. The problem with solving one crash report at a time with an LLM is that the fix is localised and not maintainable. For instance, in one of the recent PRs, it detected configuration changes as a "timing issue", which it probably wasn't since the crash happens even after waiting for some time. Any further questions had a localised response.
With limited context (one or two crash reports), we'll not be solving the root cause and end up with different solutions every time we try to solve for a crash report. Opening this issue so that we discuss and come up with a standardised approach (with or without an LLM).
How do you know that this problem exists today? Why is this important?
Recent crash reports and how they were fixed.
Who will benefit from it?
Maintainers and the open source community which take a reference of our code.
Anything else you would like to add?
No response
Pinning this issue so that contributors don't end up putting effort into solving any configuration change related issues without a plan. Tagging fellow maintainers and collaborators with write access to ensure we don't merge PRs without discussing why a specific approach has been used: @nicolas-raoul @rohit9625 @misaochan.
Hi @RitikaPahwa4444 ,
I’ve read through the issue description and the context around recent configuration-change related crashes. I understand that the goal here is not to fix individual crashes, but to agree on a standard, maintainable approach for handling configuration changes across the app (instead of adding configChanges or defensive null checks case-by-case).
I’d like to start exploring this issue by first understanding the current patterns used in the codebase. As a first step, would it make sense to:
- identify a small, representative flow (e.g. uploads / explore / login), and
- review how state is currently handled across configuration changes there, before discussing a broader guideline?
Please let me know if there’s a preferred starting area or any existing decisions/docs I should be aware of before diving in. Happy to take this step-by-step and align with the team’s expectations.
Thanks for your interest, @CodeWithSangeeta. Appreciate your enthusiasm! However, we recommend fixing a least 5 bugs before picking up any features: Context: https://github.com/commons-app/commons-app-documentation/blob/master/android/Volunteers-welcome!.md#developers
You can observe in the PRs where this issue has been mentioned - we haven't reached a consensus yet on the approach. Please feel free to pick this up once you gain experience with our critical flows by giving a few bugs a try :)
Thanks for the guidance and the context, @RitikaPahwa4444.
That makes sense — I’ll focus on picking up a few bug fixes first to get familiar with the codebase and critical flows, and follow the recommended contributor path.
I’ll keep an eye on this issue and the related PRs to understand the discussion as it evolves. Thanks again!