[UI] 러닝 활동 저장하기

[slr-09]

연관된 이슈를 적어주세요 📌

• ✨ Feature: 달리기 공통 #34

작업한 내용을 설명해주세요 ✔️

• 팝업 modifier 생성
• 러닝 끝내기 팝업 & 활동 삭제하기 팝업 추가
• 활동 저장하기 페이지 (지도 이미지 제외)
• 내 활동 페이지 (지도 & 구간별 페이스 제외)

실행 화면

RPReplay_Final1729606650.MP4

발생한 이슈

• 팝업 창과 내 활동(RunningPost.swift) 페이지에 러닝 정보의 단위는 아직 디자인대로 적용하지 않았어요
• 활동 저장하기 (FinishRunningPage.swift)에서 키보드 내리기를 Focused로 구현을 했는데 어째서인지 주변 다른 곳을 탭하면 키보드가 내려가는게 아니라 TextEditor를 탭해야 내려가더라고요 😅

<popup modifier 사용법>

.popup(
  isPresented: Binding<Bool>, 
  title: String, 
  buttonText: String, // 우측 버튼 Text (아래 이미지에서는 '끝내기')
  buttonColor: Color, // 우측 버튼 색 
  cancelAction: {}, // 취소 눌렀을 때 Action 처리
  buttonAction: {}) // 우측 버튼 눌렀을 때 Action 처리 

[ParkSeongGeun]

고생하셨습니다 👍

[ParkSeongGeun]

1. mapVM을 전달하면서 내부에 전언된 motionManager를 전달할 필요가 있나요?
2. RunningMapPage로 이동 시에 너무 많은 인자가 생성시에 전달되는 거 같습니다. 줄일 수 있는 방법이 없을까요?

[slr-09]

1. 내부에서 motionManager에 있는 러닝 정보를 motionManager.runningInfo.runningTime와 같이 사용하고 있는데 mapVM으로 사용하게 되면 mapVM.motionManager.runningInfo.runningTime처럼 코드가 너무 길어지며 가독성이 떨어지는 것 같아 이런 방법을 택했습니다 .. mapVM만 전달하는 것이 나을까요 ??

2. 알려주신 DIContainer를 알아보고 적용을 시도하려고 합니다.
   추가로 Navigation 관리를 NavigationPath를 사용하고 싶었는데 구현이 잘 되지 않는 이슈가 있었습니다. NavigationStack 관리를 조금 더 간편하게 할 수 있다면 전달하는 인자를 줄일 수 있을 것 같습니다.

[ParkSeongGeun]

1. 엇, 저도 모든 코드를 본 게 아니라 그런 사용 처가 있었군요... 다만 처음 보는 입장이라면(제 개인적) 둘의 차이가 크진 않을 거 같습니다. (둘다 길다는 건 문제가 되지만...)

• runningInfo.runningTime은 데이터에 직접적인 접근이다보니 MotionManager에서

extension MotionManager {
    func getRunningTime() -> 시간{ ... }
    func getLocation() -> 위치 { ... }
}

와 같이 메서드의 반환값으로도 받을 수 있지 않을까요?

[slr-09]

좋은 방법인 것 같습니다! 수정해보도록 할게요 : )

[ParkSeongGeun]

권장사항이긴 합니다만,

하나의 뷰 Struct에서 [레이아웃 컨테이너](https://developer.apple.com/documentation/swiftui/layout-fundamentals)(VStack, HStack, ZStack, Grid 등)는 최대 1개까지만 사용하는 것을 권장합니다.

레이아웃 컨테이너를 2개 이상 겹치게 되면 배치의 방향성이 일관되지 않게 되므로 코드의 가독성이 매우 떨어집니다. 각 배치 방향이 무엇을 의미하는지 이름을 결정해두면 가독성이 더 좋아집니다.
레이아웃 컨테이너는 남발되기 매우 쉽습니다. 레이아웃 컨테이너를 기준으로 뷰를 분리하는 과정에서 불필요한 레이아웃 컨테이너를 발견할 확률을 높일 수 있습니다.

아래 링크를 참고하였습니다.

https://github.com/DeveloperAcademy-POSTECH/swift-style-guide?tab=readme-ov-file#View-%EC%84%A0%EC%96%B8-%EB%B0%A9%EB%B2%95

[slr-09]

혹시 GeometryReader와 VStack을 말하는 것일까요?
아니면 VStack 내부의 것들을 말씀하신건가요?

저는 내부 뷰를 struct로 따로 구현하는 것은 재사용이 필요할 때만 사용하고 그 외의 경우에는 복잡한 뷰를 구현할수록 여러 레이아웃 컨테이너를 사용할 수 밖에 없다고 생각합니다. 따라서 이런 경우에는 주석을 작성하는 편입니다.

[ParkSeongGeun]

(사실 위 커멘트도 권장사항이라 프젝 컨벤션 나름인 것 같습니다)

• 다만 유저정보, 완료한 러닝 정보, 지도 이미지, 구간별 페이스를 하나의 GeometryReader에서 선언할 필요가 있을까 라는 논점이었습니다.
• @ViewBuilder 혹은 struct로 각 세부 Feature UI를 보여주는 것이 가독성 측면에서 좋지 않을까요? (이건 제 개인적 + 주변 개발자분들의 의견입니다.)

var body: __ {
    GeometryReader { ...
          userProfie()
          // title
          runningInfo() 
          map...()
          pace..()
     }
}

@ViewBuilder
func userProfile() .... {

}

@ViewBuilder
runningInfo

이와 같은 방법은 어떤가 였습니다!

[slr-09]

그런 방법은 가독성이 더 좋을 것 같긴 합니다만,

• 매개변수로 전달해야 할 인자들이 무조건 있는 경우
• 몇 줄 이상부터 분리하는 것이 좋은지 (위 코드의 title은 2줄)

위와 같은 경우에는 어떻게 해야할지 또 고민이 되는 것 같아요 ..

[ParkSeongGeun]

type: runningType == .alone ? ["개요", "지도"] : ["개요", "지도", "그룹원"]

-> String 리터럴을 직접 코드에 하드코딩하는 것은 좋지 않은 방식 같습니다.

[slr-09]

계산속성으로 변경했습니다!

[ParkSeongGeun]

Ditto.
(하나의 뷰 Struct에서 [레이아웃 컨테이너]는 최대 1개까지만 사용하는 것을 권장합니다.)