For now I've reported QTBUG-70419
<https://bugreports.qt.io/browse/QTBUG-70419>, with my own suggestion for
the fix. It's been given P1.
/René
On Fri, 31 Aug 2018 at 18:09 Paolo Angelelli <paolo.angele...@qt.io> wrote:
> I also have had several issues (mostly persistence issues) with
> Qt.labs.settings.
> In the end using QSettings directly seemed to work alright, and so i kept
> using
> that.
>
> A pity since Qt.labs.settings looks much easier to use, but nevertheless..
>
> On Fri, 31 Aug 2018 13:26:05 +0200
> René Hansen <ren...@gmail.com> wrote:
>
> > Hi,
> >
> >
> > I've run into a number of weird cases where properties on a *Settings*
> > element doesn't properly persist between launches of an app.
> >
> > Initially I used aliasing quite heavily for it's syntactic ease, as per
> the
> > main example from the docs. However, I found that sometimes only part of
> > the the properties would properly persist for next launch. I could never
> > quite reproduce the issues consistently and it had a sort of
> > race-condition'y feel about it. So I gave up an aliases.
> >
> > Instead I've opted for a direct one-way load binding on launch and then a
> > write-back to the Settings when the app closes down. This seems to work
> > correctly regarding value persistence. That is, when it actually works...
> >
> > Here's the pickle; Android has two means of closing an application. One
> is,
> > that you can directly exit it via the back button, which triggers a Close
> > event on the main window, the other is by suspending the app and then
> > "clearing" it out from the list of background processes.
> >
> > The former produces a valid result, where properties are properly
> persisted
> > to the *Settings*, the other does not.
> >
> > I'm guessing this is because the actual write-back happens on the
> > destruction of the Settings element, which is, afaict, never triggered if
> > the app is cleared during suspension.
> >
> > I've made a futile attempt at manually triggering the write-back, at an
> > earlier stage of the shutdown, by connecting the the *application.state*,
> > e.g.:
> >
> > * Connections {*
> > * target: Qt.application*
> > * onStateChanged: {*
> > * switch(Qt.application.state) {*
> > * case Qt.ApplicationActive:*
> > * console.log("Qt.ApplicationActive")*
> > * break;*
> > * case Qt.ApplicationInactive:*
> > * console.log("Qt.ApplicationInactive")*
> > * break;*
> > * case Qt.ApplicationSuspended:*
> > * console.log("Qt.ApplicationSuspended")*
> >
> > * // WRITE STUFF TO SETTINGS HERE*
> >
> > * break;*
> > * case Qt.ApplicationHidden:*
> > * console.log("Qt.ApplicationHidden")*
> > * break;*
> > * }*
> > * }*
> > * }*
> >
> > However, even by doing it this way, "seemingly" before the app is
> > suspended, the values are still not written back at all. Presumably it's
> > because of missing destruction trigger mentioned above.
> >
> > So, what are my options here if I'd like to use *Settings* here?
> >
> > I notice QSettings have a sync
> > <http://doc.qt.io/qt-5/qsettings.html#sync> method,
> > but I don't see anything similar for the QML variant.
> >
> > What is the canonical way to solve this problem for Android? Has anyone
> > else done this in a practical manner?
> >
> >
> > Best regards,
> >
> > René Hansen
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
