Skip to content

week2 - #15

Open
happy-123123 wants to merge 2 commits into
mainfrom
caddy
Open

week2#15
happy-123123 wants to merge 2 commits into
mainfrom
caddy

Conversation

@happy-123123

Copy link
Copy Markdown
Contributor

📂 관련 이슈

  • closes #[이슈 번호]

🛠️ 작업 사항

  • [ ]
  • [ ]

📸 관련 이미지 (스크린샷 또는 동영상)


💬 기타 설명

💡 추가적으로 공유할 내용이나 리뷰어에게 전달할 사항이 있다면 작성해 주세요.

maerong added 2 commits March 30, 2026 22:46

@imminyoung imminyoung left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

드디어 캐디 피드백을 할 수 있다니 너무 기분 좋네요~~
앞으로는 밀리지 않고 끝까지 완주해요~ 화이팅!!

2주차 워크북의 핵심 개념인 Activity와 Fragment의 차이는 안드로이드 코딩에서 가장 기본적인 내용이지만 그만큼 아주 중요한 내용입니다! 둘의 차이와 개념을 확실히 이해해야 적절한 화면 구성을 할 수 있거든요~

잘 이해하고 넘어가시면 좋겠습니다!

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

지금 구조 자체는 문제 없지만, 최근에는 ConstraintLayout을 더 많이 사용하는 편입니다.

화면이 복잡해질수록 제약 조건으로 관리하는 쪽이 유지보수에 더 유리하기 때문에 초반 워크북 진행 시에도 ConstraintLayout 을 사용해주세요~

android:layout_height="match_parent"
android:background="#FFFFFF">

<LinearLayout

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

뷰에 id를 붙이는 습관을 들이면 좋을 것 같습니다.

지금은 화면 구성이 단순해서 크게 불편하지 않을 수 있지만, 이후 배치해야 할 뷰가 많아지면 각 뷰를 구분하고 연결하는 과정이 훨씬 복잡해질 수 있습니다.

그래서 필요할 때만 id를 붙이는 것보다, 처음부터 id를 명확하게 작성하는 습관을 들여두면 이후 유지보수나 기능 추가 시 훨씬 수월합니다.

@imminyoung imminyoung left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

캐디! 3주차도 수고 많으셨습니다.

리사이클러뷰는 앞으로도 자주 활용하게 되는 요소라 이번 주차에서 개념과 사용 흐름을 잘 잡아두는 것이 중요합니다. 특히 Adapter와 Fragment의 관계를 정확히 이해해두면, 이후 비슷한 형태의 화면을 구현할 때도 훨씬 안정적으로 코드를 작성할 수 있습니다!


공통 피드백

모르는 개념을 정리하거나 방향을 잡는 데 AI를 활용하는 것은 괜찮습니다. 다만 전체 코드를 그대로 받아오는 방식은 추천드리지 않습니다. 그렇게 하면 과제를 제출하는 데는 도움이 될 수 있어도, 결국 본인이 직접 이해하고 익힌 내용으로 남기 어렵기 때문입니다. 이번 10주 동안은 결과만 빠르게 만드는 것보다, 스스로 공부하고 구현해보는 과정을 통해 개념을 제대로 습득하는 데 집중해주시면 좋겠습니다.

데이터 저장 방법

US$15처럼 단위까지 포함한 문자열 형태로 데이터를 저장해두면, 이후 구매 로직이나 가격 계산이 필요할 때 숫자만 다시 분리해야 해서 다루기 번거로워질 수 있습니다.

productList=listOf(
ProductData(R.drawable.ic_socks1,"Nike Everyday Plus Cushioned","Training Ankle Socks (6 Pairs)","5","10",false,true,"전체"),
ProductData(R.drawable.ic_socks2,"Nike Elite Crew","Basketball Socks","7","16",false,false,"전체"),
ProductData(R.drawable.ic_airporce,"Nike Air Force 1 '07","Women's Shoes","5","115",true,false,"sale"),
ProductData(R.drawable.ic_airporce2,"Jordan ENike Air Force 1 '07sentials","Men's Shoes","2","115",true,false,"Tops & T-Shirts")
)

이처럼 Colours, US$처럼 반복적으로 붙는 표현은 데이터 자체에 포함하기보다, 화면에 바인딩하는 시점에 붙여주는 방식이 더 적절합니다.

funbind(product:ProductData) {
binding.ivProduct.setImageResource(product.imageResId)
binding.tvTitle.text=product.title
binding.tvSubTitle.text=product.subTitle
binding.tvPrice.text="US$${product.price}"
binding.tvColors.text="${product.colorText} Colours"
}

이렇게 분리해두면 데이터와 UI 표현 역할을 나눌 수 있고, 이후 값 가공이나 재사용도 훨씬 수월해집니다. 또한 동일한 형식을 한곳에서 관리할 수 있어 일관성 측면에서도 더 좋습니다.

개별 피드백

스터디 때 물어보셨던 질문에 대해 저도 다시 찾아봤는데요!

data class는 관련된 데이터를 하나로 묶어서 관리하기 쉽게 해주는 클래스입니다. 예를 들어 상품 하나를 표현할 때 이름, 가격, 이미지, 좋아요 여부를 각각 따로 다루는 것보다 하나의 객체로 묶어두는 편이 훨씬 보기 쉽고 관리하기도 편합니다.
또 일반 클래스보다 코드가 간결하고, 값 비교나 복사도 쉽게 할 수 있어서 리스트를 다루거나 화면 간 데이터를 전달할 때도 유용합니다.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

위시리스트 탭과 구매하기 탭처럼 성격이 비슷한 화면에서 동일한 데이터 클래스를 사용하신 점이 좋았습니다. 공통되는 데이터를 하나의 모델로 관리하면 코드의 일관성을 유지하기 좋고, 이후 재사용이나 유지보수 측면에서도 훨씬 효율적입니다.

colours 필드는 현재 문자열로 관리하기보다 별도의 엔티티로 분리하는 쪽이 더 적절해 보입니다. 추후 색상 수 외에도 실제 색상값, 이름, 선택 여부 등의 정보가 추가될 수 있기 때문에, 처음부터 구조를 나누어두면 확장성과 유지보수 측면에서 더 유리합니다.


// 1. 임시 데이터(더미 데이터)
val dummyList = listOf(
Product("Nike Everyday Plus Cushioned", "Training Ankle Socks (6 Pairs)\n%Colors", "US$10", R.drawable.socks1),

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Product.kt 파일에서 말씀드렸던 것처럼, colours는 문자열이 아닌 별도의 엔티티로 관리하는 것이 더 적절해 보입니다. 이후 색상 관련 정보가 확장될 가능성을 고려하면, 구조를 분리해두는 편이 더 유연합니다.


// 뷰 안의 요소들(TextView, ImageView 등)을 찾아두는 클래스
class ProductViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
val image: ImageView = itemView.findViewById(R.id.item_image)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

개인적으로는 ViewBinding을 사용하는 방향을 추천드립니다. findViewById()를 여러 번 호출하지 않아도 되어 코드가 더 간결해지고, 각 뷰를 보다 안전하고 직관적으로 사용할 수 있다는 장점이 있습니다. 관련 내용은 1주차 워크북에서 이미 다루었으니, 한 번 다시 참고해보셔도 좋을 것 같습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants