Here’s a demo app that you can use to refactor your apps and make your projects much more efficient.
One thing that new Thunkers will often do is create too many screens in their app with the knock on effect of making everything much more time consuming to edit and update.
This is a simplified version of Darren’s great tutorial:
2 Methods to Reduce the Number of Screens in a Thunkable X App (with video)
What we’re going to build
This sample app is (in theory) an A - Z of blocks and components that are available in Thunkable X. It tells you about a component and can also read the information back to you with the help of the Text-to-Speech component.
To keep it really simple, I’ve only done the first 6 letters, but I’m sure you can imagine what the next 20 would look like!
What NOT to do
The thing we see most often is where users think “If I have 26 components I want to talk about then I will need 26 different screens” and they end up with something like this:
Please don’t do this - it’s a waste of time building something this way and it’s also really time consuming to edit and update. As you can see, this is such a waste of time, I gave up after 3 letters!!
In the next section we will look at a better way to build this.
Components Used
Rather than 26 screens for 26 different letters, we just need 1 screen to show all the letters.
To make it easier to navigate, I’ve added a SplashScreen and a MenuScreen
Splash Screen
The splash screen is really simple, it’s just a blank screen! 
When the screen opens, there’s a short pause and the MenuScreen is opened.
Menu Screen
The Menu Screen is only slightly more complex - it contains just a ListViewer with a Label at the top of the Screen:
When the menu screen opens we create a list of letters, and display those letters on the screen:
When the user clicks on a letter we keep track of what letter is pressed and its position in the list/alphabet by creating variables called clickedLetter and letterIndex. Once this is done, we open the ComponentScreen
Component Screen
This is where a little bit of planning will save us a huge amount of design time in our project.
Instead of creating one screen per item, or one screen per letter we are going to reduce this down to just creating one screen in total!
This makes it much easier to update and improve as we move forward. The screen itself should hopefully be fairly self-explanatory from the screenshot above, but here’s the component tree so you can take a closer look:
In my original design I had 3 labels, but while I was testing this I decided I wanted to have it so that the user could click on a link to the docs. If you look closely you’ll notice the LinkLabel is actually a button, while the other two are labels.
You can store you data anywhere you want (localDB or Spreadsheet would be good alternatives here actually) but just for the sake of clarity, on the ComponentScreen we have two lists. One for the components/blocks and one for the links to the docs.
When the screen opens, we update the labels on the screen:
and forward and backward navigation is now easily achievable by incrementing the letterIndex variable and calling the updateScreen function:
The link “label” (which is actually a button!) can open a page in the docs with just these 4 blocks:
And finally, just for fun, the app can read aloud what’s on the screen by passing the on-screen text to the Text_to_Speech1 component:
Remix Link
I really hope this will help you make more efficient apps and that you will become a more efficient developer by using these techniques in your own projects. If you want to take a closer look at my project, here’s the remix link.
