[Interest] QML Settings fails persistance on Android

[maitai]

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 <maitai at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
 

Links:
------
[1] http://doc.qt.io/qt-5/qsettings.html#sync
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180831/fcad53ef/attachment.html>