[POS as a Tab] Tab & Visibility

[toupper]

Description

With this PR, we add a tab for POS and show it when:

• Woo POS is enabled (same conditions previously used in the menu)
• The feature flag for "POS as a Tab" is enabled

When visibility is updated

We update the POS tab visibility in the following cases:

• On app startup and when returning from the background
• When the active site changes
• On user login

Navigation behavior

When the POS tab is tapped:

• The POS screen is launched
• The bottom navigation bar is hidden
• The tab is not visually selected (since it transitions to a new Activity)

Steps to reproduce

On app startup and coming to foreground, when logged in

Open the app with a site where POS is enabled. The tab should be visible. Open the app with a site where POS is not enabled. The tab should not be visible.

On site changed

Change your site in menu and check that the tab visibility is updated according to the the new site POS availability.

On login

Login and check that the tab visibility is shoen according to the the login site POS availability.

Testing information

See above

The tests that have been performed

See above

Images/gif

Switching sites

https://github.com/user-attachments/assets/76f977df-0c40-44f5-9e22-cfe32c354ab2

Login

https://github.com/user-attachments/assets/278a5f84-8d3a-4b10-8ee9-3f004fcdb007

• [ ] I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

[dangermattic]

	2 Warnings
:warning:	Class WooPosIsPosAsTabEnabled is missing tests, but unit-tests-exemption label was set to ignore this.
:warning:	Class WooPosTabController is missing tests, but unit-tests-exemption label was set to ignore this.

Generated by :no_entry_sign: Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	10853d021a21b9a0a6c0c6826c3aebdd25465b9b
	Direct Download	woocommerce-wear-prototype-build-pr14183-10853d0.apk

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	10853d021a21b9a0a6c0c6826c3aebdd25465b9b
	Direct Download	woocommerce-prototype-build-pr14183-10853d0.apk

[jaclync]

@toupper Nice progress with small amount of changes! From the screencasts, it looks like the POS tab is displayed right after logging in / switching stores, is it because it's shown by default, or the eligibility check results are cached for each connected site? Or the internet was so fast that all API calls from site settings (for store country/currency), remote feature flag, active plugins just returned with minimal delay?

In iOS, I'm exploring ways to optimize the POS eligibility check for the POS tab so that we can show the tab as soon as possible. This includes caching the eligibility result for each site for like 3 days in WOOMOB-599.

[toupper]

Thanks for your message @jaclync!

Nice progress with small amount of changes! From the screencasts, it looks like the POS tab is displayed right after logging in / switching stores, is it because it's shown by default, or the eligibility check results are cached for each connected site?

It was still showing the previous value, but that wasn't correct, so I implement hiding it by default here a4decdf2ac8e2985b18d157b4945199201f2407e. In next PRs we can consider caching the value as you suggested.

[jaclync]

It was still showing the previous value, but that wasn't correct, so I implement hiding it by default here a4decdf. In next PRs we can consider caching the value as you suggested.

Got it, I created an issue for caching the eligibility value in Android in WOOMOB-620.

[toupper]

It seems it currently loads the siteSettings from the local cache and if it's not there, it fails. I think we might need to either add some delay and check if the site settings is available after the delay and/or fetch the site settings if they are not available.

This issue was likely present even before, but it was almost impossible to reproduce since the user would need to switch to More menu very quickly, before the siteSettings request finishes.

Thanks @malinajirka, good catch and debug! I fixed that here 10853d021a21b9a0a6c0c6826c3aebdd25465b9b by indeed fetching the settings remotely if the local version fails. Let me know what you think.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 13.72549% with 44 lines in your changes missing coverage. Please review.

Project coverage is 37.71%. Comparing base (b87aa7d) to head (10853d0). Report is 348 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...merce/android/ui/woopos/tab/WooPosTabController.kt	0.00%	39 Missing :warning:
...m/woocommerce/android/ui/woopos/WooPosIsEnabled.kt	70.00%	0 Missing and 3 partials :warning:
...e/android/ui/woopos/tab/WooPosIsPosAsTabEnabled.kt	0.00%	2 Missing :warning:

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #14183      +/-   ##
============================================
- Coverage     37.72%   37.71%   -0.02%     
  Complexity     8948     8948              
============================================
  Files          1953     1955       +2     
  Lines        109379   109422      +43     
  Branches      14354    14360       +6     
============================================
+ Hits          41263    41265       +2     
- Misses        64362    64403      +41     
  Partials       3754     3754              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.