리액티브 프로그래밍과 옵저버 패턴 리액티브 프로그래밍 패러다임은 최근 프로그래밍 패러다임 중 가장 중요한 패러다임 중 하나이다. 리액티브 프로그래밍 패러다임이 유행하기 이전에는 명령형 프로그래밍 패러다임이 유행했다. 명령형 프로그래밍 패러다임 하에서는 데이터가 변할 때 데이터가 변화에 따라 데이터가 변해야 하는 부분에 모두 적용을 시켜줘야 했다. 리액티브 프로그래밍 패러다임은 데이터가 변하는 것을 관찰해서 데이터가 변할 때 동작을 변하도록 만드는 것을 기본으로 한다. 즉, 데이터에 반응(Reactive)하도록 코드를 만드는 것이다. 이렇게 하면 데이터가 변화할 때 변화가 필요한 부분에 변화를 관찰하도록 코드를 넣어주면 데이터가 변화했을 때 데이터 변화에 대한 변경 사항이 즉시 게시된다. 옵저버 패턴은 리..
분류 전체보기
블록이 실행되지 말아야 할 때의 Best Practice Kotlin에서는 if-else 문으로 코드 블록을 실행할지 결정한다. 하지만 if-else 문을 중첩해서 쓰면 블록이 계속 블록이 중첩되기 때문에 가독성이 떨어진다. 특히 오랫동안 유지보수된 레거시 코드들을 보면 이러한 상황이 매우 잘 나타난다. 보통 이러한 코드들은 null이 아님을 확인하기 위해 1번 if 문을 쓰는 것을 기본으로 한다. 예를 들어 다음 코드와 같이 사용된다. fun blockExecuteExample(apple : Apple?) { if (apple != null) { if(apple is Fruit) { eat() } } } 여기서 끝나면 괜찮겠지만 보통 이런 코드들은 if문을 여러 번 중첩한다. if 문을 여러 번 중첩하..
변수의 변경 가능 지점을 최소화 해야 하는 이유 프로그래밍을 하다보면, 이곳 저곳에서 변수의 값이 변화되는 것을 볼 수 있다. 코드의 양이 작을 때는 이런 것이 문제가 안되지만 코드의 양이 많아질 수록 문제가 된다. 특히 특정 클래스에 속한 변수가 외부에서 직접 접근된 다음 수정되면 해당 클래스 상태(State)의 변경 가능 지점이 늘어나기 때문에 문제가 생긴다. 예를 들어 ExampleView와 ExampleView의 데이터를 저장하는 ExampleViewModel이 있고 ExampleViewModel의 viewData는 서버에서 가져온다고 해보자. 이때 viewData는 초기화 시 한 번만 가져오고 이후에 바뀌면 안된다. 그러면 다음과 같이 코드가 만들어질 수 있다. class ExampleView(..
Shared Preferences와 Datastore Shared Preferences를 Datastore로 Migration 하기 위해서는 Datastore가 저장되는 공간에 Shared Preferences가 저장했던 정보를 다시 저장해야 한다. 이 뜻은 Shared Preferences를 Datastore로 이전 저장하기 위해 Migration 용 스펙을 정의해놓은 객체가 필요하다는 뜻이다. Shared Preferences를 Datastore로 이전하는 작업은 보통 두가지 상황의 경우에 고려된다. 첫 째, Shared Preferences가 새로 만들 Datastore과 Dependency가 있어 같이 작업하는 것이 좋은 경우. 둘 째, Datastore에서 제공하는 Coroutines, Flow..
환경세팅 안드로이드에서 Proto Datastore을 사용하기 위해서는 Type Safety를 위한 처리를 해주어야 하기 때문에 Preference Datastore보다 복잡하다. Gradle 파일 세팅 1. 모듈 수준의 gradle 파일에 플러그인을 추가한다. plugins { .. id("com.google.protobuf") version "0.8.17" } 2. 모듈 수준의 gradle에 라이브러리를 추가한다. 하나는 datastore 라이브러리이고 다른 하나는 protocol buffer을 위한 java 라이브러리이다. dependencies { .. implementation("androidx.datastore:datastore:1.0.0") implementation("com.google.p..
