Storing and saving a setting in a stand alone

Kay C Lan lan.kc.macmail at gmail.com
Thu Jan 15 19:21:42 EST 2015


On Fri, Jan 16, 2015 at 3:57 AM, Richard Gaskin <ambassador at fourthworld.com>
wrote:

>
> Why do you suppose this has survived so long with no one discovering it
> until now?
>

Whilst I may be a Mac fanboy, I'm definitely anti-iOSing of OS X. That
said, one of the few side effects may be the herding of LCers to store User
data in the correct place.

For me, a splash stack was simple. It was popular, there were several
online* and many LIst archive posts on how to achieve it. That's what I
did. With iOS that was not approved so you had to look else where. So the
beauty of LC is supposedly you can use one set of code for OS X and iOS so
it seemed silly to me to use one approach to store data on OS X and a
completely different one for iOS. So I looked at specialFolderPath() and
it's all clearly spelled out there where you should store User data. That
was a long time ago. Having gone down that route I now find that I HAVEN'T
been bitten by the change in OS X signing policy.

Having said that, the solution is still not one code for all platforms.
It's specialFolderPath("library") for iOS, specialFolderPath("Preferences")
or specialFolderPath("Support") for OS X, specialFolderPath("Support") Win
and not really sure for Linux... specialFolderPath("Desktop")?. At least
it's nice that for non-Preference type data, for documents that your User
makes with your app,  can all be sent to specialFolderPath("documents"),
except Linux.

Just had a thought, wouldn't it be nice if there was a specialFolderPath("
PrefData") which the engine naturally translated to "library" for iOS,
"support" for OS X & Win, "documents" for android, and whatever for Linux.
This should mean one code for all platforms for most basic apps and if
anything more complex was needed then you're back to where we are now;
writing different code for each platform.

* It would probably be wise for RunRev to remove any mention of the Splash
Stack method on their how-to site as it is clearly not an approach that
should be used any more.



More information about the use-livecode mailing list