Tag Changes are lost when switching apps

[HolgerJeromin]

Vespucci Version

Vespucci 20.0.2 Flavor: current Target SDK: 33

Download source

Play store

Device (Manufacturer and Model)

Motorola g73

Android Version

Android 13 Android 14

Behaviour/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

https://github.com/MarcusWolschon/osmeditor4android/assets/2410353/6ee47db0-22e6-40b2-aad3-9f7569181ef2

[simonpoole]

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

[HolgerJeromin]

However if you simply leave the app and return you should still be in the property editor (in the same state as previously).

You are right. Saving would be wrong.

This is the case if you simply select the paused instance from the recent apps.

Yes. Just tested it.

[simonpoole]

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.

[HolgerJeromin]

Sorry, my phone was updated to android 14.

[simonpoole]

Pro memoria https://stackoverflow.com/questions/19545889/app-restarts-rather-than-resumes (as normal 90% of the answers are clearly wrong).

[simonpoole]

@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.

[HolgerJeromin]

set "property editor in a separate window" active:

• select object
• tap edit button
• split mode starts
• change some stuff
• (unrelated: reselect objects in map results in "data loss")
• push home screen
• open app via home screen icon
• property editor is opened in classic full screen view (with changed data!) and usable
• closing editor gives map back

[simonpoole]

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.

[HolgerJeromin]

Vespucci 20.1 BETA 3 did NOT fixed this on my device.

[simonpoole]

Did you change the preference?

[HolgerJeromin]

Nope. 🫣 Now it works. Sorry for the noise.

[simonpoole]

Feedback on how well/not well it works is welcome.

[jajajaneeneenee]

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.)