Android/랜덤리즘 (13) 썸네일형 리스트형 [랜덤리즘] 로그인 구현 대작전 (수정) -3 지난번 포스팅 [랜덤리즘] 로그인 구현 대작전(구현) -2 일단 로그인을 구현하기 위해서는 아래의 2가지 상황이 있기 때문에 온보딩 페이지가 필요하다고 생각이 들었다. 1. 로그인을 하는 경우 2. 로그인을 하지 않는 경우 -> 둘러보기 로그인을 하지 w36495.tistory.com 로그인을 구현하는 포스팅 2편의 내용이 잘못되었음을 .. 알게되었다. 잘못되었다고 생각한 부분 LoginFragment 에서 HomeFragment 로 넘어올 때 UserRepository 에 데이터를 캐싱해보자! 해서 UserRepository 의 LiveData 에 데이터를 넣어주었었다. HomeFragment 에서 해당 LiveData 를 관찰자로 설정해주면, 그 값을 사용할 수 있지 않을까? 싶은 마음이었다. 그런데.. [랜덤리즘] 로그인 구현 대작전(구현) -2 일단 로그인을 구현하기 위해서는 아래의 2가지 상황이 있기 때문에 온보딩 페이지가 필요하다고 생각이 들었다. 1. 로그인을 하는 경우 2. 로그인을 하지 않는 경우 -> 둘러보기 로그인을 하지 않는 경우(2번)는 기존에 만들었던 화면으로 이동시켜주었다. 기능을 구현한 순서대로 차근차근 작성해보자고 .. 레스고 .. 아! 그리고 현재 repository에서 LiveData를 사용하고 있는데, LiveData를 사용하는 것이 안좋다는 포스팅을 본 것 같아서 왜 사용하면 안되는지에 대해서 알아 볼 필요가 있을 것 같다. (LiveData 대신 Flow 사용하는 것이 좋다고 함) LiveData 를 사용한 이유는 ViewModel 에서 LiveData 를 사용했기때문에 자연스레 repository 의 변수에도 .. [랜덤리즘] 로그인 구현 대작전 -1 지금까지는 사용자가 풀지 않았거나 풀었거나의 여부와는 상관없이 문제를 보여주었다. 사용자가 풀었던 문제는 보여주지 않고 풀지 않았던 문제들을 보여주기 위해서는 로그인 기능이 필요하게 되었다. 그래서 작성하는 로그인 구현 대작전! 솔브드에서의 로그인은 솔브드에서 로그인 버튼을 누르게 되면 백준 온라인 저지 사이트로 이동한다. 백준 사이트에서 로그인이 완료되어 솔브드로 연동된다는 버튼을 클릭하게 되면, 솔브드에서의 로그인 과정이 성공적으로 끝난다. 그렇다면 솔브드의 api를 사용하는 나는 어떻게 로그인을 구현해야 할까? 가장 먼저 생각한 것은 랜덤리즘에서도 로그인 버튼을 클릭하면 솔브드처럼 로그인의 과정을 거치는 것이다. 근데 생각해보라 ... 그렇다면 사용자는 랜덤리즘 .. 솔브드 .. 백준 .. 의 과정.. [랜덤리즘] Fragment와 ViewModel의 책임을 명확하게 하기 현재 랜덤리즘은 위와 같은 흐름으로 되어있다! 각각의 Fragment 에서 ProblemFragment 로 화면이 전환될 때 네트워크 통신할 때 필요한 소스를 ProblemFragment 의 newInstance 메서드를 통해 arguments 로 전달해주고 있었다. // ProblemFragment.kt fun newInstance(tag: String, value: T): Fragment { return ProblemFragment().apply { arguments = Bundle().putValue(tag, value) } } 아래의 코드는 TagFragment 에서 ProblemFragment 의 newInstance 를 통해 화면을 전환하는 코드이다. // TagFragment.kt paren.. [랜덤리즘] 예외 처리하기, 다이얼로그보다 사용자에게 선택권을 주기 흔한 알고리즘에 대해서는 문제가 많았지만, 덱, 연결 리스트와 같이 100개 미만의 문제를 가진 알고리즘이 많다는 것을 알게되었다. 문제 수가 많은 알고리즘에 대해서만 클릭해보고 기능이 잘 되는지 확인을 해보았기때문에 뒤늦게 알게된 것이겠지 .. 싶다.. 마주한 문제 위의 사진과 같이 덱 알고리즘에서 브론즈에 해당되는 문제는 존재하지 않았다. 네트워크 통신에서는 200으로 성공이었지만, 왜 문제가 보이지 않을까? 해서 주소로 접속해보았다. 일단 결과가 보내졌기 때문에 200으로 성공이 떴지만, 그 속의 내용은 문제가 존재하지 않는다는 count : 0 이 있었다! count가 0인 경우에 대한 예외처리가 필요하구나를 알게되었다. 해결을 위해 생각한 방법 [1] count 가 0으로 전달되었을 때, 다이얼.. [랜덤리즘] 중복된 코드를 1개의 코드로 리팩토링하기 현재 중심이 되는 부분이 문제를 나타낼 수 있는, 문제와 관련있는 파일들이다. 가장 처음에 태그(알고리즘)랑 레벨을 통해서만 문제를 가져왔기 때문에 유스케이스를 GetProblemsByTag, GetProblemsByLevel 2개로만 만들었었다. 그런데 2개 + 새로 만든 기능까지하면 유스케이스가 너무 많아지는데 이 코드가 똑같다는 점이 문제...다 .. 똑같은 코드인데 계속해서 새로 만들어 ..? 이건 아닌 것 같아서 수정해야겠다고 생각했다. 데이터 흐름 (리팩토링 전) 리팩토링하기 전의 데이터 흐름을 나타내면 아래와 같다. 리팩토링을 해야겠다고 생각하게 된 계기 기존에 있던 태그(알고리즘), 레벨을 통해서 가져오는 것 외에도 문제를 가져오는 경우가 추가적으로 더 생겼기 때문이다. (안그래도 중복되.. [랜덤리즘] 설정화면에서 변경한 값을 다른 화면에서 사용해도 될까? 지난번 포스팅에서 2가지 의문점을 가졌었는데, 그 중 2번째 의문점에 대해서 작성해보려고 한다. 지난번 의문점은 위의 사진을 보면 알 수 있다. 포스팅은 여기! [랜덤리즘] 관련 알고리즘 보이기/숨기기 기능 개발하기 -2 SharedPreferences vs DataStore 처음에는 SharedPreferences 를 사용해서 데이터를 저장하려고 했는데, 공식문서에서 SharedPreferences 를 사용하는 것 보다는 DataStore 를 사용하는 것을 추천한다고 해서 SharedPrefer w36495.tistory.com 상황 설명 설정 화면에서 변경한 '관련 알고리즘 보이기/숨기기'의 값에 따라 문제 화면에서도 해당 부분이 보여져야한다! 그렇다면 문제 화면에서 해당 설정 값을 가져오려면 Set.. [랜덤리즘] 관련 알고리즘 보이기/숨기기 기능 개발하기 -2 SharedPreferences vs DataStore 처음에는 SharedPreferences 를 사용해서 데이터를 저장하려고 했는데, 공식문서에서 SharedPreferences 를 사용하는 것 보다는 DataStore 를 사용하는 것을 추천한다고 해서 SharedPreferences 대신 DataStore 를 사용하였다. 가장 처음 한 일은 만들려는 기능(관련 알고리즘 보이기/숨기기)이 어느 부분에 영향을 주는지를 알아보았다. 1) 현재 프로젝트의 구조 그려보기 현재 랜덤리즘의 구조를 간단히 그려보았을 때, 위의 사진과 같았다. 여기서 SettingFragment 을 통해 변경된 값이 Problem/SettingFragment 의 화면에 보여야하므로, 2개의 화면이 변경된 값에 영향을 받는 다는 것.. 이전 1 2 다음
