Machine_웅_Note

BLE(Bluetooth Low Energy)와 Bluetooth Classic은 둘 다 **Bluetooth** 기술을 기반으로 하지만, 목표로 하는 사용 사례와 성능 요구 사항에 따라 서로 다른 **프로토콜 스택**과 특성을 가집니다. 그 결과, 두 기술은 전송 속도, 전력 소비, 연결 방식에서 큰 차이를 보입니다. 아래는 **BLE**와 **Bluetooth Classic**의 프로토콜 차이에 대한 설명입니다. ### 1. **주요 목표 및 사용 사례**- **Bluetooth Classic**:   - 주로 **고대역폭**과 **지속적인 데이터 전송**이 필요한 애플리케이션에 사용됩니다.   - 음성 통화(헤드셋), 고음질 음악 스트리밍(A2DP), 파일 전송 등이 주요 사용 사례입니다.   - ..

https://sungbin.land/%EC%95%84%EC%A7%81%EB%8F%84-mvvm-%EC%9D%B4%EC%A0%A0-mvi-%EC%8B%9C%EB%8C%80-319990c7d60 아직도 MVVM? 이젠 MVI 시대! Orbit을 이용한 MVI 디자인패턴 알아보기 sungbin.land * intent가 android intent가 아니었다... ( 그랬군.... ) * Redux의 개념을 사용한다.

싱글톤 내에 있는 List를 RecyclerView에서 사용한다면, RecyclerView의 어댑터에서 해당 List를 참조할 수 있습니다. 이 경우에는 싱글톤 내의 List를 변경하면 RecyclerView에 표시되는 데이터도 함께 변경됩니다. 즉, RecyclerView 어댑터에서 List를 참조하면 해당 List를 수정하는 것은 원래 List의 참조를 수정하는 것과 동일합니다. 그러므로 RecyclerView에서 사용되는 List는 참조가 동일합니다. 하지만, 이러한 방식은 동시성 문제가 발생할 가능성이 있습니다. RecyclerView와 싱글톤 내의 List가 동시에 수정되는 경우, 일관성이 없는 결과가 발생할 수 있습니다. 따라서, 이러한 문제를 방지하기 위해서는 동기화(Synchronizati..

Hilt 란? Dagger API를 Android에서 설치하고 설정하고, 테스트 하는 과정을 쉽게 해주는 오픈소스 래퍼 라이브러리 주목적 - 테스트를 위한 의존성 주입 설정 기능 추가 - Android 앱에서 반복적으로 가장 많이 사용되는 보일러플레이트 코드를 제거 => Dagger 와 Hilt 비교 ! => 위의 그림의 형태로 구조가 자동적으로 만들어져 있다고 보면 된다. => HiltAndroidApp 만 넣는것 만으로 다른 초기화가 필요 없음 => AndroidEntryPoint 만으로 자동으로 필드주입, 인젝션이 다른곳에 있다면 자동으로 들어감 => 모듈의 설정이 약간 바뀌었다, 컴포넌트 지정 필요 x 어디에 인스톨되는지 표기 필요 

* 컴파일 시점에서 대거를 지원하는 툴들이 지원되고 있다. => 컴포트넌트를 구현하게되면, 컴포넌트를 토대로 해서 인젝터라는게 생성이 된다. => 인젝트 매서드를 구현해줘야한다 1. Application 단에서 전역적으로 선언. => public 으로 해서 DaggerApplicationComponent.create() => 앞서 ApplicationComponent를 만들면 자동으로 Dagger라는 접두어가 달린 클래스가 자동으로 생성 된다. 2. Activity에서 super.onCreate 위에 Dagger 인스턴스를 만들어준다. (applicationContext as MyApplication).appComponent.inject(this) * 이걸로 기본 세팅은 끝났다. 주입될 대상이 될 클래스..

- 이제는 안드로이드 개발에 있어서 필수적인 부분으로 자리 잡았다. => 일관적으로 객체(의존성)를 만드는 방법이 정해진곳이 따로 있고, 만들어서 필요한 곳에 전달한다. 왜 의존성 주입을 사용하지 ?? => 객체(의존성)을 밖에서 만들어서 주입을 하게 하면, 코드 재사용상이 높아진다. => 클라이언트 코드의 변경 없이도 손쉽게 다른 형태의 DataSource 인스턴스를 만들 수 있다. => 객체의 생성 과정이 바뀌더라도 클라이언트 코드에 영향을 주지 않는다. => 클라이언트는 interface로만 객체를 알고 있으면 되므로, 보다 나은 설계가 가능하다. - 추상화, 멀티모듈에서 모듈별 의존성을 떼어내는 데에 매우 유용 => 코드를 테스트 가능하게 한다 ( 객체의 생성방..

=> 코틀린에서 invoke 해서 사용할 정도의 수준인 경우 . => 코틀린에서는 값객체를 이용한 패턴을위해 inline으로 지원해 준다. => 레포지토리란 ? 저장방식이 어떻게 되는지를 감쳐주는 역할을 한다. => 데이터스토어는 기본적으로 인터널 클래스로 만들어서 다른곳에서 노출되지 않게 만들어 준다. * Data Store는 기존의 쉐어드 프리퍼런스의 문제가 많아 대체해서 사용하기 위해서사용 하자 ( 디바이스마다 다르게 동작하는 문제라거나, 비동기가 아니라 동기적으로 동작을 한다거나 하는 문제 등 ) * 로컬을 사용하는경우 어느정도 데이터 용량이 커지기 전까지는 사용할만한다. => 할 수 있는한 가장 낮은 레벨에서 처리하는게 좋다. => 개발자가 아닌 기획자 등과 논의..

1. 도메인 주도 설계 ( DDD ) 개론 - 주된 철학 , 원리 그리고 전략적 설계 => 그프로젝트에서 의미있는 용어를 만들고 정하는 것. => 기술적인 용어 x , 도메인 용어 x , 상호 합의된 언어 => 도메인 모델을 만드는데 핵심은 사용자 스토리 이다.

강의를 통틀어서 도메인/데이터 계층 부분이 제일 중요하다고 할 수 있다.. 집중.. 1. 앱 아키텍처의 미드필더라고 할 수 있는, 도메인 계층을 어떻게 설계 할 것인가. 사고실험 ) 2번 - 보통 이렇게 시작을 한다. ( 문제는 - 앱에 구현이 어떻게 될까에 대해서는 도움이 안된다. ) 3번의 문제 - 디자인이 계속 바뀔 수 밖에 없기때문에 비효율. 4번 - 기술검토 부분 ( 재활용 x ) => 보통의 경우 데이터 설계로 시작하는 경우가 대부분인데 이렇게 되면, 앱의 경우에는 어떻게 구현을 해야할지에 대해서는 알 수 없고, 도움이 되지 않는다. Bast Case => UI와 DB 연결을 제외하고도 핵심시나리오를 구현 할 수 있기 때문에 나중에 재활용이 가능하다. => 테스트를 먼저 진행하면서 할수 있다...

* 앱 전체의 state를 하나의 머신으로 처리를 하면 어떨까..? I : (intent) 예시 ) API 요청 -> 미들 웨어 -> API 호출 -> store 저장 -> 리듀서에서 가공 -> UI 적용 => 전체 흐름에 대한 그림을 이해해는데 어려울수 있음. => 각각의 코드들이 여러군데 흩어져있임 => 로직의 복잡도가 높아지거나, 미리 염두해서 계획해야한다. => 오히려 MVVM 에서 MVI 에서 복잡하게 처리해야 할 것들을 간단하게 처리할수 있다.