Boilerplate project template maui improvements (#9549)#9550
Boilerplate project template maui improvements (#9549)#9550yasmoradi merged 13 commits intobitfoundation:developfrom yasmoradi:9549-boilerplate-project-template-maui-needs-improvements
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe pull request introduces enhancements to the Bit Boilerplate MAUI project, focusing on .NET 9.0 compatibility and adding new features for app store interactions. The changes primarily involve updating the project configuration, adding new package references, and implementing conditional compilation for new functionalities like in-app reviews, app store information retrieval, and update checks. The modifications are specifically targeted at improving the MAUI application's capabilities for version 9.0 while maintaining backward compatibility. Changes
Sequence DiagramsequenceDiagram
participant App
participant StorageService
participant PubSubService
participant AppStoreInfo
participant InAppReviews
App->>StorageService: Initialize storage
App->>PubSubService: Subscribe to messages
App->>App: CheckForUpdates()
App->>AppStoreInfo: Get latest version
AppStoreInfo-->>App: Return version info
alt Update available
App->>InAppReviews: Prompt user for update
InAppReviews-->>App: User response
end
Assessment against linked issues
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
.github/workflows/bit.full.ci.yml (1)
175-176: Review .NET version migration strategyThe workflow shows a mixed use of .NET 8.0 and 9.0 across different test configurations. This suggests a gradual migration strategy.
Consider:
- Documenting the migration strategy in the repository
- Adding comments in the workflow file to explain the version choices
- Creating a tracking issue for completing the migration to .NET 9.0
Also applies to: 181-181
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Components/Pages/AboutPage.razor.cs (1)
35-37: Consider handling offline scenarios when fetching store version.
When appending the version fromGetLatestVersionAsync, network or store unavailability could cause failures. A fallback or exception handling might be helpful.Possible enhancement:
+#if (framework == 'net9.0') try { appVersion += $" / {await AppStoreInfo.Current.GetLatestVersionAsync(CurrentCancellationToken)}"; } catch (Exception ex) { // Fallback strategy, e.g., log or silently ignore } +#endifsrc/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Boilerplate.Client.Maui.csproj (1)
170-175: Confirm the conditional framework usage.The addition of these Oscore.Maui references under the condition
"'$(framework)' == 'net9.0' OR '$(framework)' == ''"indicates they are only active for .NET 9.0 or unspecified frameworks. Please ensure that this aligns with your intended target frameworks – for example, if future expansions to older or newer .NET versions are planned. If so, you may need additional conditions or separate references for each target.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/App.xaml.cs (2)
45-49: Unused variablestatusWithin the in-app review request, the
statusvariable is assigned but never used in follow-up logic. If you plan to handle the result of the in-app review prompt (e.g., logging or conditionally retrying), consider utilizing this variable or removing it to avoid confusion.
130-132: Consider logging ignored exceptionsYou're catching
InvalidOperationException,FileNotFoundException, andCOMExceptionwithout logging or re-throwing them. Possibly add logging or a brief comment to clarify why they're safely ignorable to aid future maintainers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.github/workflows/bit.full.ci.yml(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/App.xaml.cs(3 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Boilerplate.Client.Maui.csproj(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Components/Pages/AboutPage.razor.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/MauiProgram.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Directory.Packages.props(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Resources/AppStrings.fa.resx(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Resources/AppStrings.nl.resx(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Resources/AppStrings.resx(1 hunks)
🔇 Additional comments (14)
.github/workflows/bit.full.ci.yml (2)
167-168: Verify Azure SDK compatibility with .NET 9
The TestAzureBlobStorage project is configured to use .NET 9.0. Ensure that the Azure SDK packages used in the project are compatible with this version.
Let's check the Azure SDK package references:
✅ Verification successful
Let me gather more information about the FluentStorage.Azure.Blobs package compatibility.
Azure Blob Storage integration is compatible with .NET 9
The project uses FluentStorage.Azure.Blobs version 5.3.0, which is built on top of the Azure Storage SDK. This package is framework-agnostic as it uses the Azure Storage REST APIs, making it compatible with .NET 9. The implementation uses:
- FluentStorage.Azure.Blobs 5.3.0 for Azure Blob Storage integration
- Supports both Azure Blob Storage and local emulator via configuration
- Uses SAS URL-based authentication which is version independent
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Azure SDK package references and their compatibility
# Search for Azure SDK package references in the project
echo "Checking Azure SDK package references:"
fd -e csproj -e props | xargs rg 'Azure\.(Storage|Blobs)'
Length of output: 861
Script:
#!/bin/bash
# Check FluentStorage.Azure.Blobs package details and dependencies
# Search for any additional FluentStorage references or configurations
echo "Checking FluentStorage references and configurations:"
rg -i "fluentstorage" -A 5 -B 5
# Look for any Azure Blob Storage related service configurations
echo -e "\nChecking Azure Blob Storage configurations:"
rg -i "azureblobstorage|blobstorageoptions" -A 5 -B 5
Length of output: 35141
149-149: Verify consistency of server project restructuring
The server project paths have been updated from .Server.Api to .Server.Web. This appears to be part of a broader restructuring effort.
Let's verify the consistency of these changes across the codebase:
Also applies to: 153-153, 157-157
✅ Verification successful
Let me gather more information to understand the complete picture of this restructuring.
Path changes from .Server.Api to .Server.Web are intentional template variations
Based on the workflow file content, the path changes from .Server.Api to .Server.Web are intentional and correct. The workflow demonstrates that different template configurations are being tested with varying parameters:
- When using
--api Standaloneor--api Integratedparameters, the template generates different server project structures - The remaining
.Server.Apireferences found are in the boilerplate template source, which is correct as it serves as the base template - The workflow file shows consistent usage of
.Server.Webfor test projects (TestPostgreSQL, TestMySql, TestOther, etc.)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining .Server.Api references that might have been missed
# Search for any remaining .Server.Api references in the codebase
echo "Checking for any remaining .Server.Api references:"
rg --type-add 'config:*.{yml,yaml,json,xml,props,csproj}' -t config 'Server\.Api'
# Search for .Server.Web references to confirm the new pattern
echo "Checking .Server.Web references to confirm the pattern:"
rg --type-add 'config:*.{yml,yaml,json,xml,props,csproj}' -t config 'Server\.Web'
Length of output: 2730
Script:
#!/bin/bash
# Check the workflow file to understand the context of these changes
echo "Checking the workflow file content:"
cat .github/workflows/bit.full.ci.yml
# Check for any Server.Api or Server.Web directories in test projects
echo -e "\nChecking test project directories:"
fd -t d "Test.*Server\.(Api|Web)"
Length of output: 9877
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Resources/AppStrings.fa.resx (1)
1018-1018: Parameterizable string introduced for better localization flexibility.
The introduction of the {0} placeholder in the prompt allows for dynamic insertion of context or version details at runtime. This looks good.
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Resources/AppStrings.resx (1)
1018-1018: Improved update prompt with placeholder support.
Adding the {0} placeholder is a beneficial change for providing dynamic details about the update. Ensure that the consuming code passes the appropriate argument at runtime.
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Resources/AppStrings.nl.resx (1)
1018-1018: Consistent placeholder usage across translations.
Including the {0} placeholder aligns with other languages and supports dynamic runtime messaging. No issues noted.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Components/Pages/AboutPage.razor.cs (5)
1-2: No issues with custom directive.
These lines appear to manage special build or compile-time directives. There are no apparent concerns here.
3-5: Conditional compilation for .NET 9.0.
The usage of conditional directives helps keep the codebase flexible across different frameworks. Ensure that the build process and CI pipeline cover scenarios for multiple target frameworks, including .NET 9.0, to maintain consistent behavior.
17-22: Reorganized and new field declarations look good.
Rearranging fields can improve code readability. The addition of oem also aligns well with existing properties. Ensure that each field is consistently initialized and used.
31-31: Double-check platform usage.
If telemetryContext.Platform might ever be null or empty in certain environments, consider adding safeguards or fallback values.
33-34: Validation of appVersion and processId.
Ensure that telemetryContext.AppVersion and Environment.ProcessId are accurately assigned and valid across all supported platforms.
src/Templates/Boilerplate/Bit.Boilerplate/src/Directory.Packages.props (1)
32-34: Ensure consistency with other package references.
These newly introduced package versions for Oscore.Maui libraries appear aligned with your move to .NET 9.0. However, confirm that these versions coexist seamlessly with other dependencies across multiple frameworks (net9.0, net9.0-android, etc.). Consider verifying whether each library remains backward compatible with the rest of the solution if supporting earlier frameworks is necessary.
Here’s a script you can run to search for usages or known mentions of these new Oscore.Maui packages in your solution to confirm consistent usage:
✅ Verification successful
Let me gather more information about the framework targets and dependencies.
Package references are properly configured and framework-aligned
The verification shows that:
- The Oscore.Maui packages are only used in the MAUI project targeting .NET 9.0 frameworks (net9.0-android, net9.0-ios, net9.0-maccatalyst, and optionally net9.0-windows10.0.19041.0)
- The packages are conditionally included only when the framework is 'net9.0' or unspecified
- There are no conflicting versions or inconsistent usage across the solution
- The packages are properly referenced in both Directory.Packages.props (central version management) and the MAUI project file
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for references to the newly added packages throughout the repo.
rg "Oscore\.Maui\.AppStoreInfo|Oscore\.Maui\.InAppReviews|Oscore\.Maui\.Android\.InAppUpdates" -A 5
Length of output: 3224
Script:
#!/bin/bash
# Check framework targets and other dependencies in the MAUI project
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Boilerplate.Client.Maui.csproj
# Check if there are any other projects using these packages
fd -e csproj -x grep -l "Oscore.Maui"
Length of output: 12015
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/App.xaml.cs (1)
3-5: Ensure references are only included when necessary
The using Maui.AppStores;, using Maui.InAppReviews;, and using System.Runtime.InteropServices; directives make sense for .NET 9.0–specific features like update checks, reviews, or COMException handling. However, confirm that these references do not get included in configurations where framework != 'net9.0'. Otherwise, referencing them unconditionally might lead to compilation issues on different target frameworks.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/MauiProgram.cs (2)
10-13: Confirm package references are defined for .NET 9.0
The using Maui.AppStores;, using Maui.InAppReviews;, and using Maui.Android.InAppUpdates; directives depend on package references that must be conditionally included in the .csproj file. Ensure that these packages are only referenced for .NET 9.0 builds to avoid compilation issues in other frameworks.
45-49: Approved: In-app reviews and updates initialization
Initializing in-app reviews, app store info, and the Android in-app update feature is properly scoped under the #if (framework == 'net9.0') condition and is consistent with the rest of the code.
closes #9549
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores