Skip to content

Conversation

@JinUng41
Copy link
Collaborator

@JinUng41 JinUng41 commented May 28, 2025

👻 PULL REQUEST

📄 작업 내용

  • 프로필 화면에서도 사진을 눌렀을 때, 사진 상세 뷰가 보이도록 수정하였습니다.
  • 강제 업데이트와 관련한 객체를 선언하고 설계하여, 기능을 고도화 하였습니다.
  • DI를 위한 환경 객체의 네이밍을 변경하였습니다. (BuildConfiguration.debug/.release -> AppEnvironment.mock/.production)

💻 주요 코드 설명

강제 업데이트를 위한 객체 선언과 구조 설계

  • 강제 업데이트를 위한 기능을 완성하기 위하여 Repository - UseCase & Entity의 구조를 설계하였습니다.
  • 레포지토리는 두 가지입니다.
    • 버전 정보를 가져오는 AppVersionRepository
    • 이미 업데이트 안내를 보여준 적이 있는지에 대한 정보를 저장하고, 가져오는 UpdateAlertPolicyRepository
  • Entity는 AppVersion으로 major, minor, patch (0.0.0)의 프로퍼티를 가집니다.
  • 유즈케이스에서 앱스토어와 현재 앱의 AppVersion을 가져와 비교하고, UpdateRequirement를 반환합니다.
    • UpdateRequirement.none: 필요없음.
    • UpdateRequirement.optional: 선택적 안내 -> 취소를 누르게 되면 다시 안내가 뜨지 않으며, 앱이 재시작 해도 뜨지 않음.
    • UpdateRequirement.frequent: 반복적 안내 -> 취소를 누르게 되면 안내가 사라지지만, 앱이 재시작하게 되면 다시 뜨게 됨.
    • UpdateRequirement.force: 강제 -> 취소가 없음
  • SceneDelegate에서 유즈케이스가 리턴하는 UpdateRequirement에 따라 안내를 띄울지 말지 결정합니다.

관련 코드는 커밋 기록을 확인해 주세요!

👀 기타 더 이야기해볼 점

  • 원래 유즈케이스를 사용하지 않기로 하였으나 이번 같은 경우 다시 유즈케이스라는 명칭으로 작성하게 되었는데, 추후 이러한 경우 해당 객체의 네이밍을 고민해 보면 좋을 듯 합니다.
    • 비즈니스 로직을 담당하지만, 유즈케이스처럼 특정 행위를 대표하는 행위는 아닌,, 그런 객체의 네이밍? 그래서 단순하게는 Service라는 네이밍을 생각해보긴 했습니다.

🔗 연결된 이슈

Summary by CodeRabbit

  • New Features

    • Added app version checking and update alert functionality, including support for distinguishing between required, frequent, and optional updates.
    • Introduced interactive image viewing in user profile screens, allowing users to tap on images to view them in detail.
  • Improvements

    • Enhanced update alert messaging with improved formatting and clarity.
  • Refactor

    • Updated environment configuration and dependency injection logic for improved flexibility and maintainability.

@JinUng41 JinUng41 requested a review from youz2me May 28, 2025 20:04
@JinUng41 JinUng41 self-assigned this May 28, 2025
@JinUng41 JinUng41 added the 🛠️ fix 기능적 버그나 오류 해결 시 사용 label May 28, 2025
@JinUng41 JinUng41 added the 🍻 진웅 술 한잔 가온나~ label May 28, 2025
@coderabbitai
Copy link

coderabbitai bot commented May 28, 2025

Walkthrough

This update introduces a modular app version management and update requirement feature. It adds new entities, repositories, and use cases for version checking and update alert policies. The dependency injection and environment configuration logic are refactored, and the update check flow in the app's scene delegate is replaced with a new use case-driven approach. Profile image tap-to-detail functionality is also added.

Changes

Files/Groups Change Summary
Wable-iOS.xcodeproj/project.pbxproj Project structure updated: new groups and source files for app versioning, update policies, and DI changes.
Wable-iOS/App/AppDelegate+InjectDependency.swift DI registrations updated for new repositories; environment parameter renamed; new repositories registered.
Wable-iOS/App/SceneDelegate.swift Old version check logic removed; new async use case-based update check and alert flow implemented.
Wable-iOS/Core/DI/AppEnvironment.swift, Wable-iOS/Core/DI/BuildConfiguration.swift AppEnvironment enum added; BuildConfiguration enum removed.
Wable-iOS/Core/DI/DIContainer.swift, Wable-iOS/Core/DI/Injected.swift DI protocols and property wrapper updated to use AppEnvironment instead of BuildConfiguration.
Wable-iOS/Core/Literals/String/StringLiterals+Update.swift Update alert strings revised for improved formatting and clarity.
Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift, .../UpdateAlertPolicyRepositoryImpl.swift New repository implementations for app version and update alert policy, including mock versions.
Wable-iOS/Domain/Entity/AppVersion.swift, Wable-iOS/Domain/Enum/UpdateRequirement.swift New AppVersion struct and UpdateRequirement enum introduced.
Wable-iOS/Domain/RepositoryInterface/AppVersionRepository.swift, .../UpdateAlertPolicyRepository.swift New repository interfaces for app version and update alert policy.
Wable-iOS/Domain/UseCase/AppVersion/CheckAppUpdateRequirementUseCase.swift New use case and implementation for determining update requirements.
Wable-iOS/Presentation/Profile/My/View/MyProfileViewController.swift, .../OtherProfileViewController.swift Added tap handler to content images for presenting a photo detail view.

Sequence Diagram(s)

sequenceDiagram
    participant SceneDelegate
    participant CheckAppUpdateRequirementUseCase
    participant AppVersionRepository
    participant UpdateAlertPolicyRepository

    SceneDelegate->>CheckAppUpdateRequirementUseCase: execute()
    CheckAppUpdateRequirementUseCase->>AppVersionRepository: fetchAppStoreVersion()
    AppVersionRepository-->>CheckAppUpdateRequirementUseCase: AppStoreVersion
    CheckAppUpdateRequirementUseCase->>AppVersionRepository: fetchCurrentVersion()
    AppVersionRepository-->>CheckAppUpdateRequirementUseCase: CurrentVersion
    CheckAppUpdateRequirementUseCase->>UpdateAlertPolicyRepository: hasSeenOptionalAlert()
    UpdateAlertPolicyRepository-->>CheckAppUpdateRequirementUseCase: Bool
    CheckAppUpdateRequirementUseCase-->>SceneDelegate: UpdateRequirement
    SceneDelegate->>SceneDelegate: showUpdateAlert(for: requirement)
Loading

Assessment against linked issues

Objective Addressed Explanation
Profile image tap opens image detail view (#214)
Refactor/modify forced update logic (#214)

Possibly related PRs

Suggested labels

✨ feat, ⚙️ setting, 🦉 유진

Poem

🐇
A hop, a leap, a version check anew,
With updates now alerting you!
Tap a profile image, see it bloom—
Dependency injected, all tidy in the room.
The code hops forward, neat and bright,
Wable’s features shining light!
🥕


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d6fa8fa and 9e3cad4.

📒 Files selected for processing (2)
  • Wable-iOS/App/SceneDelegate.swift (3 hunks)
  • Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • Wable-iOS/App/SceneDelegate.swift
  • Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (4)
Wable-iOS/Domain/Entity/AppVersion.swift (1)

15-23: Consider input validation and error handling.

The current implementation silently ignores invalid version components and defaults to 0, which may mask malformed version strings. Consider adding validation or throwing errors for invalid inputs.

     init(from versionString: String) {
+        guard !versionString.isEmpty else {
+            self.major = 0
+            self.minor = 0  
+            self.patch = 0
+            return
+        }
+        
         let components = versionString
             .split(separator: ".")
-            .compactMap { Int($0) }
+            .compactMap { 
+                let intValue = Int($0)
+                return intValue != nil && intValue! >= 0 ? intValue : nil
+            }
         
         self.major = components.count > 0 ? components[0] : 0
         self.minor = components.count > 1 ? components[1] : 0
         self.patch = components.count > 2 ? components[2] : 0
     }
Wable-iOS/App/AppDelegate+InjectDependency.swift (1)

67-69: Fix SwiftLint warning: Replace unused parameter with underscore.

The env parameter is not used in the closure and should be replaced with an underscore to follow Swift conventions.

-        diContainer.register(for: GhostRepository.self) { env in
+        diContainer.register(for: GhostRepository.self) { _ in
             return GhostRepositoryImpl()
         }
🧰 Tools
🪛 SwiftLint (0.57.0)

[Warning] 67-67: Unused parameter in a closure should be replaced with _

(unused_closure_parameter)

Wable-iOS/Domain/UseCase/AppVersion/CheckAppUpdateRequirementUseCase.swift (2)

18-32: Consider using Comparable for cleaner version comparison.

The version comparison logic could be simplified if AppVersion implemented Comparable. This would make the code more readable and less error-prone.

If AppVersion implements Comparable, this logic could be simplified to:

     func execute() async throws -> UpdateRequirement {
         let appStoreVersion = try await appVersionRepository.fetchAppStoreVersion()
         let currentVersion = appVersionRepository.fetchCurrentVersion()
         let isAlreadyShown = updateAlertPolicyRepository.hasSeenOptionalAlert()
         
-        let requirement: UpdateRequirement
-        if appStoreVersion.major > currentVersion.major {
-            requirement = .force
-        } else if appStoreVersion.minor > currentVersion.minor {
-            requirement = .frequent
-        } else if appStoreVersion.patch > currentVersion.patch {
-            requirement = .optional
-        } else {
-            requirement = .none
-        }
+        guard appStoreVersion > currentVersion else {
+            return .none
+        }
+        
+        let requirement: UpdateRequirement
+        if appStoreVersion.major > currentVersion.major {
+            requirement = .force
+        } else if appStoreVersion.minor > currentVersion.minor {
+            requirement = .frequent
+        } else {
+            requirement = .optional
+        }

34-43: Simplify the optional update logic.

The conditional logic for handling optional updates can be simplified for better readability.

-        if requirement == .optional, isAlreadyShown {
-            return .none
-        }
-        
-        if requirement == .optional, !isAlreadyShown {
-            updateAlertPolicyRepository.markOptionalAlertShown()
-            return .optional
-        }
-        
-        return requirement
+        if requirement == .optional {
+            if isAlreadyShown {
+                return .none
+            } else {
+                updateAlertPolicyRepository.markOptionalAlertShown()
+                return .optional
+            }
+        }
+        
+        return requirement
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b6d5dca and d6fa8fa.

📒 Files selected for processing (17)
  • Wable-iOS.xcodeproj/project.pbxproj (19 hunks)
  • Wable-iOS/App/AppDelegate+InjectDependency.swift (3 hunks)
  • Wable-iOS/App/SceneDelegate.swift (3 hunks)
  • Wable-iOS/Core/DI/AppEnvironment.swift (1 hunks)
  • Wable-iOS/Core/DI/BuildConfiguration.swift (0 hunks)
  • Wable-iOS/Core/DI/DIContainer.swift (2 hunks)
  • Wable-iOS/Core/DI/Injected.swift (1 hunks)
  • Wable-iOS/Core/Literals/String/StringLiterals+Update.swift (1 hunks)
  • Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift (1 hunks)
  • Wable-iOS/Data/RepositoryImpl/UpdateAlertPolicyRepositoryImpl.swift (1 hunks)
  • Wable-iOS/Domain/Entity/AppVersion.swift (1 hunks)
  • Wable-iOS/Domain/Enum/UpdateRequirement.swift (1 hunks)
  • Wable-iOS/Domain/RepositoryInterface/AppVersionRepository.swift (1 hunks)
  • Wable-iOS/Domain/RepositoryInterface/UpdateAlertPolicyRepository.swift (1 hunks)
  • Wable-iOS/Domain/UseCase/AppVersion/CheckAppUpdateRequirementUseCase.swift (1 hunks)
  • Wable-iOS/Presentation/Profile/My/View/MyProfileViewController.swift (1 hunks)
  • Wable-iOS/Presentation/Profile/Other/View/OtherProfileViewController.swift (1 hunks)
💤 Files with no reviewable changes (1)
  • Wable-iOS/Core/DI/BuildConfiguration.swift
🧰 Additional context used
🧬 Code Graph Analysis (5)
Wable-iOS/Domain/RepositoryInterface/UpdateAlertPolicyRepository.swift (1)
Wable-iOS/Data/RepositoryImpl/UpdateAlertPolicyRepositoryImpl.swift (4)
  • hasSeenOptionalAlert (20-22)
  • hasSeenOptionalAlert (32-34)
  • markOptionalAlertShown (24-26)
  • markOptionalAlertShown (36-36)
Wable-iOS/Core/DI/Injected.swift (1)
Wable-iOS/Core/DI/DIContainer.swift (1)
  • resolve (47-60)
Wable-iOS/Domain/RepositoryInterface/AppVersionRepository.swift (1)
Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift (4)
  • fetchAppStoreVersion (17-37)
  • fetchAppStoreVersion (49-51)
  • fetchCurrentVersion (39-43)
  • fetchCurrentVersion (53-55)
Wable-iOS/Domain/UseCase/AppVersion/CheckAppUpdateRequirementUseCase.swift (2)
Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift (4)
  • fetchAppStoreVersion (17-37)
  • fetchAppStoreVersion (49-51)
  • fetchCurrentVersion (39-43)
  • fetchCurrentVersion (53-55)
Wable-iOS/Data/RepositoryImpl/UpdateAlertPolicyRepositoryImpl.swift (4)
  • hasSeenOptionalAlert (20-22)
  • hasSeenOptionalAlert (32-34)
  • markOptionalAlertShown (24-26)
  • markOptionalAlertShown (36-36)
Wable-iOS/App/AppDelegate+InjectDependency.swift (1)
Wable-iOS/Core/DI/DIContainer.swift (2)
  • register (35-37)
  • register (39-41)
🪛 SwiftLint (0.57.0)
Wable-iOS/App/AppDelegate+InjectDependency.swift

[Warning] 67-67: Unused parameter in a closure should be replaced with _

(unused_closure_parameter)

🔇 Additional comments (24)
Wable-iOS/Core/DI/AppEnvironment.swift (1)

10-13: LGTM! Clean and semantically improved enum definition.

The replacement of BuildConfiguration with AppEnvironment provides better semantic clarity. Using mock and production cases is more descriptive than debug and release for dependency injection contexts.

Wable-iOS/Domain/RepositoryInterface/UpdateAlertPolicyRepository.swift (1)

10-13: LGTM! Well-designed repository interface.

The protocol follows the single responsibility principle with a clean, focused interface for managing update alert policies. Method signatures are appropriately designed with meaningful names and correct return types.

Wable-iOS/Domain/Enum/UpdateRequirement.swift (1)

10-15: LGTM! Logical and well-structured enum design.

The enum cases form a clear hierarchy representing different levels of update necessity. The progression from noneoptionalfrequentforce provides intuitive semantics for the update checking system.

Wable-iOS/Presentation/Profile/Other/View/OtherProfileViewController.swift (1)

213-217: LGTM! Properly implemented image tap handler.

The implementation correctly:

  • Uses [weak self] to prevent retain cycles
  • Guards against nil image before presentation
  • Follows iOS conventions for modal presentation with animation
  • Provides smooth user experience for photo detail viewing
Wable-iOS/Presentation/Profile/My/View/MyProfileViewController.swift (1)

214-218: LGTM! Good implementation of image tap functionality.

The implementation correctly follows iOS best practices:

  • Uses weak self capture to prevent retain cycles
  • Safely unwraps the image with a guard statement
  • Presents the detail view with animation

This enhances the user experience by allowing users to view profile content images in detail.

Wable-iOS/Domain/RepositoryInterface/AppVersionRepository.swift (1)

10-13: Well-designed protocol for app version management.

The protocol design is excellent:

  • Clear separation of concerns between App Store and current version fetching
  • Appropriate use of async throws for network operations
  • Clean abstraction that supports dependency injection and testing
  • Follows Swift naming conventions

This provides a solid foundation for the app update requirement feature.

Wable-iOS/Core/DI/Injected.swift (1)

14-15: LGTM! Consistent refactoring to AppEnvironment.

The parameter change from BuildConfiguration to AppEnvironment is well-executed:

  • The default value change from .release to .production is semantically appropriate
  • Consistent with the broader dependency injection refactoring
  • Maintains the same functionality while supporting the new environment-based approach

This change properly supports the new app versioning feature's dependency injection requirements.

Wable-iOS/Core/Literals/String/StringLiterals+Update.swift (1)

15-16: LGTM! Improved string formatting for better UX.

The string literal updates enhance the user experience:

  • The title "업데이트 안내" (Update Notice) is more descriptive and informative
  • The reformatted message with additional line breaks improves readability
  • These changes align well with the new app update notification system

The updated strings provide clearer communication to users about app updates.

Wable-iOS/App/AppDelegate+InjectDependency.swift (2)

22-29: LGTM! Consistent environment parameter usage.

The migration from config to env parameter and the switch from BuildConfiguration to AppEnvironment cases is correctly implemented.


71-89: Well-structured new repository registrations.

The new AppVersionRepository and UpdateAlertPolicyRepository registrations follow the established pattern and properly implement environment-based instantiation.

Wable-iOS/Data/RepositoryImpl/UpdateAlertPolicyRepositoryImpl.swift (2)

10-27: Excellent implementation following best practices.

The repository implementation demonstrates good design:

  • Dependency injection of UserDefaults enables testability
  • Private static key prevents external access
  • Clean, focused interface for managing update alert policy
  • Proper separation of concerns

31-37: Good mock implementation for testing.

The mock implementation correctly returns false for hasSeenOptionalAlert() and provides a no-op implementation for markOptionalAlertShown(), which is appropriate for testing scenarios.

Wable-iOS/Domain/UseCase/AppVersion/CheckAppUpdateRequirementUseCase.swift (1)

14-16: Well-designed use case with proper dependency injection.

The use case follows clean architecture principles with clear separation of concerns and proper dependency injection using the @Injected property wrapper.

Wable-iOS/Data/RepositoryImpl/AppVersionRepositoryImpl.swift (2)

39-43: LGTM!

Good implementation with appropriate fallback handling for missing version info.


48-56: LGTM!

Good practice to provide a mock implementation for testing.

Wable-iOS/Core/DI/DIContainer.swift (1)

14-14: LGTM! Consistent refactoring from BuildConfiguration to AppEnvironment.

The changes properly update all references from BuildConfiguration to AppEnvironment, including:

  • Protocol method signatures
  • Implementation methods
  • Environment check from .release to .production
  • Error messages

The refactoring maintains the same functionality while aligning with the new naming convention.

Also applies to: 19-19, 39-39, 47-60

Wable-iOS/App/SceneDelegate.swift (2)

189-204: LGTM! Well-structured alert handling.

The method properly handles different update requirements:

  • Shows cancel option only for non-mandatory updates (frequent/optional)
  • Always provides update option
  • Clean separation of UI logic

206-215: LGTM! Good extraction with proper validation.

The method properly validates the URL and checks if it can be opened before attempting to open the App Store. Good error logging for debugging.

Wable-iOS.xcodeproj/project.pbxproj (6)

255-261: PBXBuildFile entries for app update feature
The newly added PBXBuildFile entries for AppVersion, UpdateRequirement, the repositories, use case implementations, and AppEnvironment.swift are correctly declared. These ensure that Xcode knows to compile and bundle the new Swift files.

Also applies to: 358-358


621-627: PBXFileReference entries for new source files
The PBXFileReference entries for AppVersion.swift, UpdateRequirement.swift, the repository interfaces and implementations, and AppEnvironment.swift are accurately added under the appropriate groups.

Also applies to: 722-722


828-828: DI group updated with AppEnvironment
AppEnvironment.swift has been added to the DI group, replacing the former build-configuration approach. The group path and sourceTree settings align with other DI artifacts.


1474-1474: Domain/UseCase group extended
An AppVersion subgroup is now referenced in the Domain/UseCase group, preparing the directory structure for version-checking use cases.


1675-1682: AppVersion PBXGroup configuration
The new AppVersion PBXGroup is correctly defined, containing CheckAppUpdateRequirementUseCase.swift. Its path = AppVersion and sourceTree = "<group>" settings are consistent with the rest of the domain hierarchy.


2660-2660: Sources build phase entries for update logic
All new Swift files related to forced-update functionality (UpdateAlertPolicyRepository.swift, AppVersionRepository.swift, CheckAppUpdateRequirementUseCase.swift, AppVersionRepositoryImpl.swift, UpdateAlertPolicyRepositoryImpl.swift, AppVersion.swift, and UpdateRequirement.swift) are properly listed in the Sources build phase. This guarantees their inclusion in the compilation process.

Also applies to: 2673-2673, 2747-2747, 2855-2855, 2882-2882, 2924-2924, 2972-2972

Comment on lines +10 to +14
struct AppVersion {
let major: Int
let minor: Int
let patch: Int

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Add Comparable conformance for version comparisons.

The AppVersion struct should implement Comparable to enable direct version comparisons, which would be useful for the update requirement logic.

-struct AppVersion {
+struct AppVersion: Comparable {
     let major: Int
     let minor: Int
     let patch: Int
+    
+    static func < (lhs: AppVersion, rhs: AppVersion) -> Bool {
+        if lhs.major != rhs.major {
+            return lhs.major < rhs.major
+        }
+        if lhs.minor != rhs.minor {
+            return lhs.minor < rhs.minor
+        }
+        return lhs.patch < rhs.patch
+    }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
struct AppVersion {
let major: Int
let minor: Int
let patch: Int
struct AppVersion: Comparable {
let major: Int
let minor: Int
let patch: Int
static func < (lhs: AppVersion, rhs: AppVersion) -> Bool {
if lhs.major != rhs.major {
return lhs.major < rhs.major
}
if lhs.minor != rhs.minor {
return lhs.minor < rhs.minor
}
return lhs.patch < rhs.patch
}
🤖 Prompt for AI Agents
In Wable-iOS/Domain/Entity/AppVersion.swift around lines 10 to 14, the
AppVersion struct lacks Comparable conformance, which is needed for direct
version comparisons. Implement the Comparable protocol by adding a static
function that compares two AppVersion instances, comparing major, then minor,
then patch values in order. This will enable natural sorting and comparison of
versions.

Copy link
Member

@youz2me youz2me left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

고생하셨습니다!

Comment on lines +10 to +13
enum AppEnvironment {
case mock
case production
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

debugrelease가 아닌 mockproduction으로 설정하신 이유가 있을까요?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DI 자체에 대해서, debug이어도 Mock으로 앱을 실행할 수도 있고, 실제 객체로 앱을 실행할 수도 있기 때문에 혼동이 올 수 있을거라 판단했습니다.
그래서 아예 네이밍을 직관적으로 mock 혹은 production으로 명칭하였습니다.

Comment on lines +10 to +15
enum UpdateRequirement {
case none
case optional
case frequent
case force
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@github-project-automation github-project-automation bot moved this to In Review in Wable-iOS May 30, 2025
@JinUng41 JinUng41 merged commit 095a341 into develop May 30, 2025
1 check passed
@github-project-automation github-project-automation bot moved this from In Review to Done in Wable-iOS May 30, 2025
@JinUng41 JinUng41 deleted the fix/#214-qa-final branch May 30, 2025 22:56
youz2me pushed a commit that referenced this pull request Oct 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🍻 진웅 술 한잔 가온나~ 🛠️ fix 기능적 버그나 오류 해결 시 사용

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

[Fix] 최종 QA 반영

3 participants