[SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share
Wim de Vries
wsvries at xs4all.nl
Fri Jan 10 06:56:24 UTC 2014
On 01/09/2014 11:56 PM, Martin Kolman wrote:
> 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. :)
Could be possible, but my current sensor is to big.
>
>>
>> r
>> wim
>>
>> On 01/09/2014 01:50 PM, Thomas Perl wrote:
>>> Hi,
>>>
>>> On 09 Jan 2014, at 09:05, Wim de Vries <wsvries at 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
>
More information about the Devel
mailing list