Redesign Jetpack Landing Screen - with looping text animation

[ovitrif]

Closes #17073 + Closes #17074 too since it adds the default infinite looping animation to the large text.

This PR implements the Jetpack landing screen redesign with Compose and adds the infinite looping animation to the large text in the background.

A couple of remarks:

• The looping text animation is done with a LazyColumn, though it may need to be changed in the future when we'll influence the scrolling direction and speed with the gyro sensor data.
• The frosted glass effect with blur is only working on versions of Android 12 and above, while on earlier Android versions the text behind the buttons container is semi-transparent to make the buttons stand out.
• This PR doesn't add events tracking, that is to be handled later.
• The UI wasn't optimised for tablets.

To test:

Prerequisite - Enable the LandingScreenRevamp feature flag

• Either login → Me → App Settings → Debug Settings → enable LandingScreenRevamp → RESTART THE APP → logout or
• Apply this hard-coded solution:

Patch to enable the LandingScreenRevamp feature flag

diff --git a/WordPress/build.gradle b/WordPress/build.gradle
index 63260a4ca8..fe999fa92f 100644
--- a/WordPress/build.gradle
+++ b/WordPress/build.gradle
@@ -112,7 +112,7 @@ android {
         buildConfigField "boolean", "READER_COMMENTS_MODERATION", "false"
         buildConfigField "boolean", "SITE_INTENT_QUESTION", "true"
         buildConfigField "boolean", "SITE_NAME", "false"
-        buildConfigField "boolean", "LANDING_SCREEN_REVAMP", "false"
+        buildConfigField "boolean", "LANDING_SCREEN_REVAMP", "true"
         buildConfigField "boolean", "LAND_ON_THE_EDITOR", "false"
         buildConfigField "boolean", "BLOGGING_PROMPTS", "false"
         buildConfigField "boolean", "QUICK_START_EXISTING_USERS_V2", "false"

---

1️⃣ Test Case 1: Android12+ — Blurred text behind the buttons

0. Make sure LandingScreenRevamp feature flag is enabled (see prerequisite) and you're not logged in
1. Launch Jetpack App on a device or emulator with Android12 or higher Verify That the design implementation matches the design specs and the buttons container is blurring the text.
2. Let the text animation play until you see the same text scrolling at least 3 times including the initial show. Expect A smooth scrolling animation (there should be no jumps or jiggles or anything non-smooth).
3. Toggle dark mode on the device. Expect The design of the screen to adjust for night.
4. Rotate the screen to landscape Expect The design of the screen to include the Jetpack logo and the buttons to not be cut.
5. Set larger and smaller font sizes via Accessibility settings Expect The animation to still run smooth and the buttons to be visible and their text readable.
6. Try to scroll the text up and down with touch gestures Expect The scrolling animation to continue, ignoring the user scroll.

2️⃣ Test Case 2: Android12- — Semi-transparent text behind the buttons

0. Make sure LandingScreenRevamp feature flag is enabled (see prerequisite) and you're not logged in
1. Launch Jetpack App on a device or emulator with Android11 or lower Expect The large text behind the buttons container to be semi-transparent and not blurred.

3️⃣ Test Case 3: Login/Signup — Functionality

0. Make sure LandingScreenRevamp feature flag is enabled (see prerequisite) and you're not logged in
1. Launch Jetpack App
2. Tap the Continue with WordPress.com button Expect The WP.com login/signup flow to start and work as before.
   • Continue the flow expecting it to work as before.
   • Logout.
3. Tap the Enter your existing site address button Expect The login with WordPress site to work as before.
   • Continue the flow expecting it to work as before.

4️⃣ Test Case 4: WordPress app — Regression test

0. Make sure LandingScreenRevamp feature flag is enabled (see prerequisite) and you're not logged in
1. Launch the WordPress app and Expect The landing screen to be unchanged.

---

Previews

Remark The framerate of the GIF preview was cut to 10fps to be able to upload them here. The animation should run smoother on the device.

Android 12+ Light	Android 12+ Dark

Android 12- Light	Android 12- Dark

🏞 Landscape Previews on Android12+

Light Mode

Dark Mode

🎬 Smooth Recording Preview on Android12+ in Dark mode

https://user-images.githubusercontent.com/4588074/188173335-55e4290d-744f-452f-8f58-0dd3f315e736.mp4

🎬 Smooth Recording Preview on Android12- in Light mode

https://user-images.githubusercontent.com/4588074/188173814-b8a272e5-7afe-438d-b0dd-2a8240d19255.mp4

🖥 Tablet Previews

Light Mode

Dark Mode

Merging Strategy

1. Merge #17104 into feature/revamp-landing-screen/
2. Manually fix the merge conflicts of this branch by merging it locally with feature/revamp-landing-screen/ and pushing
3. Merge this branch to feature/revamp-landing-screen
4. Open a PR to merge feature/revamp-landing-screen to trunk

Regression Notes

5. Potential unintended areas of impact Unexpected, since the changes introduce a new screen. The LoginActivity was changed though.

6. What I did to test those areas of impact (or what existing automated tests I relied on) Manual testing.

7. What automated tests I added (or what prevented me from doing so) This PR only adds a new UI, these changes don't warrant tests according to our current guidelines.

PR submission checklist:

• [x] I have completed the Regression Notes.
• [x] I have considered adding accessibility improvements for my changes.
• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

You can test the Jetpack changes on this Pull Request by downloading an installable build (jetpack-installable-build-pr17117-5b51fa5.apk), or scanning this QR code:

[peril-wordpress-mobile[bot]]

	Warnings
:warning:	PR has more than 300 lines of code changing. Consider splitting into smaller PRs if possible.

Generated by :no_entry_sign: dangerJS

[antonis]

Great work @ovitrif 👍 I've tested the app on my Pixel 5 with Android 13 and everything worked as described. I've noticed a small issue on the status bar when pressing the Continue with WordPress.com or Enter your existing site address buttons.

The header is drawn on top of the status bar.

I also encountered a startup crash while trying to test on my older Huawei P9 running Android 7. I'm not sure if this is expected but I will try to debug this and provide more info.

[antonis]

I've also noticed an issue with the animation stopping if you leave the app on the background for a long time. It restarts thought after a few seconds.

[mkevins]

The header is drawn on top of the status bar.

I wonder if this can be fixed by resetting the flag when the fragment is detached, instead of destroyed 🤔 in this part:

https://github.com/wordpress-mobile/WordPress-Android/pull/17117/files#diff-0ddbcac04d7f8e41dd4ecdc185e45a7b357addd9d9822210e14ab73c2267bccdR55-R58

Edit: Actually, I was not able to reproduce this, but I think the current placement to reset the flag looks correct. I think the issue is that this is using an extension function when fullscreen is enabled, but not revering when the transitioning to the next fragment.

In my testing, it seems the status bar is already transparent, with the flag FLAG_LAYOUT_NO_LIMITS. Maybe that is all that is needed? I.e.:

diff --git a/WordPress/src/jetpack/java/org/wordpress/android/ui/accounts/login/LoginPrologueRevampedFragment.kt b/WordPress/src/jetpack/java/org/wordpress/android/ui/accounts/login/LoginPrologueRevampedFragment.kt
index 4c9d6ce0e7..3105297e3c 100644
--- a/WordPress/src/jetpack/java/org/wordpress/android/ui/accounts/login/LoginPrologueRevampedFragment.kt
+++ b/WordPress/src/jetpack/java/org/wordpress/android/ui/accounts/login/LoginPrologueRevampedFragment.kt
@@ -58,11 +58,8 @@ class LoginPrologueRevampedFragment : Fragment() {
     }
 
     private fun Window.enableFullScreen() {
-        // Set Translucent Status Bar
-        this.showFullScreen()
-
         // Set Translucent Navigation Bar
-        setFlags(FLAG_LAYOUT_NO_LIMITS, FLAG_LAYOUT_NO_LIMITS)
+        addFlags(FLAG_LAYOUT_NO_LIMITS)
     }
 
     private fun Window.disableFullScreen() {

Wdyt?

[antonis]

Actually, I was not able to reproduce this

Probably this is triggered by the camera placement at the top-left of the screen that is set to overlap with the status bar

by resetting the flag when the fragment is detached, instead of destroyed 🤔 in this part

I tried this suggestion but it did not fix the problem for me

Maybe that is all that is needed? I.e.:

I've tested this approach and it works only for the Continue with WordPress.com button. The behavior persist for the Enter your existing site address button.

Another issue I noticed while testing is that the back action (top-left button or back button / swipe action) exits the app instead of returning to the landing screen.

[ovitrif]

Thank you for reviewing, testing and reporting your findings @antonis 🙇

I noticed the issue with the statusbar myself in the Pixel emulator — hence my update to clear the flags — but wasn't sure exactly how this would work on a real device. I really need a physical Pixel device soon for testing 😸 .

The header is drawn on top of the status bar. Thanks for letting me know! Seems my fix in the onDestroyView doesn't quite do what I was hoping it will.

In my testing, it seems the status bar is already transparent, with the flag FLAG_LAYOUT_NO_LIMITS. Maybe that is all that is needed? I.e.:

@mkevins You're right on this, I should probably remove the call to the showFullScreen method anyway, it shouldn't be needed.

Thank you!

I've tested this approach and it works only for the Continue with WordPress.com button. The behavior persist for the Enter your existing site address button.

@antonis Bummer, I had high hopes for Matthew's patch 😢 . I'll continue investigating to find a fix for this issue.

[ovitrif]

Another issue I noticed while testing is that the back action (top-left button or back button / swipe action) exits the app instead of returning to the landing screen.

I've also noticed this and reported it on Matthew's draft PR for the WP app: https://github.com/wordpress-mobile/WordPress-Android/pull/17104#pullrequestreview-1092046708 (Point 1).

This could apparently be existing behaviour according to @mkevins's response, though when testing on trunk (a release version) it wasn't the case for me 🤷 .

EDIT: After a few more tests I think I might have found something relevant about this issue. It seems to be a regression also on the non-revamped Landing screen. But it's only on our revamp branches, not on trunk.

For me this behaviour reproduces only when I press back after tapping Continue with WordPress.com. For Enter your existing site address it goes back to the revamped splash screen 🤷 .

@antonis Could you please let me know if that's also the case for you? Just to double-check it's not something specific to my testing device.

[ovitrif]

I've tested this approach and it works only for the Continue with WordPress.com button. The behavior persist for the Enter your existing site address button.

According to this StackOverflow answer, clearing the FLAG_LAYOUT_NO_LIMITS should be done in fragment's onPause.

This worked for me locally. I've pushed https://github.com/wordpress-mobile/WordPress-Android/pull/17117/commits/836e631d7d19a9dd7aac2bbbd84388973b3e7e15 to address the issue.

[ovitrif]

Another issue I noticed while testing is that the back action (top-left button or back button / swipe action) exits the app instead of returning to the landing screen.

I've also noticed this and reported it on Matthew's draft PR for the WP app: #17104 (review) (Point 1).

This could apparently be existing behaviour according to @mkevins's response, though when testing on trunk (a release version) it wasn't the case for me 🤷 .

EDIT: After a few more tests I think I might have found something relevant about this issue. It seems to be a regression also on the non-revamped Landing screen. But it's only on our revamp branches, not on trunk.

This can be fixed by modifying our initial change in LoginActivity.startLogin on this if condition: getLoginPrologueFragment() == null || getLoginPrologueRevampedFragment() == null changing it into getLoginPrologueFragment() == null && getLoginPrologueRevampedFragment() == null does the trick.

@mkevins Could you please add this change to your PR, since this one is supposed to be merged after yours in the feature branch? 🙇

Commit for the fix: https://github.com/wordpress-mobile/WordPress-Android/pull/17117/commits/eb23ef0d25b8aeefab3c00675d3cab0b282d8efa

[ovitrif]

I also encountered a startup crash while trying to test on my older Huawei P9 running Android 7. I'm not sure if this is expected but I will try to debug this and provide more info.

Interesting, I didn't encounter crashes while testing with my physical device that runs Android 9. Could be that we're using something that has problems on Android 7.

Please let me know if you find anything more about this 🙇 .

[ovitrif]

I also pushed my refactoring to the auto-scrolling animation that allows it to work with different values and negative offsets, changing the direction based on scrollBy's relation to 0.

This was part of my work for the animation with gyro data, but it also included other fixes that feel proper for this branch 🚀 .

[antonis]

For me this behaviour reproduces only when I press back after tapping Continue with WordPress.com. For Enter your existing site address it goes back to the revamped splash screen 🤷 .

@ovitrif That is correct. I messed up my clipboard on my initial message 😅

[antonis]

Interesting, I didn't encounter crashes while testing with my physical device that runs Android 9. Could be that we're using something that has problems on Android 7.

I was able to reproduce this in debug mode and it seems to be a memory issue

2022-09-07 16:24:06.968 16015-16015/com.jetpack.android.beta E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.jetpack.android.beta, PID: 16015
    java.lang.RuntimeException: Canvas: trying to draw too large(165888000bytes) bitmap.
        at android.view.DisplayListCanvas.throwIfCannotDraw(DisplayListCanvas.java:260)

The full stack trace can be found here.

The device seems to have enough free memory and the specs are not so low end (considering its age). Probably it is indeed bad memory management from Android 7.

As a workaround I resized bg_jetpack_login_splash.png in half (720x1600) and it worked 🎉

https://user-images.githubusercontent.com/304044/188893624-96516c58-2d19-4919-affa-deabaa5e0058.mp4

I guess we can try different pngs for different screen resolutions to handle this in a more generic way.

[ovitrif]

I guess we can try different pngs for different screen resolutions to handle this in a more generic way.

Good point, thank you for finding the root cause of the issue 🙇

[mkevins]

Hi @ovitrif 👋 😄

Could you please add this change to your PR, since this one is supposed to be merged after yours in the feature branch?

Good catch! I've added this here: https://github.com/wordpress-mobile/WordPress-Android/pull/17104/commits/3cb9170c9316422008c5366c83b84ab7bc9e838d

[ovitrif]

I guess we can try different pngs for different screen resolutions to handle this in a more generic way.

Added in https://github.com/wordpress-mobile/WordPress-Android/pull/17117/commits/4c613b7d4ae8e43e270e5d168bea0b81d19aebbe 👍

@antonis Could you please test this again on your Huawei P9 device when you have time for it? Thanks in advance 🙇

[wpmobilebot]

You can test the WordPress changes on this Pull Request by downloading an installable build (wordpress-installable-build-pr17117-5b51fa5.apk), or scanning this QR code:

[antonis]

Could you please test this again on your Huawei P9 device when you have time for it? Thanks in advance 🙇

The build with the latest changes fixed this for me. Great work @ovitrif 👍

[antonis]

I've retested the Jetpack app on both my devices (Pixel 5/Android 13 and Huawei P9/Android 7) and everything worked as expected. I noticed a minor issue when bringing the app back from the background on my Pixel device.

Before getting the app to the background	After putting the app to the background
Notice the white white area at the top and bottom

I wasn't able to test the WordPress app locally due to the missing fragment on the WP variant.

[ovitrif]

I noticed a minor issue when bringing the app back from the background on my Pixel device. [...] Notice the white white area at the top and bottom

Thank you for reporting this issue @antonis 🙇

I'm working on a fix, this also replicates on the WP revamped landing screen for me. I couldn't reproduce it with the emulator but I see it on my physical device too 👍

[ovitrif]

I noticed a minor issue when bringing the app back from the background on my Pixel device. [...] Notice the white white area at the top and bottom

Thank you for reporting this issue @antonis 🙇

I'm working on a fix, this also replicates on the WP revamped landing screen for me. I couldn't reproduce it with the emulator but I see it on my physical device too 👍

Added a fix in https://github.com/wordpress-mobile/WordPress-Android/pull/17117/commits/fa1d85ca34d985100a1cf8c50de38616709378c9 👍