Format rule condition vs. Show condition

I’ve been working on a prototype app that is designed to be used by a single user in prototype (free) mode. So, there’s only one user. Since there’s only one user per app, I can have a small table (only a few rows) of “options” from which the user can choose:

Screen Shot 2020-02-07 at 19.19.12

One of the options is “Word” size, that is, an option to change the display size of the vocabulary items in this flashcard app. The size that the user selects is stored in a small “options” table (just a few rows). A format rule to actually change the display size has the following condition:

LOOKUP(“Word1”, “Options”, “Key”, “Enum”)=“Bigger (1.5)”

I’m just looking up one cell in the table but the platform seems to think this approach is likely to be “expensive.”

Today it occurred to me that another approach might get rid of the warnings but I’m not sure if it would be more efficient.

I could make a few virtual columns to display the data in the [Word] column . . . perhaps [Word bigger] and [Word biggest]. I could then put the same LOOKUP() condition in the “show if” slot for each line. Next, I could make conditionless format rules for each virtual column. Finally, the detail view I use to display the information could have all three “Word” columns but only the column with the specified option would be shown because of the “show if” condition.

I’ve confirmed that this technique gets rid of the following sort of yellow warning:

Screen Shot 2020-02-07 at 19.41.55

However, what I don’t know is if I’m likely to be improving the efficiency of my app or even making it worse by implementing this strategy. Does anyone have any ideas?

1 Like

It’s a better approach because then you don’t need to calculate the format rule when you scroll more with the device… I should say… it’s already calculated.

3 Likes

Thanks! In that case, I’ll employ my virtual column strategy to get rid of all of these warnings. :slight_smile:

1 Like

You’re welcome

1 Like