728x90 반응형 전체 글180 Dart isolate에서 탭 선택이 꼬인 날 — 늦은 응답을 거르는 방법 Dart isolate에서 백그라운드 작업 결과를 받아 화면을 갱신하다가 탭 선택이 꼬이는 문제를 겪었다. 이전 요청의 응답이 늦게 도착해 최신 상태를 덮어쓰고 있었다. 결국 요청 번호로 오래된 결과를 걸러내고, UI 상태 변경의 경계를 정리했다.처음에는 결과만 받으면 되는 줄 알았다처음에는 백그라운드 isolate의 결과를 받아 메인 isolate에서 상태를 바로 갱신하면 될 줄 알았다. 간단한 샘플에서는 화면도 바로 갱신됐고, 별문제가 없어 보였다.문제는 작업이 길어지고 요청이 겹치면서 나타났다. 샘플에서 잘 돌아간다고 실제 화면에서도 응답 순서가 보장되는 건 아니었다.탭을 빠르게 오가자 이전 응답이 덮어썼다탭을 빠르게 오갈 때 이전 요청 결과가 늦게 도착하면서 최신 선택값을 덮어썼다. 로딩이 끝났는.. 2026. 10. 17. 핀치 줌 4배를 100배로 올리며 손본 안드로이드 렌더러 크기와 툴바 여백 협업 메신저 앱의 원격 화면 보기에서 핀치 줌 상한을 4배에서 100배로 올렸다. 그 과정에서 확대된 크기대로 렌더러 뷰를 배치하는 구조와 툴바 높이가 빠진 여백 계산도 손봤다. 숫자 하나를 바꾸며 함께 고친 배치 계산을 정리했다.4배 제한을 100배로 바꾸면 끝일 줄 알았다안드로이드 앱에서 원격 PC 화면은 두 손가락으로 확대할 수 있었다. 기존에는 맞춤 배율의 4배에서 멈추도록 coerceIn(1f, 4f)로 제한했다.이번에는 상한을 100배로 높이고 상수로 분리했다. 다른 원격 데스크톱 앱도 100배를 쓴다는 설명을 코드 주석에 적었지만, 그 수치를 별도로 검증하지는 않았다.아래 코드는 커밋에서 필요한 줄만 뽑아 간략화한 예시다.// 수정 전: 맞춤 배율의 4배까지val nextZoom = (ges.. 2026. 10. 17. 멀티 모니터 원격 뷰어, 창 하나를 전제로 짠 세션·수명 구조 풀기 원격 제어 프로그램에 모니터마다 창을 따로 여는 기능을 추가했다. 처음에는 뷰어 창만 늘리면 될 줄 알았지만 서버와 호스트에도 단일 세션을 전제로 한 코드가 있었다. 그 전제를 풀어 간 과정과 아직 남은 검증을 정리했다.모니터 전환 버튼 하나로는 부족했다원격 PC에 모니터가 여러 대 있어도 뷰어는 창 하나로 화면을 보여줬다. 다른 화면을 보려면 툴바에서 모니터를 전환해야 했다. 두 화면을 나란히 놓고 보기는 어려웠다.그래서 '모든 모니터 열기' 버튼을 추가하기로 했다. 기존 창은 남겨 두고 열리지 않은 모니터를 각각 별도 창으로 띄우는 방식이다. 처음엔 창만 몇 개 더 만들면 될 것처럼 보였다.세션을 교체하던 서버에 창 그룹을 넣었다첫 번째 문제는 관리 서버의 세션 생성 규칙이었다. 기존 코드는 같은 관.. 2026. 10. 17. Flutter Hot Reload에 속아 연결 상태가 꼬인 날 — 원인과 해결 Flutter로 연결 상태 모니터링 화면을 만들다가 Hot Reload 직후 연결은 살아 있는 것처럼 보이는데 데이터가 오지 않는 문제를 겪었다. 원인은 상태를 보존하는 Hot Reload가 초기화 코드까지 다시 실행해 줄 것이라는 착각에 있었다.Hot Reload만 믿고 화면을 고쳤다처음에는 Hot Reload로 UI를 계속 만지면 충분할 줄 알았다. 위젯 배치를 바꾸면 바로 화면에 반영되니 개발 속도가 빨라지는 느낌이었다.연결 상태를 보여주는 화면도 비슷할 거라고 생각했다. 화면을 수정하고 Hot Reload로 확인하는 방식이 익숙해졌다.연결된 것처럼 보였지만 데이터는 오지 않았다문제는 Provider 초기화 코드를 건드린 뒤 나타났다. 화면은 살아 있었지만 내부 연결 상태가 꼬였고, 연결되어 있다고.. 2026. 10. 17. RLock 파일 락이 동시 다운로드를 막던 구조, 읽기·쓰기 락으로 바꾼 과정 Windows 클라이언트에서 다운로드 세 개를 동시에 처리하려다 서버의 파일 락 구조부터 다시 살펴봤다. 기존에는 같은 파일을 읽는 요청도 하나의 락을 두고 경쟁하도록 묶여 있었다. 서버의 읽기·쓰기 구분과 클라이언트 전송 스케줄러를 함께 손본 과정을 정리했다.전송은 한 번에 하나씩만 처리했다사내 클라우드 스토리지에는 웹 화면 외에 Windows 클라이언트도 있다. 기존 클라이언트는 모든 파일 전송을 SemaphoreSlim(1, 1) 하나로 제한했다. 파일 하나를 받는 동안 다른 다운로드와 업로드는 차례를 기다려야 했다.이번에 정한 목표는 다운로드 최대 3개와 업로드 1개를 별도로 처리하는 것이었다. 처음엔 세마포어 숫자만 바꾸면 될 것처럼 보였다. 하지만 클라이언트의 제한을 풀기 전에 서버의 파일 접.. 2026. 10. 17. SQL COUNT(*) 때문에 느려진 로그 목록 — 이전·다음만 남긴 이유 로그 목록에 전체 페이지 수를 보여주려고 COUNT(*)를 함께 실행했다. 그런데 로그가 쌓이자 전체 건수를 세는 작업 때문에 목록까지 느려졌다. 결국 페이지 번호를 없애고 이전·다음 버튼만 남기면서 목록 조회의 체감 속도를 개선했다.처음에는 COUNT(*)를 함께 실행했다2026년 9월 6일, 로그 목록의 페이지네이션을 손보고 있었다. 처음에는 목록 쿼리 옆에 COUNT(*)를 같이 실행하면 전체 페이지 수를 쉽게 표시할 수 있다고 생각했다.데이터가 적을 때는 체감상 괜찮았다. 목록도 나오고 전체 개수도 알 수 있으니 굳이 구조를 바꿀 이유가 없다고 생각했다.로그가 쌓이자 카운트가 발목을 잡았다그런데 로그가 쌓이니까 목록 조회보다 전체 건수를 세는 작업이 더 오래 걸리는 것처럼 느껴졌다. 사용자는 목록.. 2026. 10. 17. 이전 1 2 3 4 ··· 30 다음 728x90 반응형
