While researching using the factory design pattern for fragment creation I couldn't help but notice how that fragment creation is a long term source of bugs. Why is fragment creation error prone?
Perhaps because the API for fragment has been changed so frequently that so much of the advice is dated. In the real world fragment is deprecated in favour of a decedent in the app support library but that has been deprecated as well in-favour of androidX support libraries.
Perhaps it is because many newcomers to Android are Java developers who follow the Java idiom of constructor overloading to pass parameters at creation for use in Activity.onCreate(). However, this is not a good idea it is an example of bug pattern. Using a constructor will usually appear to work fine until Android destroys the activity and looks for a default constructor. If there isn't one the app crashes with a
runtime exception. This is because behind the scenes the default constructor is called rather than the constructor provided. The issue is of course that the parameters you use to call the fragments are not known by Android framework.
If there is a default constructor a more subtle bug will will arise. When the fragment is recreated following a runtime or configuration change using the default constructor and without any of the parameters used previously. This is not going to work unless somehow the parameters are set before they are used. Once you try to get at them - you will get a null error exception. Using getters and setter may help and default values may help a little more but this is not really fixing the issue.
The default Android mechanism for saving and restoring state is of little use. It only covers states stored in controls. Anything more sophisticated requires attention from the programmer.
If the state has all been saved and restored to a bundle in onPause() and onRestore() respectively this is likely to still not enough.
When the constructor passes resource ids etc required earlier in the lifecycle before the bundle mechanism is run say in
onCreateView() or in
onCreate(). These fragment may still be crashworthy. Also at this point reproducing the bug may require a rather sophisticated set of scenarios as the bug is still around but harder and harder to reproduce.
I also noticed some mentions of an Android developer setting called "don't keep activities" but in adb it is a global flag which tells Android to call finish on activities once they lose focus. This has the consequence of simulating a configuration change. Once set activities are no longer kept in the task (top level activity container for fragments). This will ensure the fragment's default constructor will be called as if the device is a memory staved device with a brand new equivalent date of 2012. Using this setting we should crash faster and more consistently if the above bug were introduced into the app allowing fixing them.
I spent some time figuring how to control this setting via adb.
This raises another question is how to coordinate tests and adb commands.
Or better yet how to do the adb voodoo using junit rules.
I hope to cover these in future.
great
ReplyDelete