Cards versus Stacks

[goldbasilisk]

A newcomers question. If I want a main window with a variety of dialogs that come up from time to time, it seems that I could take two approaches:
(a) one stack with lots of cards
(b) lots of stacks with one card each
Which would be the best approach, and why?

[Mark]

Hi,

Normally, you'd make one stack with one card for each task, the same way you'd do in other development environments. Sometimes, you might want to make a wizard-like window, for which you might use one or more groups and multiple cards. This makes it easier to step through a process while making small changes to the interface with each step.

It might be tempting to create one stack with many cards if you're going to make a database, but there are better, faster ways to do this, e.g. keeping the data in custom properties or SQLite.

Kind regards,

Mark

[goldbasilisk]

Thanks Mark

I assume you meant (one stack with one card) (for each task) and not (one stack) (with one card for each task).

Basilisk

[Mark]

Hi,

You got it right.

Kind regards,

Mark

[townsend]

Interesting-- I was thinking of doing one stack, with many cards.

What would be the downside to this strategy?
What's the advantage to many stacks, each with one card?

[Mark]

Hello,

What do you intend to make?

Mark

[townsend]

Hey Mark-- A large application, with a splash screen and many different views of a remote PostgreSQL database.

Different DataGrids would be used for each view. I was thinking that I could save all the views and their data in one operation, if I used one stack and many cards.

This is assuming that iOS will allow me to save my sub-stack in the specialFolderPath("documents") folder.

Eventually, I'm thinking to save bandwidth, only new entries from the remote DB will need to be added to the DataGrid views.

[Mark]

Hi,

For iOS, you probably will want to make on stack with a number of cards. It just doesn't make sense to have an interface consisting of multiple stacks on iOS.

Don't use multiple cards to manage your data. It'll be slow. Instead, use one card to show different sets of data and keep the data in sqlite, text files or custom properties.

Kind regards,

Mark

[townsend]

Don't use multiple cards to manage your data. It'll be slow. Instead, use one card to show different sets of data and keep the data in sqlite, text files or custom properties.Mark

I appreciate the advice Mark! Knowing about bottlenecks before hand is a big time saver.
Otherwise-- I and others-- might have to go back and redo a lot of code.

Would I be right in my guess that the "slowness" you speak of would be from,
basically keeping all my data in memory (in DataGrids). Or is there something else,
that causes slowness, like DataGrid behavior, or maybe switching between complex cards,
that I'm yet unaware of. (Isn't keeping data in custom properties also keeping data in memory?)