[POS] Better error handling for eligibility

[toupper]

Closes WOOMOB-1016

Only one review required, but I add you both as reviewers in case you are interested in the solution.

Description

With this PR we improve the logic for handling errors when opening POS, including when there is no connection. We implement this logic:

POS tab eligibility

• Positive → Show POS tab.
• Negative → Hide POS tab.
• Unknown (e.g., backend error) → Show tab using last cached value.
  When entering POS tab and eligibility check errors again:
• Cached Positive → Allow access to POS.
• No Cache → Deny access and show error message.

For that we:

• Update AppPrefs to cache also whether POS was launchable. We also update the tab logic to only make it possible to cache positive cases.
• Update WooPOSIsRemotelyEnabled, WooPosCanBeLaunchedInTab and WooPosTabShouldBeVisible to return a result instead of a boolean
• Refactor WooPosCanBeLaunchedInTab with the new logic, including setting the value in cache.

Steps to reproduce

With all conditions met:

• Start the app with internet connection
• Verify the POS tab is visible
• Tap on it and access POS
• Kill the app
• Turn on airplane mode
• Start the app
• Notice the POS tab is visible (before it was not)
• Tap on the tab and access POS

With the POS feature switch disabled in wp-admin:

• Start the app with internet connection
• Verify the POS tab is visible
• Go to the POS tab
• Verify that you get an error about the feature switch disabled
• Kill the app
• Turn on airplane mode
• Start the app
• Notice the POS tab is visible
• Go to the tab
• You cannot enter POS and a genetic message is shown

With a store in a country other than US or UK:

• Start the app with internet connection
• Verify the POS tab is not visible
• Kill the app
• Turn on airplane mode
• Start the app
• Notice the POS tab is not visible

Testing information

The tests that have been performed

See above

Images/gif

On this video we can see how the tab is shown in airplane mode because it was shown before, but given that we never cached whether the POS was launched, we prevent accessing it:

Screen_Recording_20250813_143918_Woo.Pre-Alpha.mp4

Here we show how if previously the user accessed POS, it can access it even if there's no connection:

Screen_Recording_20250813_144433_Woo.Pre-Alpha.mp4

• 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.

[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	42a2975
	Direct Download	woocommerce-wear-prototype-build-pr14463-42a2975.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	42a2975
	Direct Download	woocommerce-prototype-build-pr14463-42a2975.apk

[malinajirka]

Thanks for working on this @toupper! I've reviewed the code and left some questions/suggestions. I haven't tested the behavior yet. Let me know what you think and I'll test it when we resolve these discussions.

[toupper]

Thanks for your comments @malinajirka! I addressed them and refactored the code a bit to make it cleaner and easier to read. Please let me know what you think

[malinajirka]

Thanks for all the changes! The tests are failing, other than that LGTM . I've left question but feel free to ignore it.

[malinajirka]

💡 I'm wondering if this should be set to false when forceRefresh is true, wdyt?

[toupper]

That's a good question. I was considering that, and I think it's ok to keep the logic simple and use the same rationale when forceRefresh is true. If the previous check gave false eligibility we refresh the cache, so it would give us false anyways

[malinajirka]

❓ Is this test correct, why do we want to return tabVisible when remote FF is disabled?

[toupper]

Good catch, fixed in c609905

[codecov-commenter]

Codecov Report

❌ Patch coverage is 62.10526% with 36 lines in your changes missing coverage. Please review.
✅ Project coverage is 37.99%. Comparing base (dcaca49) to head (42a2975).
⚠️ Report is 273 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...merce/android/ui/woopos/tab/WooPosTabController.kt	0.00%	13 Missing ⚠️
...rc/main/kotlin/com/woocommerce/android/AppPrefs.kt	7.69%	12 Missing ⚠️
...d/ui/woopos/util/analytics/WooPosAnalyticsEvent.kt	0.00%	5 Missing ⚠️
...merce/android/ui/woopos/WooPOSIsRemotelyEnabled.kt	60.00%	1 Missing and 1 partial ⚠️
.../android/ui/woopos/tab/WooPosCanBeLaunchedInTab.kt	95.55%	1 Missing and 1 partial ⚠️
.../android/ui/woopos/tab/WooPosTabShouldBeVisible.kt	84.61%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##              trunk   #14463   +/-   ##
=========================================
  Coverage     37.98%   37.99%           
- Complexity     9207     9236   +29     
=========================================
  Files          1991     1992    +1     
  Lines        112532   112580   +48     
  Branches      14848    14858   +10     
=========================================
+ Hits          42747    42776   +29     
- Misses        65878    65898   +20     
+ Partials       3907     3906    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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