Add blocks to the initial startup splash screen

[eoinparkinson]

I’ve created many apps with login screens. For each of these apps I must add a loading screen so when a user who is already signed in they must watch the splash screen and then another loading screen before being navigated to the home screen.

It would be great if we could add blocks to the splash screen. I don’t know the correct terminology or name for something like this but apps such as Spotify, Snapchat, Instagram and many many other apps only have one loading screen which is also the splash screen.

The ability to be able to add blocks would be fantastic, even if it was very limited to just sign in blocks for firebase authentication and other database, logic & math blocks. (Basically the blocks that don’t adjust visual properties).

Designing the actual splash screen has already been requested but maybe something like this could interlock with that?

Definitely not a high priority feature but would love to see this introduced further down the pipeline!

[MrMazzone]

I can understand the need for what @eoinparkinson is describing.

Can someone on the Thunkable team (maybe @josmas or @mark-friedman) describe the Thunkable app lifecycle? Especially as it relates to these two events, specifically on the first screen.

Do either of these two event run prior to visuals loading? I assume Starts runs once when the screen first opens and Opens runs every time the screen is navigated to and opened. If not, it would be useful to attach code the the splash screen load.

[easaw]

What I've done is if you happen to have a white icon, nothing shows on the spalsh then straight to a normal screen which you can do what you want with.

Of course this is only useful if you have a white icon, but in my experience the second or so that shows the splash is an acceptable segway to the first screen.

I think there also be some more important issues than this, that the Thunk staff will get to first, such as the Variables and other functional bugs mentioned recently. So you may be waiting a while to see a result on this...

[eoinparkinson]

Yes of course not a priority as I mentioned above. To make it even lower priority the workaround is just to add a loading screen :) Would love to see this nonetheless somewhere down the line.

[josmas]

Hi all, with regards to changes in the Splash screen, I guess that one of the suggestions in https://github.com/thunkable/thunkable-issues/issues/175, the ability to disable it completely, could fix this particular case. We've talked about it at one of our design meetings and we need to come up with a UI to do all this. It seems like the Splash could just be another Screen on your app, but this clashes with how the Companion currently works, so we need to think about it properly and come up with a sound design.

With regards to Opens and Starts, @MrMazzone your intuition is correct. Starts only happens once while Opens runs every time the screen gains focus. But these abstractions are rather tricky. We want to make them as simple as possible, but first of all, they are controlled by the framework, so we cannot run them at will, and second, we have no control over how they run. Rendering of the initial screen elements happens before the blocks inside Opens are run, but that same operation may (or may not) trigger changes in the elements, so Starts may get called immediately after (several times actually). They do not overlap, but unless you have a lot of blocks, they will run so fast that it might look like they are running at the same time. We had a conversation recently that illustrates what it was thought as a loop running twice here. My recommendation, as stated on that other post is to handle these blocks with care and use, whenever possible, idempotent code (code that can run multiple times without affecting the output). Anything in those two blocks that have a side effect such as changing the value of a variable based on a previous value (the case of the misterious twice-running-loop) will have undesired and difficult to spot consequences.

This is not ideal by any means, but abstractions tend to break at a certain point. It is also something that developers struggle with, even when working directly with a particular platform like Android. We are always looking for ways to make things easier and clearer, but these problems are far from trivial. Hope that makes a bit of sense!