iOS AppData directory changes with each build: where to save files?

[Urthas]

Hello,

I have written a Qt application that targets Android and iOS. Users can download content of interest from a remote server through the app. Content is saved to QStandardPaths::writableLocation(QStandardPaths:: AppDataLocation). The corresponding local URLs are saved to a database, from which models are derived for display in QML views, etc. This works great. The problem is that when I push an update, the URLs in the database no longer "work". For example:

AppDataLocation for BundleVersion 6: /var/mobile/Containers/Data/Application/0EA7343F-5483-4D11-A3C7-0BCC088E57B4/Library/Application Support/<organization>/<app>/
AppDataLocation for BundleVersion 7: /var/mobile/Containers/Data/Application/6912CF98-818C-4078-8BBB-FD52B77D74A3/Library/Application Support/<organization>/<app>/

After deploying version 7 -- or even a fresh build of version 6! -- to a device, the app is evidently unable to access previously downloaded files using the URLs in the database.

One possible solution, I suppose, is to save the files to a directory in QStandardPaths::writableLocation(QStandardPaths:: DownloadLocation). However, these files will not be cleaned up if the user deletes the app. Moreover, if the user renames or deletes the files for whatever reason, the app will not function properly without additional code that re-fetches any missing files etc. This is a headache, especially with the forthcoming iOS file browser in the Fall.

I would like to use AppDataLocation as it seems intended for precisely what I want to do. But, how do I get around the apparently incompatible sandbox from build to build?

Thank you very much for any insight.

[Urthas]

I suspect that the problem is saving the absolute URL of a downloaded file, rather than just the filename proper and dynamically generating the URL at runtime...? Will update with a solution (if I find one)!

[Urthas]

Alright, so, indeed, this problem was not a bug in code per se, but a misunderstanding on my part as to how the iOS app sandbox works. I feel a bit silly, but, lesson learned and maybe this will help someone in future.

The lesson is: don't persist an absolute device URL that is based on the value returned by QStandardPaths::writableLocation(QStandardPaths:: AppDataLocation). Instead, store the filename (including extension) and stitch together the absolute URL at runtime. For example:

// main.cpp
MyApp app;
QQmlApplicationEngine engine;
QQmlContext *rootContext = engine.rootContext();
rootContext->setContextProperty("app", &app);

// main.cpp
MyApp app;
QQmlApplicationEngine engine;
QQmlContext *rootContext = engine.rootContext();
rootContext->setContextProperty("app", &app);

To copy to clipboard, switch view to plain text mode 

// myapp.h
Q_PROPERTY(QString dataLocation READ dataLocation CONSTANT)

// myapp.h
Q_PROPERTY(QString dataLocation READ dataLocation CONSTANT)

To copy to clipboard, switch view to plain text mode 

// MyView.qml
property var model: ...
property int currentIndex: ...
readonly property url localUrl: "file://" + app.dataLocation + "/" + model.get(currentIndex, <url role>) // <-- gets absolute URL using AppDataLocation and the filename stored in the data layer, at runtime

// MyView.qml
property var model: ...
property int currentIndex: ...
readonly property url localUrl: "file://" + app.dataLocation + "/" + model.get(currentIndex, <url role>) // <-- gets absolute URL using AppDataLocation and the filename stored in the data layer, at runtime

To copy to clipboard, switch view to plain text mode