LiveCode Forums.

I'm organizing my library stacks for what will be a large, evolving project. I'm new to livecode, but have had lots of experience with other authoring software and am keenly aware that I may make organization decisions that prove to be cumbersome later.

I've pondered two ways of organizing my project, and wonder whether one of them might get me in trouble later. I want to build a project that can easily transform into an iPad app. I'm including the sub projects (Data exploration, drawing tool, writing tool) as substacks that use the various libraries.

The one I'm trying now is to have my library stacks as separate mainstacks. This has the advantage that they are external and can be used on other projects. If one of my sub projects requires a library, it loads it and when it quits, it destroys libraries that are only used by it. In fact, if my sub projects get large, perhaps they may become separate mainstacks.

The other strategy is to put all library stacks as substacks. This ties them to the main project and they are loaded automatically when the project loads. The overall project seems simpler and I can always extract the substack libraries for use in other projects.

Is there a memory consequence to either approach? It seems that putting everything in substacks is simpler, but the substacks may always reside in memory, which could be an issue for mobile apps.

Is there any other "gotcha" That I haven't thought about?

Separate mainstacks have the advantage that, apart from the stack that the OS sees as "your app" when it launches, they can store permanent changes. This means you could update your libraries and apps that use them without requiring your user to reinstall the entire app. You could even do live updating where the app remains open and the old library stack is removed from memory and the new one opened. You do have to take care of keeping track of where the stack files are located on the file system and how to open them, though. If you have one stack with substacks, you can't update the libraries that are substacks without reinstalling the entire app.

Substacks can be "exported" as new mainstacks and mainstacks can likewise be incorporated as substacks into existing stacks (see set the substacks property in the dictionary) so you can use either as a development model without it determining your final app's structure. In other words, if you have a substack that you decide has potential use as a library in other projects, you can export it as a mainstack. You have some flexibility!

Thanks, I hadn't thought of the updating issue. In my Director application, I launched an updater app to download updates to my main app, so it was completely separate.

Is there the same advantage to having parts of my main project in separate files? I think of a main window that loads apps and deletes them when the user closes them. That would have the same update advantages, as well as possible memory useage advantages when I make an IOS version???

This is commonly referred to as the "splash stack" method, where the standalone app being launched is a very simple stack which then opens the stack that has all the running code. Doing this lets you keep the number of "extra" stack files - and paths - you need to keep track of at one while still allowing you to make and save permanent changes. It is a very popular model. I don't know how this works on iOS. Perhaps ask about using splash stacks in the iOS forum or on the use-list
http://lists.runrev.com/mailman/listinfo/use-livecode

Apple might have some rules that affect, in particular, using this for in app updates. But, it's outside my experience.

Apple tightly controls what gets downloaded to an iOS device, so I don't think the auto-updating will work. All updates must go through the App Store.

When calculating memory usage, any stack that is open or in use will be in memory whether the stack is a substack or a separate mainstack. If all the libraries are being used, the memory footprint will be the same with either method. However, if you only use some libraries some of the time, then keeping them in separate files will reduce memory because not all of them will be open. All substacks are always loaded into RAM when the mainstack opens, so if you use substacks they will all take up memory.

That said, most library stacks aren't too big, so the difference usually doesn't matter much unless you're talking a whole lot of them.

Thank you for the info. It has been very helpful and I can go forward with confidence that I won't hit any blind alleys. The more I get into livecode, the more impressed I am with not only the scope of what's built in, but the documents, tutorials, and user community.
Cheers!