본문 바로가기

전체 글

 (88)
[랜덤리즘] 로그인 구현 대작전 (수정) -3 지난번 포스팅 [랜덤리즘] 로그인 구현 대작전(구현) -2 일단 로그인을 구현하기 위해서는 아래의 2가지 상황이 있기 때문에 온보딩 페이지가 필요하다고 생각이 들었다. 1. 로그인을 하는 경우 2. 로그인을 하지 않는 경우 -> 둘러보기 로그인을 하지 w36495.tistory.com 로그인을 구현하는 포스팅 2편의 내용이 잘못되었음을 .. 알게되었다. 잘못되었다고 생각한 부분 LoginFragment 에서 HomeFragment 로 넘어올 때 UserRepository 에 데이터를 캐싱해보자! 해서 UserRepository 의 LiveData 에 데이터를 넣어주었었다. HomeFragment 에서 해당 LiveData 를 관찰자로 설정해주면, 그 값을 사용할 수 있지 않을까? 싶은 마음이었다. 그런데..
[객사오] 커피 구매를 위한 프로그램 업그레이드하기 객체지향의 사실과 오해의 5장을 읽었고, 마찬가지로 '커피 구매' 프로그램에 적용해보려고 한다. 책을 읽는동안에 작성했던 코드에서 달라지는 부분이 어디일지 궁금해서 엉덩이 들썩들썩였다 ㅋㅋㅋㅋㅋ 이번 5장에서 중요한 부분은 객체의 외부/내부를 분명히 하는 것! 이전 포스팅 [객사오] 커피 구매를 위한 프로그램에 적용해보기 어렴풋이 알고만 있던 객체지향에 대해서 공부해보고자 유명한 '객체지향의 사실과 오해' 책을 구매하였다. 사실 유튜브에서 객체지향 관련해서 영상(링크)을 보게되었는데 중간까지보다가 개 w36495.tistory.com 인터페이스 수정 // 수정 전 interface Customer { var money: Int fun buyCoffee() } interface Cashier { val m..
[객사오] 커피 구매를 위한 프로그램에 적용해보기 어렴풋이 알고만 있던 객체지향에 대해서 공부해보고자 유명한 '객체지향의 사실과 오해' 책을 구매하였다. 사실 유튜브에서 객체지향 관련해서 영상(링크)을 보게되었는데 중간까지보다가 개념을 알고있어야겠다싶은 마음에 구매했다. 현재 4장까지 읽었고, 책에 나와있는 설계 순서를 지키며 나만의 예제를 만들어보고자 했다. 협력 / 메시지 / 역할 협력(목표) 손님이 커피를 구매한다. 메시지(행동) 역할(추상화) 고객, 캐셔, 바리스타는 어느 누구가 담당해도 괜찮기 때문에 공동 인터페이스로 작성했다. 코드 작성 interface Customer { var money: Int fun buyCoffee() } interface Cashier { val menus: Map fun showMenu() fun serveCof..
[랜덤리즘] 로그인 구현 대작전(구현) -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개 + 새로 만든 기능까지하면 유스케이스가 너무 많아지는데 이 코드가 똑같다는 점이 문제...다 .. 똑같은 코드인데 계속해서 새로 만들어 ..? 이건 아닌 것 같아서 수정해야겠다고 생각했다. 데이터 흐름 (리팩토링 전) 리팩토링하기 전의 데이터 흐름을 나타내면 아래와 같다. 리팩토링을 해야겠다고 생각하게 된 계기 기존에 있던 태그(알고리즘), 레벨을 통해서 가져오는 것 외에도 문제를 가져오는 경우가 추가적으로 더 생겼기 때문이다. (안그래도 중복되..

티스토리툴바