-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag Changes are lost when switching apps #2575
Comments
You didn't actually save the tag changes so you shouldn't have the expectation that they have been applied to the data. However if you simply leave the app and return you should still be in the property editor (in the same state as previously). This is the case if you simply select the paused instance from the recent apps. I currently suspect that the issue is due to a change in startup behaviour aka the app being replaced instead of the paused instance being resumed when started from the launcher |
You are right. Saving would be wrong.
Yes. Just tested it. |
Unluckily I can't recreate the issue on an (bog standard) Android 13 emulator, but can on a Android 14 Samsung. That makes things difficult. The only positive thing is that I do get similar behaviour if I change the launch mode from what it is right now (standard) to singleTask or singleTop. Though that is only an indication that it is launch related. |
Sorry, my phone was updated to android 14. |
Pro memoria https://stackoverflow.com/questions/19545889/app-restarts-rather-than-resumes (as normal 90% of the answers are clearly wrong). |
@HolgerJeromin I fairly sure this is simply a launcher bug on some devices ... but interesting enough I can get things to wotk on the above mentioned samsung if I enable the experimental feature to start the property editor in a separate window. When you have time it would be interesting to know if that changes the behaviour for you too. |
set "property editor in a separate window" active:
|
This is a workaround issues with certain Android launchers that has been around since 2009. There is no particular reason why this should work except that it seems to do so. Resolves #2575
The interesting thing is that the launching the property editor with the "NEW TASK" flag set (which is implicit when launching in split window mode) works*, however doing that means we can't use the "classical" startActivityForResult way of starting the property editor, but as we already have all the bits and pieces in place (due to the multi-window support) to communicate back to the map display via intents, we can offer this as an option. * naturally as we don't know -why- the launchers don't resume the app properly there is no guarantee that this is more than a temporary fix. |
This is a workaround issues with certain Android launchers that has been around since 2009. There is no particular reason why this should work except that it seems to do so. Resolves #2575
This is a workaround issues with certain Android launchers that has been around since 2009. There is no particular reason why this should work except that it seems to do so. Resolves #2575
This is a workaround issues with certain Android launchers that has been around since 2009. There is no particular reason why this should work except that it seems to do so. Resolves #2575
Vespucci 20.1 BETA 3 did NOT fixed this on my device. |
Did you change the preference? |
Nope. 🫣 |
Feedback on how well/not well it works is welcome. |
I can confirm this issue on a Samsung A33 with Android 14 (also had it under Android 13 since some time) and the new experimental setting seems to help (tested with 20.1.0 Beta3). Very good! (You could add the Samsung A33 to the list "Testing on selected devices" on http://vespucci.io/tutorials/faq/#resuming-the-app-doesnt-bring-me-back-to-the-property-editor.) |
Vespucci Version
Vespucci 20.0.2
Flavor: current
Target SDK: 33
Download source
Play store
Device (Manufacturer and Model)
Motorola g73
Android Version
Android 13Android 14Behaviour/Symptoms
Change tags of an element
Push home screen button
Reopen vespucci
Now we have map view with lost changes.
Expected Behaviour
Changed tags should survive
How to recreate
Crash dump submitted (no or yes + date)
Triggered a crash dump right now.
Not sure if successfully
screen cast
Removed phone
Added cuisine
Changed name
Home screen
screen-20240609-195001.mp4
The text was updated successfully, but these errors were encountered: