Thanks Thomas for the explanation.
Indeed, I think I will stick to a minimal persistent data set to enable
the user to play with.
For the open/free data I will have a look at SF.
The maps created by the user (with an accompanying desktop application)
will have to be copied to sailfish via USB to a dir in $XDG_DATA_HOME.
The good thing is that I am not in a hurry, don't expect many pilots
with a Jolla for now :-)
And, in the long term ... A pilot Other Half!
r
wim
On 01/09/2014 01:50 PM, Thomas Perl wrote:
Hi,
On 09 Jan 2014, at 09:05, Wim de Vries <wsvr...@xs4all.nl> wrote:
I am converting my aircraft navigation app to Sailfish.
It comes (default) with OpenStreet based maps + 3D data files of Western Europe
(in RPM).
Most users will use this map, but some users may use their home made maps
(generated by a PC application).
In the latter case, the users will delete this W-Europe map (it takes up quite
some disk space).
So far so good, but the installation/RPM is a problem:
Harbour says that I should install the app data (very much bytes for the W-Eu
map) in /usr/share/$NAME and in the first run of the app, copy them to
$XDG_CONFIG_HOME/$NAME.
But now I am stuck with an enormous amount of (useless) data in
/usr/share/$NAME that cannot be removed.
Any suggestions?
The “copy stuff to the home directory of the user” is only relevant if you want
to e.g. ship default config files and install them to the config directory on
first start (the suggestion was put in place when somebody wanted to install
files to /home/nemo/.config/ in the RPM file, something that will also lead to
unhappy people in case of package upgrades, and that was suggested as best
practice if the code can’t deal with missing config files - which it ideally
should ;)). For big files, obviously it doesn’t make sense to copy them to
$XDG_CONFIG_HOME/$NAME. Instead, what you could do is install them to
/usr/share/$NAME, and then just have a flag in $XDG_CONFIG_HOME/$NAME if the
user wants to disable the system-wide data (of course, this doesn’t free the
data, but in case hiding/not loading the data will improve e.g. the startup
time or user experience, it could still make sense).
For data that the package manager installs, only the package manager should
modify/remove the data. Making /usr/share/$NAME world-writable is not allowed
per harbour rules, and for good reason - if the user would e.g. delete the
pre-installed maps there, they would re-appear every time the app is upgraded,
or if the user modifies the data there (or the app), these changes would be
overwritten by a package upgrade.
Also, another thing: Having big pre-installed data in the app packaged (=inside
the RPM) is bad, as it will require this data to be re-downloaded every time
the package is installed, and (during installation time) will take up the space
for the - temporarily downloaded - RPM and the extracted data (you will need ~
400 MB free to extract a 200 MB RPM file with 200 MB of data inside, not taking
into account compression and stuff).
So, you have an app plus some big data that probably doesn’t change as often as
the code does (either it changes more often or it doesn’t change as often - the
data doesn’t usually have anything to do with code updates to your app except
if you happen to do some data format changes).
There are basically two options:
1. Don’t ship any data with your application
- Small download and upgrade size, no wasted space
- For the “pre-packaged” maps, you could download them in the app on first
start
2. Ship data with your application, and don’t let the user delete it
- No need to host any data packages
- Package upgrades and first download will be unnecessarily large
I’d suggest you do variant 1: Users who have a good connection might not
want/need to download much data upfront, they might just want to try out your
app (=easier when it’s a smaller download) and only after they’ve tried and
liked your app, they might go into the in-app menu and select something like
“download pre-packaged maps”. As your data seems to be open in some sense, you
might be able to either download it directly from the OSM servers, or you
package it up and put it up on some hosting service (e.g. sourceforge.net works
well for hosting such data downloads, including mirroring - but any other
service or your own web server would work just as well).
If you really do want to ship the data with your package, it should not be
possible to delete it, only possibly hide it from the UI of the application via
a setting that is stored in $XDG_CONFIG_HOME/$NAME. By the way, all the data
that you download should go into $XDG_DATA_HOME, not $XDG_CONFIG_HOME (as the
name suggests — this will allow backup and cleanup applications in the future
to e.g. backup / clean only the data directory (keeping the config in place) or
only deleting only the data). For data that you basically cache from a web
services, such as map tiles, $XDG_CACHE_HOME/$NAME might be an even better
place.
Of course, you could also create a separate “Map pack” app entry for each
pre-loaded packs that just contains the map data, although I’m not sure if we
currently accept such “non-app” items (without a .desktop file and icon).
For the future, if somebody wants to brainstorm it on together.jolla.com, we
could have separate “data packages” for each app on harbour that the store
client takes care of installing and updating independent of the app, which
would also result in better bandwidth usage (data is only downloaded when
updated, app package updates can be downloaded and installed independently). On
Google Play, this mechanism is called “APK Expansion Files”:
http://developer.android.com/google/play/expansion-files.html - something
similar to that could solve the problem in your case, but we’re not there yet.
HTH :)
Thomas
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
