OOM(Out Of Memory)이란 사용자에게 보이는 앱의 비정상 종료는 대부분 예외 발생에 따른 Crash가 그 원인이지만, 기타 주요 원인으로는 Out Of Memory(OOM)를 들 수 있다. 애플리케이션이 대량의 메모리를 이용하여 시스템 메모리가 부족해지면, OS에 따라 해당 앱은 강제로 종료된다. 일반적으로 사용자에게 보이지 않는(백그라운드 또는 작동하지 않는) 앱이 우선 종료되지만, 앱이 표시되고 있는 상태에서도 대량의 메모리를 소모하여 시스템 메모리가 부족해지면 OS에 의해 강제로 종료된다. OOM에 의해 앱이 종료되는 경우, 앱 프로세스 내부에서 이벤트를 취득할 수 없으며, 앱 프로세스 외부에서 강제로 종료되기 때문에 정확하게 OOM을 검출할 수 없다. 또한, 앱이 표시된 상태에서 프로세..
BLoC(Business Logic Component) BLoC(Business Logic Component)란 UI와 Business Logic을 분리하여 만드는 방식을 의미한다. BLoC는 Flutter의 state를 관리하는 디자인 패턴 중 하나이며 Google 개발자에 의해 고안되었다. Flutter는 state에 따라 렌더링이 일어나기 때문에, 상태 관리가 매우 중요하다. 또한 상태 관리는 Flutter에서 만의 문제가 아닌 모든 개발에서 중요하게 고려되어야 할 사항이다. 그러므로 이 BLoC Pattern은 Flutter를 위해 설계되었지만 다른 프레임워크나 언어에서도 적용 가능한 디자인 패턴이다. 예를 들어 React Native에서 setState라는 Hook을 이용해 상태를 갱신시키며 ..
주요 개념 BLE RSSI(Received Signal Strength Indicator) RSSI(Received Signal Strength Indicator) 방식은 실내 위치 측위를 위한 가장 간단한 방법으로 많이 사용되는 위치 측위 방법 중에 하나이며, RSS는 수신기에서 수신되는 실제 신호 전력 강도이며 일반적으로 데시벨-밀리와트(dBm) 또는 밀리와트(mW) 단위로 측정된다. 이 용어는 Bluetooth에서만 쓰이는 단어는 아니고 RF 신호를 사용하는 모든 시스템에서 사용되고 있는데, LTE 모뎀과 같은 통신 모듈에서도 RSSI라는 단어를 사용한다. RSSI값은 송신기(Tx)와 수신기(Rx) 장치 사이의 거리를 추정하는 데 사용할 수 있다. RSS 값이 높을수록 Tx와 Rx 사이의 거리가 ..
BLE 기능을 사용하는 앱을 설계하며 블루투스와 BLE는 이름만 비슷한 다른 방식이라는 것을 알게 되었다. 블루투스(Bluetooth)우선 블루투스(Bluetooth)는 버전별로 아래와 같은 차이가 있다. BT 1.x 버전은 가장 초기에 나온 1.0부터 2002년에 등장한 1.1을 거쳐 1.2까지 개선하였다.1.0 버전에는 블루투스 기기에서 볼륨 조절 등을 가능하게 해주는 AVRCP 기능 포함하여 출시되었다. 하지만 1.0 버전은 초창기 규격으로 속도나 안정성의 문제가 있었다. 대표적으로 2.4Ghz의 주파수를 사용하고 무선 랜(802.11b/g)도 2.4Ghz대의 주파수를 같이 사용하므로 동시 사용에 따른 충돌 관련 문제 등이 있다. 이후 1.1 버전~1.2 버전 업데이트를 통해 안정성과 보안 그리고..
MQTT(메시지 큐잉 텔레메트리 트랜스포트, Message Queuing Telemetry Transport)는 ISO 표준 Publish(발행)-Subscribe(구독) 기반의 메시징 프로토콜이다. MQTT는 TCP/IP 프로토콜 위에서 동작하는데 이는 Bluetooth나 Zigbee와 같이 다른 통신 모듈이 필요한 것이 아닌 wifi나 lte를 이용해 인터넷을 통해 통신이 이루어진다는 뜻이다. 다만 HTTP, TCP등의 통신과 같이 Server-Client 구조로 이루어지는 것이 아니라 Broker, Publisher, Subscriber 구조로 이루어진다. "작은 코드 공간"(small code footprint)이 필요하거나 네트워크 대역폭이 제한되는 원격 위치와의 연결을 위해 설계되어 있다. P..
컴퓨터 프로그래밍에서 SOLID란 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 스파게티 코드, 에일리언 코드 또는 레거시코드가 되지 않도록 하기 위한 지침이다. 이렇게 설계된 소프트웨어는 재사용이 많아지고, 수정이 최소화되기 때문에 결국 유지 보수가 용이해진다. 물론 처음에 SOILD 원칙에 따라 소스코드를 작성하였어도 지속적으로 추가, 수정 등을 진행하며 리팩터링을 수행하여야 한다. SOILD는 아래 5가지의 원칙의 첫 글자를 따서 명명되었다...
