Improved styling the landing screen

[grzesiek2010]

Closes #5733

Why is this the best possible solution? Were any other approaches considered?

This is what we have discussed in the issue and in this pr.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Testing the landing screen will be enough since nothing else has been touched. Changes that I have added:

• moved the logo
• refactored the text displayed at the bottom to add a demo project

Do we need any specific form for testing your changes? If so, please attach one.

No.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• added a comment above any new strings describing it for translators
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[grzesiek2010]

@alyblenkin please take a look and let me know what you think. Here as well the landscape mode looks worse than what we already have on master so it might require some tweaks.

[lognaturel]

Please make sure to also take a quick look at languages like French that have longer taglines! @alyblenkin, I see you did it in mockups but would be good to see how you feel about it on a real device.

[alyblenkin]

Here are a few screen grabs from the device below. I think it looks pretty good. The text seems to shift to be more centred with French for some reason. I also noticed the bottom text gets cut off in German.

[grzesiek2010]

I also noticed the bottom text gets cut off in German.

Even on master there wasn't enough space for such long translations and now that text is even bigger so it takes even more space. The problem is that those are two separate strings Don't you have a project yet and Try a demo Maybe we should refactore it and keep it as one string and then enable display in two lines if it's longer?

[alyblenkin]

Even on master there wasn't enough space for such long translations and now that text is even bigger so it takes even more space. The problem is that those are two separate strings Don't you have a project yet and Try a demo Maybe we should refactore it and keep it as one string and then enable display in two lines if it's longer?

Good to know. I think the text was very small before and challenging to read. I think it is worthwhile refactoring it so we can display it on two lines if it's not too much work.

[grzesiek2010]

I think it is worthwhile refactoring it so we can display it on two lines if it's not too much work.

Done.

[alyblenkin]

I think this is a great next iteration! Next time we redesign the landing screen we will likely have a new logo :)

[seadowg]

I've got one idea for an improvement we could make while we're here so will hold off on "needs testing" for now.

[seadowg]

#5772 (comment)

[seadowg]

Why make this nullable?

[grzesiek2010]

Because I don't want to throw false as the initial value. That would mess up what we have above in the activity class plus when it comes to the progress dialog it also does not need to receive that initial false value.
And one more thing in kotlin it's not nullable because the data type is Boolean not Boolean?

[seadowg]

Ah because you need to differentiate between "no longer loaded" and "hasn't loaded yet" for the observation that launches the Main Menu. It's strange because the LiveData is technically nullable (you could set it to null) due to some weirdness in the generic typing which was the whole reason to introduce the NonNull... implementations.

Here I guess this all works without a null check (again in the observation that launches the Main Menu) because _isLoading has no "initial" value. However, I think if you called getValue on it, you would get back null. Given that, I'd prefer to use MutableLiveData<Boolean?>(null) and then add a null check in so that it's clearer what's happening. It looks like the newest lifecycle modules actually give us correct typing for nullable types.

[grzesiek2010]

I already added a null check in MaterialProgressDialogFragment because it's java but you think it would be good to do the same here:

            viewModel.isLoading.observe(this@FirstLaunchActivity) { isLoading ->
                if (!isLoading) {
                    ActivityUtils.startActivityAndCloseAllOthers(
                        this@FirstLaunchActivity,
                        MainMenuActivity::class.java
                    )
                }
            }

when observing it can't be null you said that it's possible to get null by calling getValue() but if I'm not using that method I don't think if it makes sense to change anything.

[seadowg]

Ok I realized I was being over cautious because of how LiveData used to work. I thought I'd be able to write the following line in FirstLaunchViewModel:

_isLoading.value = null

This used to be possible, but it is now fixed (a lint check fails). I knew they'd improved this, but hadn't realised we'd finally got protection on the setter side as well as in the Observer.

I think this means that we can actually deprecate our custom NonNull types!

[dbemke]

Tested with Success!
Verified on Androids: 8.1, 10
Verified cases:

• landing screen: the logo, buttons, the bottom text
• landing screen in different languages
• light and dark mode
• landscape and portrait view
• deleting all project

[srujner]

Tested with Success!

Verified on Androids: 12,13