Unify the logic of fetching product by SKU

[samiuelson]

Closes: #11919

Description

This PR intends to unify the logic responsible for fetching the product by SKU.

Context: Users reported a problem that it's impossible to add a product by scanning its barcode in the order creation flow, however, the product was detected correctly in the Products screen. The hypothesis was that the EAN-13 checksum was not handled correctly in the OrderCreateEditViewModel, however, it turned out that the product was not found because it was fetched from the local storage only.

There are also the following reasons for that change:

• Keeping the business logic extracted from view models in a use case – making it easier to read, and debug the code.
• Avoid discrepancies between how we fetch products by SKU in different places in the app (Scan to update product inventory – Products screen, and Order creation flow).
• Avoid code duplication
• Extract/reduce code in the OrderCreateEditViewModel class that contains too much code

To achieve the above, this PR switches to using the existing FetchProductBySKU class in the OrderCreateEditViewModel. The difference between the existing logic in the VM and the FetchProductBySKU use case is that the latter on attempts to look for the product on the remote in case it's not found in the local cache.

Steps to reproduce

1. Create a new order
2. Scan a barcode of a product that is not present in the local cache (DB)
3. Verify the app fails to add the product

Testing information

It's important to do thorough tests of the order creation flow — adding a product by scanning the barcode, including edge-cases, e.g. wrong barcode value (not matching any SKU), barcode matching existing SKU present on remote only, etc.

The tests that have been performed

I tested that this PR fixes the above scenario. Device: Pixel 8, Android 14

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

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.

[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	8a8490e
	Direct Download	woocommerce-wear-prototype-build-pr12540-8a8490e.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	8a8490e
	Direct Download	woocommerce-prototype-build-pr12540-8a8490e.apk

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 77.77778% with 4 lines in your changes missing coverage. Please review.

Project coverage is 40.59%. Comparing base (114603f) to head (8a8490e).
Report is 252 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...oid/ui/orders/creation/OrderCreateEditViewModel.kt	77.77%	1 Missing and 3 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #12540      +/-   ##
============================================
- Coverage     40.61%   40.59%   -0.02%     
+ Complexity     5665     5653      -12     
============================================
  Files          1228     1228              
  Lines         68917    68900      -17     
  Branches       9544     9542       -2     
============================================
- Hits          27991    27971      -20     
- Misses        38354    38356       +2     
- Partials       2572     2573       +1     

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

[AnirudhBhat]

Thanks for the improvement @samiuelson. The fix works fine. I've left couple of comments about showing progress bar while we fetch product from remote and adding unit tests. Let me know what you think!

[AnirudhBhat]

❓ I don't think we need this. Please refer my comment below.

[AnirudhBhat]

⚠️ Since this is launched in a coroutine, i think we need to display progress bar (isUpdatingOrderDraft = true) so that UI won't look like it is frozen. What do you think?

Also, we could write unit tests to test these business logic.

[samiuelson]

Done – 5e74c63

[samiuelson]

we could write unit tests to test these business logic

I reviewed existing unit tests and think the logic of fetchProductBySKU is covered pretty well. If you can see any scenario missing let me know though, @AnirudhBhat!

[AnirudhBhat]

I meant adding tests for the newly made changes of showing and hiding progress bar while fetching SKU.

[wpmobilebot]

Version 20.4 has now entered code-freeze, so the milestone of this PR has been updated to 20.5.

[samiuelson]

Thanks for the review, @AnirudhBhat! I've addressed your comments. Let me know what you think.

[AnirudhBhat]

LGTM! I've just left one minor comment about adding unit test for the newly added logic of displaying and hiding progress bar while fetching product from SKU.