App structure help request

[tomcam]

LiveCode noob, experienced programmer here. I'm working on a pretty straightforward app targeting phones & tablets. There are multiple pages of icons. Click an icon and a sound file plays. You can drag and drop icons to reorder them, and move them to different pages. Eventually you'll be able to import your own graphic via file dialog or drag/drop, or use the system camera to take a picture, and record your own sound file for it. There are potentially thousands of such icon/soundfile pairs. It will come loaded with with many of them, and I suspect typically there will probably be only a few dozen user-supplied ones (though I plan to support the atypical case of many more than that).

Because there are so many icons possible, I assume the best architecture would be to use referenced controls, since mobile devices often have sharply limited memory?

If that's the case, how are the stock icon/soundfile pairs loaded? Would it be as a standard stack or is there some kind of dynamic allocation of controls required from the start? In other words, if the app starts with a couple thousand icon/sound file pairs, I know only the first page will be loaded assuming they're referenced controls. The number of items per page will be variable depending on screen resolution, user preferences, and so on. But I'm not sure what the best architecture is to load that page and future ones.

Thank you.

[Mark]

Hi,

In LiveCode, we rarely use words like architecture and load. Also, a LiveCode window isn't referred to as a page but as a card.

Just make your card with buttons and put a play command into each button. The play command can work with files on disk.

If you want to avoid load time, you might want to use a player control and set its filename to the path to a file on disk. Set its awaysBuffer to true and use a button to control the player.

Kind regards,

Mark

[jacque]

I don't have a problem with "architecture" or "load",they're fairly generic. "Card" however is the correct term of a screenful of data.

If you plan to create a standalone application, then it's important to know that apps can't modify themselves. All customizations will need to be stored as file(s) on disk, and loaded when the app opens. There are two usual approaches to that. The first is to create a bare-bones, one-card application (often a splash screen) that does nothing but open the main stack. Since the stack is not an application but rather a document file, it can be modified and saved.

The second approach is to create a template card in your app that loads data on demand. You can either fake a "go next card" command by locking the screen, reloading all the buttons/icons with new content, and then showing the card again, or you can create new cards as needed, which will be temporary because the app won't be able to save them for next launch. In either case, you're right that using referenced images and sounds are the only way to go.

Images can have scripts, so it isn't strictly necessary to use buttons unless you want a text label, which you could fake with a field, but a button is generally easier in this case. Whichever you choose, the script can play the associated sound file by creating a hidden player object, setting its filename, and starting it up. You can decide whether to re-use the same player object for each sound or just delete it and make a new one each time. I usually re-use the same one, mostly because I can create, hide, and save it during development and not worry about it again. It's always there.

If you need more info, ask away, that's why we're here.

[Mark]

Are you suggesting I have a problem with those words, Jacque? I just said we rarely use them, which is true. If we use the word architecture, it is mostly related to XCode.

Mark

[jacque]

Are you suggesting I have a problem with those words, Jacque?

No.

[Mark]

Very well. Thank you.