[1.1.0/AN-FEAT] 인앱 업데이트 기능 구현 #358
Conversation
| } | ||
| } | ||
|
|
||
| private fun checkForAppUpdate(info: AppUpdateInfo): Boolean { |
There was a problem hiding this comment.
boolean 을 리턴하는데 메서드 네이밍이 checkFor 로 시작해요.
저희 컨벤션에 맞지 않아요.
appUpdateIsEnabled 등으로 메서드 네이밍을 빌더로 해야 합니다.
There was a problem hiding this comment.
저는 이런 경우 should 라는 prefix를 선호합니다! 이유는 Android api 가 해당 네이밍을 많이 써서에요 ㅎㅎ
shouldAppUpdate() 어떠신가요??
근데 이건 동사인가..?
There was a problem hiding this comment.
shouldAppUpdate() Boolean 이라 이것도 괜찮을 듯?
There was a problem hiding this comment.
boolean 을 리턴하는데 메서드 네이밍이 checkFor 로 시작해요.
저희 컨벤션에 맞지 않아요.
헉쓰 그렇네요~
Android api 가 해당 네이밍을 많이 써서에요 ㅎㅎ
shouldAppUpdate()로 변경하겠습니다~~
| private val context: Context, | ||
| ) { | ||
| private val appUpdateManager: AppUpdateManager = AppUpdateManagerFactory.create(context) | ||
| private val updateType = AppUpdateType.FLEXIBLE |
There was a problem hiding this comment.
정말 개인적으로 이건 변수로 따로 안 빼는게 좋아 보입니다.
아래 있는 checkForAppUpdate 함수의
val isUpdateAllowed = info.isUpdateTypeAllowed(updateType)
👇
val isUpdateAllowed = info.isUpdateTypeAllowed(AppUpdateType.FLEXIBLE)
이게 더 빨리 읽힘 ㅎ
근데 사소해
There was a problem hiding this comment.
저도 동의합니다! 중복이 되긴하지만 지역 변수로 만들거나 그대로 사용하는게 더 잘 읽히는 것 같네요 ㅋㅅㅋ
There was a problem hiding this comment.
변수로 뺀 이유는, UpdateManager에서 updateType은 가장 중요하다고 생각해서 뺏습니다 !
만약 업데이트 타입을 바꾸기 위해서 해당 클래스로 들어왔을 때, checkForAppUpdate()를 찾는 번거로움도 있을 것 같기도 하고~
|
|
||
| InstallStatus.DOWNLOADED -> { | ||
| Timber.i("Update installed successfully") | ||
| appUpdateManager.completeUpdate() |
There was a problem hiding this comment.
다운로드 완료되면 플레이스토어 들어가져서 설치하고 재시작됩니다 !
an.feat._.webm
There was a problem hiding this comment.
앱을 사용자가 안받으면 어떻게 할지 로직을 안세웠어요 -> 같이 이야기 해봐야할 듯?? 서버에서 하위호환성을 구현해주면 필요 없을 것 같긴함
이게 이해가 잘 안됩니당. 사용자가 업데이트 거절하면 어떻게할지를 얘기하는 걸까요?
현재 업데이트 되는 화면이 HomeActivity에서 업데이트를 진행하고 있습니다. 보통 의견이 시작화면(HomeActivity)과 스플래시화면에서 업데이트를 유도하는 것 같아요 !
저는 Intro 에서 하면 좋을듯합니다!
이유는 그게 좀 더 자연스러운 것 같긴해서?? 하지만 상관없어용
아 ! 그리고 업데이트 하도록 호출하는 api가 횟수가 정해져있어서 반복적으로 호출하면 안뜰수도 있다고 합니다. (몇번인지는 나도 모름)
사용자가 취소하면 그냥 다음 버전 업데이트될 때까지 안뜨도록 해야할 것 같아요!
자꾸 뜨면 저는 화가 나더라구요 ㅋㅋㅋ
위와 비슷하게 앱 다운로드 중 실패한다면, 어떻게 되도록 해야할지도 의견을 물어보고 싶어요.
토스트 메세지??
| app-update = { module = "com.google.android.play:app-update", version.ref = "app-update" } | ||
| app-update-ktx = { module = "com.google.android.play:app-update-ktx", version.ref = "app-update" } |
There was a problem hiding this comment.
뭔가 ktx 만 추가해도 될 것 같다는 느낌?? 아닌가욥?
There was a problem hiding this comment.
그러게요 코틀린 환경에서만 사용하는거면 ktx만 추가해도 되는군요 !
app-update는 삭제했습니다~
| } | ||
| } | ||
|
|
||
| private fun checkForAppUpdate(info: AppUpdateInfo): Boolean { |
There was a problem hiding this comment.
저는 이런 경우 should 라는 prefix를 선호합니다! 이유는 Android api 가 해당 네이밍을 많이 써서에요 ㅎㅎ
shouldAppUpdate() 어떠신가요??
근데 이건 동사인가..?
| private val context: Context, | ||
| ) { | ||
| private val appUpdateManager: AppUpdateManager = AppUpdateManagerFactory.create(context) | ||
| private val updateType = AppUpdateType.FLEXIBLE |
There was a problem hiding this comment.
저도 동의합니다! 중복이 되긴하지만 지역 변수로 만들거나 그대로 사용하는게 더 잘 읽히는 것 같네요 ㅋㅅㅋ
| updateManager.unregisterInstallStateUpdateListener() | ||
| } | ||
|
|
||
| private fun initUpdateManager() { | ||
| updateManager = UpdateManager(applicationContext) | ||
| updateManager.registerInstallStateUpdateListener() |
There was a problem hiding this comment.
별건 아니긴하지만 레벨 4에서배운 DefaultLifecycleObserver 를 활용한다면 �액티비티의 생명주기에 맞게 알아서 register/unregister 해줄 수 있을 것 같아요!
There was a problem hiding this comment.
옹 좋은데요 ??? 👍👍
DefaultLifecycleObserver를 활용해서 리스너 관리 할게요
|
/noti 인앱 업데이트 내일 오프에서 간단하게 |
작업한 내용
an.feat.webm
PR 포인트
앱을 사용자가 안받으면 어떻게 할지 로직을 안세웠어요 -> 같이 이야기 해봐야할 듯?? 서버에서 하위호환성을 구현해주면 필요 없을 것 같긴함
위와 비슷하게 앱 다운로드 중 실패한다면, 어떻게 되도록 해야할지도 의견을 물어보고 싶어요.
현재 업데이트 되는 화면이 HomeActivity에서 업데이트를 진행하고 있습니다. 보통 의견이 시작화면(HomeActivity)과 스플래시화면에서 업데이트를 유도하는 것 같아요 !
splash vs home
아 ! 그리고 업데이트 하도록 호출하는 api가 횟수가 정해져있어서 반복적으로 호출하면 안뜰수도 있다고 합니다. (몇번인지는 나도 모름)
🚀Next Feature