Storing and saving a setting in a stand alone
scott at tactilemedia.com
Fri Jan 16 22:26:00 EST 2015
The following won’t address the issue of the RunRev article you cite needing to be updated, which clearly needs to happen. But it might help you to know that there are really two different issues being addressed here: saving stack data, and making an updatable stack. While the splash screen approach CAN be used for saving data, its real power is more about making updatable stacks.
If your goal is solely to save user data, you don’t need to use the splash screen method at all. You can write virtually any kind of data file (text, image, stack, etc) to a writable location, which, yes, can vary from platform to platform, but as mentioned in my earlier email, can be addressed using a common folder such as “Documents”. Your app then reads and writes its data files to that location.
The real benefit of the splash screen approach IMO is being able to make updatable stacks. As you know, an application cannot modify itself. The only update option with a standalone application is replace the entire standalone with an updated version. However, with LC you can create your application stack normally, leave it in stack format, and build a standalone whose sole purpose is to load your application stack. In this way it’s possible to treat your application stack as a data file that can be updated virtually at will without having to replace the standalone. This allows you to, for example, update the entire UI without building a new standalone Pretty neat stuff.
But with iOS, this capability is limited because Apple frowns on remote loading of binary files (executable code). Does this mean you can’t update apps using the splash screen method? In theory, yes (though I’ve been dying to try to get a mobile app published that does this). But it doesn’t mean you CAN’T update your app, it just means you have to utilize the channels Apple provides to do your updates.
As security and privacy concerns continue to grow, it shouldn’t be surprising that the viable locations for writing and saving files will become more restricted. This isn’t a LiveCode thing, this is an OS thing, and is something that RunRev has to jump through hoops to stay on top of.
Your suggestion for creating a table of what data/stack options are possible on what platforms is a good one. And my guess is whatever code you’ve created to handle data saving/updating can still work, but with some modifications.
Tactile Media, UX/UI Design
On Jan 16, 2015, at 5:57 PM, Kay C Lan <lan.kc.macmail at gmail.com> wrote:
> it's more likely I'm confused. You and Richard are the experts here so I
> tend to be wary if I'm going against the flow.
> The original post simply asked about Saving User preferences. Unfortunately
> there was no mention of OS, nor was there any mention that it used to
> 'working for ages up until I upgraded to....' So I'm not sure that it's
> related to the bug you mention but that may be an extra factor.
> From my perspective (NOT a full time programmer) I see the original post in
> the same light as: 'I have a 10,000+ line file I need to step through, I
> need to process each and every line, how do I do that." Although
> repeat with x = 1 to the number of lines in myDataFile
> is a valid and workable solution it is NOT the one that would be
> recommended by most LC experts. Repeat for each would be recommended. It
> has a known advantage.
> Prior to iOS, the Splash Screen approach was a very neat and tidy solution
> on all platforms, it still is on some platforms , BUT with the further
> iOSification of OS X it may be becoming an even less tidy solution. IMO
> (and I'm probably completely wrong) the recent in rush of interest in LC is
> a combination of the Community Edition, it's cross-platform abilities and
> the desire of people to build mobile Apps. For me (and it just might be me)
> I learn a LOT from online example. I plagiarise. I take the online example,
> see that it works then slowly modify it to suit my own particular needs. It
> really really frustrates me when I take an example, verbatim, and it
> doesn't work as advertised. IMO, it's even worse, and very counter
> productive to have an example that works perfectly, on desktop, work weeks
> or months adding features having it all work fine; then deploy to iOS and
> it fail.
> Here's one lesson:
> Although if the reader bothered to read all the Comments they'd see that it
> doesn't work on iOS.
> I must be going crazy because I'm sure when I was last on that site there
> were tags listed including 'splash' and 'splash stack' but I don't see them
> any more. You can simply search the site for 'splash'. My original comment
> about removing them was a little over the top, a clear banner note at the
> top stating that the method will not work on iOS would suffice - as long as
> there was a link to a How-To that did work on ALL platforms.
> As for the User Guide there is only one mention of the Splash Stack
> approach in a Note on page 299. As you imply, that one Note is rather
> pitiful for a topic that would be far better served by an entire section
> covering the multitude of options available, a nice matrix table of what
> works and doesn't work on various platforms with the reference to the
> sub-section that spells out how to achieve option B on platforms W,X,Y and
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode