search

phikal / ReGeX

A Regular Expression game for Android
https://f-droid.org/en/packages/com.phikal.regex/
GNU General Public License v3.0
102 stars 10 forks source link

Scrollable view changes state on device rotation #35

Closed reverse-unina closed 7 years ago

reverse-unina commented 7 years ago

When I perform this sequence of events, the scroll view on screen goes back to the top

  1. In the first help dialog, scroll down
  2. Orientation Change
phikal commented 7 years ago

Which scroll view are you refering to? "Match" and "Don't match"?

reverse-unina commented 7 years ago

The scroll view inside the dialog that appears right after install

phikal commented 7 years ago

The one with "ReGeX /ˈrɛːɡɛx/ is an android game, with a simple objective: [...]"?

reverse-unina commented 7 years ago

Yes, it's him!

phikal commented 7 years ago

I'm afraid that's the native behaviour of a scroll view element, so there isn't much I can do about it. As far as I see, as soon as a scroll element looses focus, it goes back to the top, and element (I believe) always loose and regain focus when rotated.

One possible solution I could think of spontaneously would be to memorize the position and reset it every time the activity is reloaded.

But other than some slight visual pleasure in not having to scroll down a bit after rotating a device in an (more or less) irrelevant dialog, I don't think the code or the effort in writing/maintaining this would be worth it.

So, spontaneously I'd close this issue, but I'm just going to ask if you have some specific argument for having to fix this?

reverse-unina commented 7 years ago

I am exploring GUI failures for research purposes. As stated by Android guidelines after an orientation change, apps should preserve their state and functional parity. Thanks to your contribution, it is emerging that there are some limitations in the Android framework and high coding effort are required in certain situations (i.e. retain a scroll position)

phikal commented 7 years ago

Ah, ok, I'm glad that I could help.

But just regarding the

high coding effort are required

it's not that it's a lot of effort to write it per se, but rather when thinking about issues, like #31, that bugs appear over time related to such "manual fixes". The code would probably be 20-30 lines max., so I just wanted to mention that for your research.

So all in all, I'll consider this "fixed" for now, unless anyone protests.