For sure don’t try to write updates to Applications on macOS, that requires
permissions. Far better to treat them as app data and store in same place
preferences get stored.
Kee Nethery
> On Aug 3, 2018, at 5:29 PM, Peter Bogdanoff via use-livecode
> wrote:
>
> So, to store and access LC
On Android, "documents" is sandboxed with the app, so isn't accessible
unless the device is rooted.
On 8/3/18 8:59 PM, Brian Milby via use-livecode wrote:
Yes, specialFolderPath would be good to use. On a desktop, I'm not sure
that I'd want non-user facing data stored in the documents
Yes, specialFolderPath would be good to use. On a desktop, I'm not sure
that I'd want non-user facing data stored in the documents location unless
you configure it to be hidden. Windows and Mac both have "support" folders
defined. "library" would be the place on iOS. Android doesn't have one
Apple specifies that apps should store their app-related data in their own
folder inside Application Support, where you will always have permissions.
You can also store prefs in the Preferences folder but it's discouraged in
favor of App Support. LC has specialFolderPath("support") for that
With the increasing use of sandboxing on Operating Systems (i.e. very
limited access on iOS and Android that will eventually be included in
desktop OSes), I might suggest using specialFolderPath("documents") and
creating a directory structure in there, say of the form
// and whatever else you
/Library is going to have the same permission issue, but
/Users/username/Library... would be fine.
The down side is that the user can accidentally or intentionally mess with
stuff stored there more easily that something built into the app or stored
in the Applications/Program Files directories
So, to store and access LC stacks and other files used by myApp that must be
periodically updated, does it make sense to put them into
macOS—Library/Application Support/myApp
Win—user/AppData/myApp
rather than in Applications or Program Files?
Are there any restrictions or downside to this?
On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
> Hi,
>
> To raise the issue again of updating Mac and Windows apps, I’m referencing
> this thread between Graham and Jacqueline...
>
> Can existing files in the user’s application directory be
> saved/modified/replaced by my
Hi,
To raise the issue again of updating Mac and Windows apps, I’m referencing this
thread between Graham and Jacqueline...
Can existing files in the user’s application directory be
saved/modified/replaced by my application?
> On Mar 18, 2018, at 12:57 PM, J. Landman Gay via use-livecode
>
Thanks, Jacque, as usual your ideas are excellent. I’ll see what I can do to
follow your advice and report back.
As ever, it’s one of those deployment things that I would imagine affects
everyone who publishes an app that isn’t distributed via some app store, but it
doesn’t seem a popular
On 3/18/18 6:44 AM, Graham Samuel via use-livecode wrote:
Now, here is the primitive bit: if the user selects the update option, he/she
is invited to carry out the following sequence:
- quit the current version (actually this can of course be done automatically
via an “OK” button);
I'd
I’ve written before about trying to include within a desktop app a check for
updates, and a user-driven update action: I’ve looked a bit at Trevor’s
incorporation of such a scheme in Levure, and independently at Sparkle (only
for Macs), but I have never reached an encapsulated solution that
12 matches
Mail list logo
