I use both, in the backend it is just declared as a QSettings in private
variables.
QSettings settings;
And it can access or set settings set or used by the qml part.
Philippe.
Le 31-08-2018 14:38, René Hansen a écrit :
> I guess you have a QSettings instance instead of using the QML Settings
> component then?
>
> /René
>
> On Fri, 31 Aug 2018 at 14:35 maitai <mai...@virtual-winds.org> wrote:
>
> Hi,
>
> Here I have a slot in my backend (c++) that is called each time the app goes
> to background (from override onPause() in java). I do sync() there.
>
> Philippe.
>
> Le 31-08-2018 13:26, René Hansen a écrit :
>
> 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 [1] 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
Links:
------
[1] http://doc.qt.io/qt-5/qsettings.html#sync_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
