-
User Story
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
Why?
Cause - i.e why is it needed?
- Example use case: Device changes orientation (or other configurations) and the Activity is recreated and Qt "stays running"
Customer - i.e. who needs it?
- ?
- Technically huge impact also to Q4A not just QQ4A
Cruft - .e. why it is not needed (counter arguments)?
- ?
What?
Definition i.e what is it?
- If the device changes orientation (or other configurations) and the Activity is recreated, while Qt stays running, the Activity/Context Qt holds reference to will change, and the user might be holding a reference to it, but there is no way (in Qt API) to let them know it has happened
- The Activity/Context is used in a lot of Qt API internals to initialize things, register BroadcastReceivers etc, as well as exposed through QNativeInterface::QAndroidApplication. If we want to make sure everything gets cleaned up properly and nothing is left holding a reference to the destroyed Activity, we should have a way of letting all these places know that the Activity has been destroyed, and a new one created.
- Split it to API and underneath fix could go to older/pick versions
Demarcation - i.e. it is not?
Dependencies - i.e. it needs?
- Previous work
QTBUG-123711Should go all where the patch fix introducing this went
How?
Effort - i.e how easy or hard does it feel?
Estimate - i.e. how big is the amount of work (in calendar time)?
Essential - i.e the add on value it brings? High
When?
Flex i.e. time-bound (like platform or feature freeze) or not is it?
- New API, so bound to FF (Qt 6.11 in early December)
Force i.e. labor (do we have enough people working on it) capacity?
Fit i.e. does it fit in (like Qt release)?
- Qt 6.11?
- resulted from
-
QTBUG-123711 QtQuickView doesn't handle recreation of Activity properly
-
- Closed
-