Week3 ‐ 멘토링

AOS

질답내용

• Q. 커스텀 뷰가 뷰모델을 가져도 되는지

  • 커스텀 뷰가 기능이 많고, 중요한 컴포넌트면 가져도 상관없음
  • 하지만 사실 커스텀뷰는 뷰모델을 가지고 있어도 라이프 사이클은 액티비티에 연결되어 있음
  • 그래서 이 부분을 고민하면서 사용하면 좋을 것 같음
  • ViewModel의 onCleared 호출 시점을 명확하게 알면 이런 걱정을 안해도 될 것 같음
    • ViewModel의 라이프 사이클에 대해 다시 공부해보기

• Q. 클래스에서 컨텍스트를 주입받는게 올바른 방향일지

  • 컨텍스트는 Activity나 Fragment에 의한 거기 때문에 메모리 릭이 날 수가 있음
  • 그래서 조심해서 사용해야함,
  • 혹시 Application Context로 대체할 수 있을지?
    • ⇒ Q. Application Context로 대체하면 어떤점이 더 좋은가요?
  • 일반 context로 하면, 예를들어 A Activity의 context를 전달받았는데 B Activity에서 그걸 사용하고 있고, 그 상태에서 A Activity가 destroy 되면 앱이 죽게 됨.
  • 근데 Application context로 사용하면 그런 걱정 안해도 됨
  • ⇒ Q. 그래도 Application context는 너무 큰걸 알고있는거 아닐까요?
  • fragment 의 context를 알고 있을 때 안전하면 사용해도 되는데, 그럼 관리가 어려움.
  • 화면이 여러개가 됐을 때 어느 부분에서 메모리릭이 일어날 지 모르니까 사용하지 말라고 하는 편임.
  • 그렇지만 관리가 가능하다면 사용해도 됨

• Q. 노드가 추가/삭제 될 때 애니메이션을 넣고 싶은데 페인트로 직접 구현하는 게 맞을까요? 코루틴도 같이 사용해야 할 것 같은데 이런 방향이 맞을지 궁금합니다

  • 일단 코루틴은 효율을 위해 사용하는 비동기이니 지금 이건 코루틴으로 구현 안해도 됨
  • 커스텀 애니메이션을 만들면 될듯 → 키워드 : alpha animation
  • ⇒ Q. object animator를 사용하면 될까요?
  • 넵 object animator 또는
  • 뷰 자체에도 애니메이션 메소드가 있어서 그걸 이용해서 구현해도 될 것 같아요
  • 근데 이건 paint에 animation을 넣어야 해서 아마 invalidate를 호출해야 될 수도 있을 것 같아요 → 키워드 : android alpha animation in canvas

• Q. 상속 구조를 sealed 클래스로 했는데, 상속 받는게 모두 data class인데도 매번 카피를 해주기 위해서 when을 이용해 타입 캐스팅을 해줘야하는게 불편합니다.. 현업에서도 이런 방법을 쓰나요? 다른 좋은 방법이 있을까요?

  sealed class A {
      data class B(
          val name: String
      ) : A {
          companion object {
              fun of(
                  name: String
              ) = B(name)
          }
      }
  }
  B.of("홍길동")

  • 이렇게 구현하시는 것도 괜찮아요!

• Q. 현업에서 CI를 어디까지 자동화하는지 궁금합니다

  • 회사마다 다르고, ci/cd가 잘 되어 있는 회사일수록 더 여러가지가 자동화 되어 있을 거에요
  • 예를 들어서 저희 회사같은 경우는 ktlint 뿐만 아니라 테스트 코드 빌드, png 같은 이미지는 용량이 크니까 그런걸 줄여주는 액션 같은게 되어 있는데 지금 하시는 프로젝트에서는 ktlint만 하셔도 충분하다고 생각해요
  • 대신 ci/cid가 왜 필요한지 이해를 하시고, 액션을 한가지라도 경험을 해보시는게 중요하다고 생각해요

• Q. 다음주부터 실시간 공동 작업을 구현할 것 같습니다. 구현할 때 고려하거나 주의해야할 사항이 있을 까요?

  • 소켓 통신의 경우에는 백엔드분들과 어떤 값을 주고받을지 얘기를 하는게 좋은 것 같음
  • 소켓을 언제 연결하고, 언제 끊을지, 언제 재연결할지
  • 소켓을 이용하는 걸 하나의 lifecycler이라고 생각하고 구현하면 좋을 것 같음
  • 만나서 하면 더 좋을듯!! 얘기나 대화를 나눠야하는게 많은데,
  • 그리고 백엔드에서 소켓 쓸 때, 직접 라이브러리 안쓰고 구현해 본 다음에 라이브러리르 써보는게 “왜 안되지?” 라는거에 오히려 빠르게 될지도

BE

• Q. 여러 개로 정해진 타입에 대응하는 클래스를 만들고 싶은데, 제네릭 타입으로 만들면 어떤 타입이 들어와도 된다는 느낌입니다. 들어올 수 있는 타입은 여러 개가 가능한데, 정해진 타입만 들어오게 할 수 있을까요??

  class PersonExtends<T extends String | Number> { // string, number만 가능
    private _name: T;
  
    constructor(name: T) {
      this._name = name;
    }
  }
  
  new PersonExtends("Mark");
  new PersonExtends(39);
  
  typeof A == "String"

• Q. 캐시 서버의 필요성

  • 캐시 서버는 본 서버로 가기 전에 캐시 서버에서 빠르게 찾아서 보낼 수 있도록 하기 위해서 쓰는것
  • 즉 캐시서버에서 들고있는 메모리가 DB에서 읽어오는 속도보다 현저하게 빠르게 해야함

• Q. 트리

  • 트리 아이디보다는 노드 아이디로 하는 것도 나쁘지 않을 것 같다.
  • ms로도 같은 시간에 DB에 들어갈 수 있음.
  • 그래서 좀 더 디테일하게 겹치지 않는걸 생각해보는 것도 나쁘지 않음

기타

• Node ID를 UUID로 클라이언트에서 만들고 있는데, 중복되지 않을까 걱정됩니다.
  • UUID 중복 걱정은 안해도 됨
  • 다만 클라이언트에서 ID 관련 작업은 안하는게 좋음. 빠르게 하기위해서 클라이언트에서 만든다고 하셨는데, 차라리 블러처리된 / 투명한 임시처리뷰를 보여주거나, 로딩을 띄워주는게 좋음.
• 개발자 쪽에서는 실패를 하면 그걸 큰일로 생각하는 경우가 많은데, 안그래도 됨. 사실 실패가 떴을 때 사용자가 재요청 할 수 있게만 해주면 괜찮음.
  • 예를 들어 결제를 하다가 실패해도 왜 실패했는지, 그리고 다시 할 수 있게만 해주면 사실 사용자는 별로 불편이 없음.
  • 이런게 UX 적인 부분인데, 속도를 단순히 빨리 하려고 하는것보다 이런쪽에 대해서도 고민해보면 좋을 것 같음.
• 그리고 화면 오리엔테이션 바꾸면 액티비티가 죽었다가 다시 재생성 되잖아요, 이럴 때 데이터 관리를 어떻게 해서 다시 화면을 유지시킬건지에 대해서도 고민해보시면 좋을 것 같아요.
  • Q. ViewModel 쓰면 되는거 아닌가요?
  • 그 문제는 한번 해보면 아실거에요..ㅎㅎ
• Jetpack compose 현업에서 많이 쓰나요?
  • 사실 많이는 안쓰는 것 같다.. 그래서 xml을 제대로 공부하는게 더 도움이 될 것 같아요
• 추가로 말씀을 드리자면,
  • 신기술은 검증이 안됐어요. 그래서 라이브러리를 쓸 때 0 버전은 절대 안쓰고, 써도 1 버전 이상을 써요.
  • 검증이 안된 라이브러리를 사용하면 그 라이브러리에 문제가 있으면 그 라이브러리를 직접 고쳐야하는데, 그러기보단 검증된걸 쓰는거죠.
    • 그래서 아직 자바 버전 8 쓰는 곳도 있어요.
• 그리고 어떤 아키텍처 패턴이 왜 나왔는지 이런것도 알아두시면 좋을 것 같아요.