hm, I don't have this experience, maybe last time you checked in an old android device or something ?
Imagine if every time you resized a window on your PC, the window got killed and restarted, and you see why bugs like that arise.
It'd be one thing if it was when the app is backgrounded, but no, even if you have one app running on your entire device, the UI be torn down.
It's insanity that in 2022 a major operating system is still doing that, and yet here we are with no end in sight.
But you know what? Maybe instead we should discourage people from clumsily trying to push their pet agenda the moment their favorite sports team (erm excuse me, Operating System) is painted in a poor light.
But we can't all get what we want can we?
This is something you learn very quickly once you start building Android applications -- or, at least, I did when I started back in 2011 (I haven't done much Android dev in the past decade since then). While I do think this behavior is a pretty terrible default behavior for the underlying UI framework, it's pretty bad that the AndFTP developers have not fixed this bug in their application -- and yes, it is a bug in their application.
The UI development paradigm has changed quite a bit over the life of Android, making "Fragments" more popular to use in some quarters than "Activities" as the "unit of UI screen" (though Fragments are still underpinned by Activities), but I believe the fundamental issue is still there: if you don't explicitly handle rotation properly, and store state in your Activity, it will get destroyed whenever the screen is rotated.
Android will kill the user-facing portion of the process ("Activity") and recreate it* if you rotate the screen.
Devices have gotten fast enough to hide it with an animation, but it's still "kill UI, draw new UI". (specifically it's usually "render the UI to an image, squish it and rotate it, then show the new UI underneath".
My problem isn't with the literal animation, it's what that mess of rebuilding the entire user facing UI because they rotated their screen represents.
(* apps can opt out of this, but that's reserved for games and apps that render their own custom UI directly to a raw surface)
But this is like ground-truth stuff about Android, about as immutable as it gets: https://developer.android.com/guide/topics/resources/runtime...
The best time to fix it was before the G1 launched and the 2nd best would have been right after, but here we are more than a decade later paying for its sins.
12 years ago people were asking for this stuff: https://www.reddit.com/r/Android/comments/djp18/i_know_its_s...
At this point I think I qualify as a career Android developer (did other stuff but just a lot of time on Android) and my joking reply to anyone who asks why I use an iPhone is:
> I'll switch back when Android can handle a screen rotation without blanking the screen.
The thing is, the fact there's no smooth rotation isn't literally a blocker, but it's what such a subtle thing represents: Android apps are still living with the complexity of a situation that showed up because of the limitations of the 256 MB of RAM the Android G1 had in 2008.
-
They're still doing this messy state restoration stuff where the OS essentially has to kill part of your app to support a basic rotation, they never went back and fixed it as phones matured, bad configuration change handling easily causes hundreds of thousands of crashes a day for end users, constantly throws a wrench in development that Google has had to invent many different catcher's mitts for, drains resources that would be better used on improving the user-facing functionality of these apps.
And this isn't the only feature like that. There are so many basic sharp edges of the OS UX-wise that will just seemingly never get fixed, and even if were fixed tomorrow, it'd be at least 6 years before those improvements represented even 90% of the Android userbase (something iOS tends to achieve within 12 months...)
[and before the nitpickers show up, yes you can override configuration changes and manage that for your own app... no it doesn't scale for any "normal" app]