|
Agree with you in both 1) Google being dogmatic and 2) you can do whatever you want.
Even when both are true I can't see a good reason to handle changes yourself, unless:
- You want to override its behaviour (ie: whatsapp disables the account on sim changes and requires reactivation)
- You're forced because of reasons (ie: KOReader handles input/rendering in a single thread where the LuaJIT VM runs. Receiving an onDestroy() call on the input handler efectively destroys the single instance activity)
Managing configuration changes yourself without adding any logic to handle it differently is like overriding a method to add a comment: useless. Specially if you let the framework to manage your activity lifecycle on other configuration changes. If it works well on orientation changes (the app is destroyed, recreated and rendered correctly with previous data without the user noticing a delay beyond the system animation) it should work the same way when you attach a bluetooth hid device.
Does the activity need a restart?. Probably not. Does the restart hurt your user experience? It shouldn't if the app is well made.
I saw quite a few apps whose onCreate method is a god function that covers 80% of the activity logic. In those cases handling changes yourself might hide the problem a little bit. But the proper solution would be lazy loading, not preventing that method from being called.
|