Android-runtime: Simplify method to add a splash screen

[NathanaelA]

This is relating to issue #331 and #332 in several ways; but I would like to discuss the pros and cons of how to do this for the forsee able future.

I would like to see something like what iOS has currently where you can just drop a image into the App resources and it shows up as the app splash screen. I realize this is built into the iOS app; and Android doesn't have this built in. So we have to add it...

So I was thinking at bootup the app automatically loads the resource "splashScreen". By default we put in the project a transparent 1x1px splashScreen, this image is then overlayed on the screen before even the NS engine is initialized, so it is displayed as quickly as possible. Then when the NSActivity is actually launched we clear the activity and/or remove it from the screen.

I'm not sure if it would be better to have a separate Launch Activity that displays the screen or if we can use a api to just draw it to the screen without using a different activity, thoughts?

Pros & cons:

1. Simple for the masses, and follows basically what we are exposing on the iOS side.
2. Might add a fraction of a second to the startup time, but to the user seeing something asap will make it "feel" a lot faster.

Thoughts, and any guidelines for implementing, this might be something one of us in the community can implement?

[Plamen5kov]

Hi, @NathanaelA
First of all, it's a great idea to simplify the splash screen creation process, and it would be great if the user could just put a splashscreen.bmp somewhere and the splash screen works.
Let me share what I think:
There are two main ways I can think of:

• use splash screen activity of sorts

A couple of things I don't like are that it adds extra time (even if it's not much), and additional manipulation of activities.

• use the "android way" (themes)

I thought about the current way we do splash screen and then about, how is splash screen best implemented in android and found a couple of solutions including posting the main theme intent with some delay or with intervals, but it didn't seem very legit in the context of {N}, because the time for parsing the JS code can vary, depending on it's size . Then i found this article.
As you can see there isn't much difference, but I think we can make some default transparent picture as you suggested, but also the styles have to be in place and let us have default behavior.

One possible way would be to have default style in res/styles.xml that refers to a layer-list as described in the latter article. And from there we can leave the configuration of the picture to the user if necessary. That fixes the problem with the problem put the picture and splashscreen works, but then when the application starts, on activity on create we need to replace the "splashscreen theme".

There are three ways I can think of:

• As is described in the {N} article:

application.android.onActivityCreated = function(activity) {
            // apply the default theme once the Activity is created
            activity.setTheme(org.nativescript.applicationname.R.style.AppTheme);
        }

• In the tns_modules
• combination of both (tns_modules behavior that replaces the theme can be switched on or off)

By all means, these are not all possible or best solutions. We are open to any suggestions.

[NathanaelA]

Hmm, very interesting article. Excellent find @Plamen5kov -- that might be an excellent default solution. I like that the theme is not global, but tied to the single starting activity which is then replaced before it chains up to the super. That should be easily implementable and totally eliminates the existing issue with the error screen and using the global theme...

Here are my thoughts from that article; to KISS it for the masses (including me! :grinning:)
We could add the style, xml for the layer-list, and a 144dpi {N} logo in to the default project templates, and update the main activity .java file to automatically set the theme back to the default theme.

This should allow all the existing apps to work without the end users having to make any changes when they upgrade to 2.x (now they obviously won't get the splash screen until they add the missing files and update their manifest to use the splashtheme). And those who create a new project would automatically get the ability to just replace the "splashscreen.png" in the Xdpi folders and be done just like iOS.

What do you think? Any negatives that you can think of doing it this way?

[Plamen5kov]

I think the control for reverting back to the default app theme is better left to js code, rather than the template files, because it would be more accessible and understandable to the end user, but besides that, I'm thinking much of the same implementation.

[PanayotCankov]

@Plamen5kov :+1:
I too think we should add the theme based splash screen in the hello-world templates and the code that revers the theme in its app.js.

We should also add a "Launch Screen" storyboard for iOS using an image. It will work the same way as the android aproach.

This will be cross-platform, relatively easy for the developers to maintain, and is what we currently have in the nativescript-marketplace-demo. The only side-effect we have seen there so far is the error activity picks the splash screen theme.

[NathanaelA]

@Plamen5kov & @PanayotCankov -
I have also mixed thoughts about putting it in the app.js -- if the majority of the implementation is already hidden, and not touched by anyone; shouldn't the whole thing be out of the way. The objective is KISS. The vast majority of the user base is wanting this to be a no thought process. For those of us who are actually interested in how it does it; I'm not sure that moving the theme restoration to the java layer (or the JS activity class) is going to make any difference. The restoration is just going to set the theme back to the app default theme, so this is code that a end user has no reason to change that I can think of, so not sure what the point of adding it to app.js would serve. However, what I think really matters is wouldn't the app.js file be too late in the process; my understanding from reading the article is that the code to set the theme default back needs to be set before super is called. I thought app.js is parsed and ran after the NS activity is created, which means the super is called already...

[petekanev]

@NathanaelA I have to agree that it should be as easy as possible to our users. They don't need to know that changing a theme solely for the purposes of a prettier splash screen will make that theme persist throughout their application unless explicitly reverted when their app pops up.

And even when that is not the case, writing boilerplate like setTheme( ) in app.js is somewhat unnecessary if they've already set their desired theme for their application in the AndroidManifest.

[Plamen5kov]

@Pip3r4o

• ...writing boilerplate like setTheme( ) in app.js is somewhat unnecessary if they've already set their desired theme for their application in the AndroidManifest.
• In the current suggested implementation the user will have declared in the AndroidManifest.xml the "splash screen" theme, instead of the default theme, so we will need to replace the "splash screen" theme at later time.

@NathanaelA

• ...so this is code that a end user has no reason to change that I can think of, so not sure what the point of adding it to app.js would serve.
• I also can't think of a user case right now, but I don't want to dismiss it as a possibility. In the future, if such a scenario appears and the user wants behavior, different from the default one, we will be able to easily provide it.

---

• ...what I think really matters is wouldn't the app.js file be too late in the process...
• I don't think it would be too late, because in app.js is the first jsvascript file called by the runtime.

---

• I thought app.js is parsed and ran after the NS activity is created...
• The app.js file is run after the NS application and before NS activity.

---

• ...what I think really matters is wouldn't the app.js file be too late in the process; my understanding from reading the article is that the code to set the theme default back needs to be set before super is called.
• If you read the articles again, you'll see that both reset the theme in the onCreate of the activity, not the application, so the callback should be executed in our favor.

[PanayotCankov]

Splash screens for android have already been implemented. They will ship with the next {N} version. You can find more information here: https://github.com/NativeScript/docs/blob/master/publishing/creating-launch-screens-android.md