9.1.2014 23:27, Wim de Vries:
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!
Well, a TOH with barometer & a variometer application might be a nice
combo for glider pilots. :)
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
_______________________________________________
SailfishOS.org Devel mailing list
