I want to add as many switches as the number of data

I am pulling data through Google tables. I would like to add this switch to the number of data. Thanks for the help.

This is very simple to do with the Any Component blocks in Thunkable X @zekidemirci

Can I clarify which platform you are using please?

App inventor

Ok, well I probably should have started by saying “Welcome to the Thunkable Community”, but here’s an example of using the Any Component blocks that I mentioned already that uses 5 UI components and just 32 blocks to create any amount of labels and switches you want…

All you need is 1 row with a label and a switch ( you can style them however you like) and a column below that:


Once you get all that data from the Spreadsheet component this first loop creates a new row in your app for each row that exists in your spreadsheet. If you add more data to your spreadsheet then more rows will automatically be created in your app. There’s no need to ever change these blocks.

This second loop updates all the switch labels with text from your spreadsheet. Again, this is a case of “set it and forget it” as you will never need to add any more blocks for this.

@zekidemirci if you click the link below it will copy my project directly into your account:

NOTE: you will need to add your own spreadsheet details.

1 Like

Thank you. My questions can be a bit simple. Excuse me. I couldn’t see a block in the form of “from label” on the app inventor.

Well App Inventor and Thunkable X are completely different platforms, run by completely separate organisations.

Since you asked here in the Thunkable community I felt I’d give you an example of how easy it is to use Thunkable X to create an Android and iPhone app that does what you originally asked.

1 Like

This is why I always advise people to only ask on the forum of the builder they are using. Yet some users shoot me down claiming what works on one builder will always work on others because they are all built upon App Inventor.

The answer is a bit involving here, since as you can see, the Thunkable staff is apparently way more eager to push for the incompatible Thunkable X, even when the question is unquestionably (and properly) posted in the Classic forum.
The bottom line is that Thunkable wants to completely stop support for the Classic, and your best alternative for a development platform that is App Inventor compatible and offer support for Ad Mob is to go with Kodular/Appybuilder (since kodular and appybuilder have just merged).
For the record, next time someone asks you what platform you are using, reply “Classic”, that will prevent the sort of futile “ask at the forum of the builder you are using” answer that does not do you much good. And as far as App Inventor is concerned, there is nothing that works in App Inventor that DOES NOT work in Classic, but since the community in App Inventor is a lot smaller (for instance, I hardly ever go there anymore) the chances of getting an answer is indeed better here (and will eventually get better at Kodular/Appybuilder since we likely all going to be there eventually).

This long preamble to reassure you that I consider your question valid and worthy of an answer.

So, you want a variable number of switches as a function of how many data points you have.
The short answer is that you cannot in Classic (or App Inventor). X will allow that because it is object oriented components and the capability to duplicate those. The flip side is that not all the features present in App Inventor (and consequently Classic Thunkable) currently exist in X, and that any app develop in X pays a huge premium in terms of memory foot print, and likely speed of execution, not to mention limitations in the size of the final application and number of logic blocks. The only real advantage that X has is that it can target iOS, which is of not much use if you only want to target Android machines; but imposes limitations on everyone by “we decide everything” Apple.
(For what it is worth, the API 28 compiler of Classic is currently bugged down with a limit of 1/3 the size of what we could achieve with the API 26 compiler, and since Google now demands API 28, we are stuck waiting for a fix that is several months overdue).

So, you may appear to be stuck.
But programming is not about what cannot be done, but about how can one do what is needed.
Here, the issue is that you have a limited real estate area on your screen already; you cannot possibly envision hundreds of switches on your screen at the same time. So what you can do is define the maximum number of switches that you can realistically expect at the same time, and have the ones that would be redundant in the case you have less data simply be not shown (visible=false).
For instance, suppose that you want 15 switches and that you only have 11 entries, then you have switch_1 to switch_11 with visible=true, and switch_12 to _15 set to false.
You, of course, still need to have the “when switch_15.Click” block, but it would only be reachable if that switch is enabled and visible anyway. And if all the switches do the exact same thing only with different date, all those blocks only need to call a single procedure with the argument “data_line=1”, “data_line=2” etc. (it can even call “data-line = (2+ offset)” which will be perfect for what I am about to describe next).
Now, what would happen if one day you have more than 15 values?
Then you need to be a bit more clever still, and add logic that offset things. If you have 30 values, 1 to 15 correspond to the switches, while 16 to 30 would correspond to 1 to 15 with an OFFSET of 15, i.e. you have a scroll down button that adds 15 to the data index before associating it to the action of the switch (and a scroll up that will subtract 15 so that you can get back up). Multiple press of the scroll up/down would keep adding/subtracting 15 to the offset so that there is no specific limit to how many data point you have (limited evidently by the memory of your device, evidently…)

Is this strategy considered acceptable?