rotating screen causes import / export to stop

[tfbb-bb]

hi there -

thank you for sms-ie - it seems to work as intended :) i just noted that rotating the screen breaks the import-/export process.

[tmo1]

Thanks for reporting this - I have confirmed the problem.

There are apparently a number of methods for dealing with this issue, of various complexity and robustness; for (my own) reference, see here, here, here, here, and here.

It would be nice to fix this, although I don't see it as a major problem, so I'm not going to make fixing it a priority, and I'll probably only fix it if I can work out how to do so without too much work.

[ericjs]

I don't know if this is related, but I find other things can kill an import process also, like switching to another app and coming back. Is this expected or related? With a big import I find myself almost afraid to do anything except periodically tap white space on the screen to keep the phone awake... (It does seem to survive the screen shutting off and locking...though I'm not sure it continues to run.)

[tmo1]

Probably related. As I've said above, it would be nice to fix this, but I haven't made it a priority. The import should continue to run even if the screen shuts off and locks, though

[kirk56k]

I had this issue with my own app as well. The fix is very easy and straightforward, you just need to set screenOrientation for each activity in your manifest to "portrait" and that will lock the orientation regardless of whether the phone has auto-rotation enabled.

<activity
    ~~~
    android:screenOrientation="portrait"
    ~~~ >
</activity>

[tmo1]

The fix is very easy and straightforward, you just need to set screenOrientation for each activity in your manifest to "portrait" and that will lock the orientation regardless of whether the phone has auto-rotation enabled.

Thank you! It looks like that setting screenOrientation would indeed fix the original reporter's problem of screen rotation terminating import / export operations, but not the other variations of the problem, such as switching to another app and returning, noted by @ericj (a point discussed here). Still, your suggestion is probably worth implementing since it's easy and will help for the common case of phone movement.

Looking around, I'm not sure what the ideal value for screenOrientation is in our case: you propose portrait, but perhaps sensorPortrait, nosensor, or locked would be preferable (see the official documentation, and the previously linked StackOverflow thread as well as this one). Do you have any thoughts on this?

Thanks again.

[kirk56k]

You're right about the other specified issues. For my application, I had to move some of my work to a persistent notification thread (one of the few things allowed to bypass androids sometimes overzealous unloading mechanism). Along with disabling battery optimization for the app, which requires user interaction to do. This also requires inter-activity and/or inter-thread communications in order for the work to communicate with the UI. Which is not entirely simple to implement (but not stupidly hard either). But then, all of my knowledge is based on Java Android, not Kotlin, so I don't know if things are any different in that arena. Most of the code I maintain is legacy (read: very old), so there may be better ways to do things in later versions of android I'm not aware of.

As for the orientation, I think "portrait" is most appropriate for your app, as your UI is most suitable to portrait use. "nosensor" or "locked" will allow the app to open in landscape or reverse portrait, it just won't change afterwords. And "sensorPortrait" allows the user to flip the device upside down, if the device configuration allows it, which could cause the problem we're trying to avoid.

[tmo1]

As for the orientation, I think "portrait" is most appropriate for your app, as your UI is most suitable to portrait use. "nosensor" or "locked" will allow the app to open in landscape or reverse portrait, it just won't change afterwords. And "sensorPortrait" allows the user to flip the device upside down, if the device configuration allows it, which could cause the problem we're trying to avoid.

I've decided to go with locked, at least for now, since although the UI is indeed designed for portrait orientation, it will work in landscape as well, and I don't want to take away the choice from the user. Thanks for the suggestions and advice!

I'm leaving this issue open, since although locking the orientation should solve the OP's problem, it won't help the case of leaving the app while an operation is running. Fixing that will probably require something along the lines of what you suggest above. I don't currently plan to implement such a solution, since it would require significant work for limited benefit, but I'll leave this issue open for further discussion.