week2 - #15
Conversation
imminyoung
left a comment
There was a problem hiding this comment.
드디어 캐디 피드백을 할 수 있다니 너무 기분 좋네요~~
앞으로는 밀리지 않고 끝까지 완주해요~ 화이팅!!
2주차 워크북의 핵심 개념인 Activity와 Fragment의 차이는 안드로이드 코딩에서 가장 기본적인 내용이지만 그만큼 아주 중요한 내용입니다! 둘의 차이와 개념을 확실히 이해해야 적절한 화면 구성을 할 수 있거든요~
잘 이해하고 넘어가시면 좋겠습니다!
There was a problem hiding this comment.
지금 구조 자체는 문제 없지만, 최근에는 ConstraintLayout을 더 많이 사용하는 편입니다.
화면이 복잡해질수록 제약 조건으로 관리하는 쪽이 유지보수에 더 유리하기 때문에 초반 워크북 진행 시에도 ConstraintLayout 을 사용해주세요~
| android:layout_height="match_parent" | ||
| android:background="#FFFFFF"> | ||
|
|
||
| <LinearLayout |
There was a problem hiding this comment.
뷰에 id를 붙이는 습관을 들이면 좋을 것 같습니다.
지금은 화면 구성이 단순해서 크게 불편하지 않을 수 있지만, 이후 배치해야 할 뷰가 많아지면 각 뷰를 구분하고 연결하는 과정이 훨씬 복잡해질 수 있습니다.
그래서 필요할 때만 id를 붙이는 것보다, 처음부터 id를 명확하게 작성하는 습관을 들여두면 이후 유지보수나 기능 추가 시 훨씬 수월합니다.
imminyoung
left a comment
There was a problem hiding this comment.
캐디! 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는 관련된 데이터를 하나로 묶어서 관리하기 쉽게 해주는 클래스입니다. 예를 들어 상품 하나를 표현할 때 이름, 가격, 이미지, 좋아요 여부를 각각 따로 다루는 것보다 하나의 객체로 묶어두는 편이 훨씬 보기 쉽고 관리하기도 편합니다.
또 일반 클래스보다 코드가 간결하고, 값 비교나 복사도 쉽게 할 수 있어서 리스트를 다루거나 화면 간 데이터를 전달할 때도 유용합니다.
There was a problem hiding this comment.
위시리스트 탭과 구매하기 탭처럼 성격이 비슷한 화면에서 동일한 데이터 클래스를 사용하신 점이 좋았습니다. 공통되는 데이터를 하나의 모델로 관리하면 코드의 일관성을 유지하기 좋고, 이후 재사용이나 유지보수 측면에서도 훨씬 효율적입니다.
colours 필드는 현재 문자열로 관리하기보다 별도의 엔티티로 분리하는 쪽이 더 적절해 보입니다. 추후 색상 수 외에도 실제 색상값, 이름, 선택 여부 등의 정보가 추가될 수 있기 때문에, 처음부터 구조를 나누어두면 확장성과 유지보수 측면에서 더 유리합니다.
|
|
||
| // 1. 임시 데이터(더미 데이터) | ||
| val dummyList = listOf( | ||
| Product("Nike Everyday Plus Cushioned", "Training Ankle Socks (6 Pairs)\n%Colors", "US$10", R.drawable.socks1), |
There was a problem hiding this comment.
Product.kt 파일에서 말씀드렸던 것처럼, colours는 문자열이 아닌 별도의 엔티티로 관리하는 것이 더 적절해 보입니다. 이후 색상 관련 정보가 확장될 가능성을 고려하면, 구조를 분리해두는 편이 더 유연합니다.
|
|
||
| // 뷰 안의 요소들(TextView, ImageView 등)을 찾아두는 클래스 | ||
| class ProductViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) { | ||
| val image: ImageView = itemView.findViewById(R.id.item_image) |
There was a problem hiding this comment.
개인적으로는 ViewBinding을 사용하는 방향을 추천드립니다. findViewById()를 여러 번 호출하지 않아도 되어 코드가 더 간결해지고, 각 뷰를 보다 안전하고 직관적으로 사용할 수 있다는 장점이 있습니다. 관련 내용은 1주차 워크북에서 이미 다루었으니, 한 번 다시 참고해보셔도 좋을 것 같습니다.
📂 관련 이슈
🛠️ 작업 사항
📸 관련 이미지 (스크린샷 또는 동영상)
💬 기타 설명