savedStateHandle로 ViewModel의 상태를 저장 PR리뷰로 (Activity or Fragment)에서 사용하던 savedInstanceState를 ViewModel의 savedStateHandle로 사용해달라는 요청이 왔습니다. 검색하면서 궁금했던 점 1. 아래 글을 보면 savedStateHandle.set과 get이 있습니다. 따로 set/get은 하지 않아도 된다고 함. savedStateHandle 안에 intent로 넘어온 값이 들어있음 로그를 직접 찍어보니 Fragment의 savedInstanceState는 null이고 (true값) ViewModel의 savedStateHandle는 데이터가 있었다. (intent안에 있는 값들이다.) 그래서 뷰 모델의 LifeCycle은..

exception 이 발생할 수도 있을 것 같아서 try/catch를 띄워주면 좋을 것 같아요. 그리고, 관련 메서드들이, java 코드라서, 반환값이 NotNull을 보장할 수 없기 때문에, null 예외처리도 해주면 좋을 것 같아요함수를 만들었는데 그 함수가 exception이 발생할 수 있는지 확인하고, 사용하는 함수가 안에 자바로 되어있을 경우 null예외처리도 생각하자.!

Provider 패턴 프로바이더 패턴을 쓰는 이유는? a.관심사의 분리 관심사의 분리는 디자인 원칙의 하나입니다. 보통 관심사는 어떤 코드가 하는 일을 말합니다. UI를 담당하는 코드, 네트워크를 담당하는 코드, 데이터를 담당하는 코드 등 보통은 한 클래스가 여러 역할을 할 수록, 클래스가 커지고 관리가 어렵게 됩니다. 따라서 클래스가 하나의 역할(관심)만 갖도록, 클래스를 나눈다. 이게 바로 관심사의 분리이다. Provider나 Bloc패턴을 쓰는 이유는 관심사의 분리를 위해서이다. b. 데이터의 공유 하나의 데이터를 여러 페이지에서 공유하고 싶을 때가 있다. ex) 유저 인증 정 Provider패턴을 쓰면 데이터 공유를 쉽게 할 수 있습니다. c.좀 더 간결한 코드 Bloc패턴의 경우 클래스들을 역할..

Bloc Pattern Bussiness Logic Component https://medium.com/@pks2974/bloc-%EC%9D%B4%ED%95%B4-%ED%95%98%EA%B8%B0-%EB%B0%8F-%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC-%ED%95%98%EA%B8%B0-7dc705e4c640 Bloc 패턴은 Flutter의 상태 관리를 제어하기 위해서 Google개발자에 의해서 디자인 되었다. Flutter에서는 상태에 따라서 렌더링이 일어나기 때문에, 상태 관리가 매우 중요하다. BLOC은 UI와 Bussiness Logic을 분리하여, 각각 코드의 의존성을 낮추게한다. Bloc의 형태 bloc에서 각 UI객체들은 bloc객체를 구독하고 있다. bloc객체..

팩토리 패턴(Factory pattern) -모든 팩토리 패턴에서는 객체 생성을 캡슐화한다. -팩토리 메소드 패턴과 추상 팩토리 패턴이 존재한다. -팩토리 메소드 패턴: 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정한다. -추상 팩토리 패턴: 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성할 수 있다. 추상 팩토리 패턴에는 팩토리 메소드 패턴이 포함될 수 있다. -디자인 원칙 중 '추상화된 것에 의존하도록 만들어라. 구상 클래스에 의존하지 않도록 만든다.'에 기인한 패턴이다. 팩토리패턴의 핵심은 '클래스의 인스턴스를 만드는 것을 서브클래스에서 결정하도록 한다는 것이다.' 즉, new 키워드를 사용하는 부분..

빌더 패턴 (Builder pattern) -객체를 생성할 때 흔하게 사용하는 패턴이다. Member customer = Member.build() .name("홍길동") .age(30) .build(); 규칙. 생성자 인자가 많을 때에는 Build패턴 적용을 고려하라. 아이템. 생성자에 매개변수가 많다면 빌더를 고려하라. :객체를 깔끔하게 :점층적 생성자 패턴 1. 필수 인자를 받는 필수 생성자를 하나 만든다. 2. 1개의 선택적 인자를 받는 생성자를 추가한다. 3. 2개의 선택적 인자를 받는 생성자를 추가한다. 4. ..반복 5. 모든 선택적 인자를 다 받는 생성자를 추가한다. // 점층적 생성자 패턴 코드의 예 : 회원가입 관련 코드 public class Member { private final ..

리뷰 내용 : 지금 onNext 이후에 onComplete를 호출해주고 있지 않은데요 끝날 때 onComplete를 호출해주시거나 어차피 onNext와 onComplete를 한번씩만 호출해 줄 것이라면 Observable 대신 Single을 사용해보면 어떨까요? 참고로 Observable의 하위 구현체들은 아래와 같습니다. Single : 데이터를 한개만 방출 Maybe : 데이터를 0개 또는 1개만 방출 Completable : 데이터 없이 성공 실패만 방출 Subject : Observer 이면서 Observable Flowable : 배압(Backpressure) 조절 가능한 Observable

리뷰 내용 : subscribeOn과 observeOn을 모두 메인스레드에 하고 있는데 둘 다 메인스레드로 설정할 필요는 없어 보입니다. 제 생각에는 sendPhotoObservable와 sendSignObservable를 병렬로 처리할 수 있도록 subscribeOn은 IO스레드나 새로운 스레드(Schedulers.newThread())에서 하고 observeOn을 지금처럼 메인스레드에서 처리하여 zip한 결과를 UI 스레드에서 처리하는게 좋지 않을까 싶네요

var nextString: String? = null if (next > 0) { nextString = next.toString() } putExtra("next", nextString) >>>>>>> putExtra("next", next.takeIf { it > 0 }?.toString())

기존 2개 선언 할 때 val (textColorResId, backgroundResId) = R.color.gray_4 to R.drawable.shape_round_20_gr 3개로 선언할 때 val (textColorResId, backgroundResId, enable) = Triple(R.color.gray_4, R.drawable.shape_round_20_gr, false)