손영준 Assignment3 제출 #64
Conversation
…tax errors with HTTP communication.
| override fun onItemClick(itemId: Int) { | ||
| // 클릭한 아이템의 ID를 사용하여 필요한 동작 수행 | ||
| // 예: 상세 화면으로 전환하면서 ID를 전달 | ||
| val intent = Intent(this, DetailActivity::class.java) | ||
| intent.putExtra("itemId", itemId) | ||
| startActivity(intent) | ||
| } |
There was a problem hiding this comment.
인터페이스 👍
하지만 어댑터에게 람다를 전달하는 방법으로 더 간단하게 구현할 수 있습니다.
| viewModel.wordListInfoData.observe(this@MainActivity) { wordListInfo -> | ||
| // LiveData를 관찰하여 데이터를 얻고, adapter를 업데이트 | ||
| Log.d("DetailActivity", "Word list size: ${wordListInfo.size}") // 디버그 로그 추가 | ||
| adapter.setItems(wordListInfo) |
| val fetchedList: Pair<MainRepository.Signs, Any?> = repository.getWordListInfo() | ||
| val sign = fetchedList.first | ||
| val responseValue = fetchedList.second |
There was a problem hiding this comment.
꿀팁)
val (sign, responseValue) = repository.getWordListInfo()
| enum class Signs { | ||
| SUCCESS, | ||
| FAILURE, | ||
| EXCEPTION | ||
| } |
There was a problem hiding this comment.
이렇게 별도로 래핑하는 구조도 나쁘지 않아 보이지만 일반적인 방식은 아닙니다.
왜냐면 굳이 sign을 Pair로 붙여서 return하지 않더라도, Exception이 발생하지 않았으면면 SUCCESS이고 Exception이 발생했으면 FAILURE 또는 EXCEPTION 라고 알 수 있기 때문이죠. 그리고 Exception의 type을 통해 FAILURE(40X, 50X를 의미하신 거겠죠?)과 EXCEPTION도 구분할 수 있습니다.
|
|
||
| suspend fun verifyPassword(id: Int, password: String): Pair<Signs, Any?> { | ||
| return proceedException(api.verifyPermission(id, MyData.PasswordJSON(password))) | ||
| // 왜 잘못 입력했는데 200이 뜨지... |
There was a problem hiding this comment.
dagger hilt로 Repository는 보통 이런 식으로 만듭니다.
https://stackoverflow.com/questions/64820394/using-dagger-hilt-in-repository-class
| android:id="@+id/input_password" | ||
| android:layout_width="match_parent" | ||
| android:layout_height="wrap_content" | ||
| android:inputType="textPassword" |
| if (result != "SUCCESS") { | ||
| Toast.makeText(this@DetailActivity, result, Toast.LENGTH_SHORT).show() | ||
| } |
| // 요청 성공 시 메인화면으로 <- 요청 성공/실패 체크] | ||
| val intent = Intent(this@DetailActivity, MainActivity::class.java) | ||
| startActivity(intent) |
There was a problem hiding this comment.
이렇게 하면 메인화면으로 "되돌아가는 것" 이 아니라, MainActivity화면을 새로 만들어서 위에 쌓는 구조가 됩니다. (단어장 삭제하고 나서 뒤로가기를 눌러보면, 스택처럼 두 개의 MainActivity가 쌓여있는 것을 볼 수 있습니다)
그래서 삭제를 했을 때 MainActivity가 그걸 activityResultListener로 전달받은 게 아니라 (챌린지 스펙의 내용), 그냥 새 MainActivitty가 떠서 다시 fetch list를 한 상황입니다.
|
|
||
|
|
||
| } | ||
| // Dialog abstract class를 만들어도 될듯...? itemId와 Binding 받아서... |
There was a problem hiding this comment.
좋은 생각입니다
Dialog를 상속해서 자신의 앱에서 쭉 사용할 커스텀 다이얼로그를 만들어서 사용하는 게 일반적입니다. 레이아웃을 설정하고, 등장/퇴장 및 애니메이션까지 커스텀해서 사용하면 편하죠
최소 스펙 완료했습니다.
모범 답안이 나오기 전까지 추가 스펙, 챌린지 스펙 + 디자인에 도전해보겠습니다.