Add Trails actions demo app

[tolgahan-arikan]

Summary

• add a generated Trails API client for the Trails actions demo
• add a trails-actions Android sample app with auth, Polygon balances, earn positions, and Trails swap/deposit/withdraw actions
• align the demo UI with the existing Kotlin auth styling and the TypeScript Trails actions layout where applicable

Notes

• The swap-then-deposit flow follows the Swift example two-step behavior: send swap, then prepare/send deposit after USDC output is observed.
• The demo keeps the existing whitelisted OIDC redirect URI used by the Kotlin auth sample.

Verification

• ./gradlew :trails-actions:compileDebugKotlin :trails-actions:lintDebug :trails-actions:assembleDebug ktlintCheck
• ./gradlew :trails-actions:installDebug
• launched com.omsclient.kotlin_sdk_trails_actions/.TrailsActionsActivity on the visible emulator
• git diff --check origin/master..HEAD
• pre-push hook ran ktlintCheck successfully

[claude]

Claude finished @tolgahan-arikan's task —— View job

---

PR Review Complete

I've completed a thorough review of this PR that adds a Trails actions demo app. Here's my assessment:

Todo List:

• Read and analyze main implementation files
• Review security aspects of auth and credential handling
• Check code style compliance and KDoc coverage
• Verify if public API changes need documentation updates
• Provide comprehensive review feedback

Summary

This PR adds a comprehensive demo app for Trails API integration. Overall the implementation is solid and follows good practices, but I've identified several areas for improvement.

✅ Strengths

• Proper SDK Integration: Correctly uses the main SDK for auth, wallet operations, and transaction sending
• Security Best Practices: Auth flow is secure, uses proper session management, no credential exposure
• Error Handling: Good error handling throughout with descriptive error messages
• UI State Management: Proper UI state management with loading states and status updates
• Code Organization: Well-structured code with clear separation of concerns

Issues Found

🔴 Security Concern - Hard-coded API Key

File: TrailsActionsActivity.kt:1969

const val TRAILS_ACCESS_KEY = "AQAAAAAAAMCYJYqQIBlKgsdYZIC44JP84lo"

This API key is hard-coded in the source. While likely a demo key, this should be:

• Documented as a demo-only key if safe to expose
• Or moved to build config/environment variables
• Include a comment explaining this is for demo purposes only

🟡 Code Style Issues

1. Missing KDoc on Public APIs: The TrailsActionsActivity class and public methods lack KDoc comments. While this is a demo app, following the project's KDoc standards would be better.

2. Generated Code: The TrailsApiClient.kt (7K+ lines) is generated code. This is fine, but ensure it's excluded from ktlint checks in the build config (which it appears to be: exclude("**/generated/**")).

🟡 Architecture/Design Considerations

1. Large Activity Class: TrailsActionsActivity.kt is nearly 2000 lines. Consider splitting into:

   • Separate UI helpers/builders
   • Business logic classes
   • Data models in separate files

2. Magic Numbers: Several magic numbers could be extracted to constants:

   • POST_SEND_REFRESH_ATTEMPTS = 24 - should be documented why this specific number
   • MAX_REASONABLE_USDC_APY_RATE = 0.5 - explain this threshold

3. Coroutine Scope: Uses MainScope() which is acceptable for demo code, but production code might want more structured scope management.

🟢 Minor/Nits

1. Long Parameter Lists: Some functions have many parameters - consider data classes for complex parameter sets
2. String Concatenation: Some places use string concatenation instead of string templates
3. Nullable Chains: Some nullable chains could be simplified with ?.let or similar

No Documentation Updates Needed

The PR correctly doesn't modify any public SDK APIs - it only adds a demo app that consumes existing APIs. No changes to docs/api.md or README.md are needed.

Verification Notes

The author has already verified:

• ✅ Compilation and lint checks
• ✅ Manual testing on emulator
• ✅ ktlint formatting compliance
• ✅ Git formatting check

Recommendation

Approve with minor suggestions. The security concern about the hard-coded API key should be addressed with documentation clarifying it's a demo key (if safe) or moved to build config. The large activity class could benefit from refactoring but isn't a blocker for a demo app.

The implementation demonstrates proper SDK usage patterns and provides a valuable example for developers learning the Trails API integration.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ba05ca5eb5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Claude finished @tolgahan-arikan's task —— View job

---

PR Review Complete

I've completed a thorough review of this PR that adds a Trails actions demo app. Here's my assessment:

Todo List:

• Read and analyze main implementation files
• Review security aspects of auth and credential handling
• Check code style compliance and KDoc coverage
• Verify if public API changes need documentation updates
• Provide comprehensive review feedback

Summary

This PR adds a comprehensive demo app for Trails API integration. Overall the implementation is solid and follows good practices, but I've identified several areas for improvement.

✅ Strengths

• Proper SDK Integration: Correctly uses the main SDK for auth, wallet operations, and transaction sending
• Security Best Practices: Auth flow is secure, uses proper session management, no credential exposure
• Error Handling: Good error handling throughout with descriptive error messages
• UI State Management: Proper UI state management with loading states and status updates
• Code Organization: Well-structured code with clear separation of concerns

Issues Found

🔴 Security Concern - Hard-coded API Key

File: TrailsActionsActivity.kt:1969

const val TRAILS_ACCESS_KEY = "AQAAAAAAAMCYJYqQIBlKgsdYZIC44JP84lo"

This API key is hard-coded in the source. While likely a demo key, this should be:

• Documented as a demo-only key if safe to expose
• Or moved to build config/environment variables
• Include a comment explaining this is for demo purposes only

🟡 Code Style Issues

1. Missing KDoc on Public APIs: The TrailsActionsActivity class and public methods lack KDoc comments. While this is a demo app, following the project's KDoc standards would be better.

2. Generated Code: The TrailsApiClient.kt (7K+ lines) is generated code. This is fine, but ensure it's excluded from ktlint checks in the build config (which it appears to be: exclude("**/generated/**")).

🟡 Architecture/Design Considerations

1. Large Activity Class: TrailsActionsActivity.kt is nearly 2000 lines. Consider splitting into:

   • Separate UI helpers/builders
   • Business logic classes
   • Data models in separate files

2. Magic Numbers: Several magic numbers could be extracted to constants:

   • POST_SEND_REFRESH_ATTEMPTS = 24 - should be documented why this specific number
   • MAX_REASONABLE_USDC_APY_RATE = 0.5 - explain this threshold

3. Coroutine Scope: Uses MainScope() which is acceptable for demo code, but production code might want more structured scope management.

🟢 Minor/Nits

1. Long Parameter Lists: Some functions have many parameters - consider data classes for complex parameter sets
2. String Concatenation: Some places use string concatenation instead of string templates
3. Nullable Chains: Some nullable chains could be simplified with ?.let or similar

No Documentation Updates Needed

The PR correctly doesn't modify any public SDK APIs - it only adds a demo app that consumes existing APIs. No changes to docs/api.md or README.md are needed.

Verification Notes

The author has already verified:

• ✅ Compilation and lint checks
• ✅ Manual testing on emulator
• ✅ ktlint formatting compliance
• ✅ Git formatting check

Recommendation

Approve with minor suggestions. The security concern about the hard-coded API key should be addressed with documentation clarifying it's a demo key (if safe) or moved to build config. The large activity class could benefit from refactoring but isn't a blocker for a demo app.

The implementation demonstrates proper SDK usage patterns and provides a valuable example for developers learning the Trails API integration.

[tolgahan-arikan]

Addressed the review feedback in 536b2a4:

• Commit the Trails intent before sending the wallet transaction, then execute it with the resulting transaction hash.
• Wait for the Trails intent receipt and expected USDC balance increase before continuing to the deposit leg.
• Added a comment documenting the hard-coded Trails access key as demo-only.