Compose Desktop 자체로만 본다면 기능적 한계(제공되지 않는 기능, 제한된 커스텀)이 명확하지만 기존 Swing, AWT를 그대로 사용할 수 있기에, 그리고 이전부터 만들어졌던 Java 라이브러리를 사용할 수 있기에 해당 문제를 해결할 수 있지 않나 싶습니다. 상호운용성 하나만큼은 정말 뛰어나기에 AWT와 Compose를 엮어서 간단하게 자유롭게 커스텀이 가능하다는 점이 정말 좋은 것 같습니다. 그렇지만 이는 AWT 지식이 있어야만 자유로운 데스크탑 개발이 가능하다는 것... 또한 이외의 기능들도 Flutter의 경우 이제는 수많은 라이브러리를 통해 네이티브 개발 없이도 구현 가능한 기능들이 많지만, Kotlin Multiplatform은 출시된지 얼마안됐기에 황무지인데... 과연 개척에 성공..

모아키를 사랑하는 저는 아이폰으로 다시 넘어오면서 모아키를 사용하지 못하는 현실에 좌절하였습니다. 사실 안드로이드, 아이폰을 매번 번갈아가면서 사용하고 있어 알고있었기에 마음의 준비를 했음에도 불구하고 점점 그리워지는... 그래서 든 생각. 없으면 직접 만들어보자 라는 생각으로 도전해보고 있는데 받침 조합을 생각하니 복잡하다는 사실을 깨달았습니다. (완성할 수 있을까...?) 저작권이 삼성에 있어 출시는 못하겠지만 자기 만족으로 쓰지 않을까... 잠깐이나마 일부긴 하지만 돌아가는 모아키를 보고 반가웠습니다.

올해 1월부터 6월동안 개발한 프로젝트가 최종 TOP 100위에 선정되었습니다. 치매 노인을 위한 서비스로, 아쉽게도 TOP 10위에는 들지 못하였지만, 처음 플러터로 개발한 프로젝트이자 현직 구글 멘토님들과의 멘토링을 통해 새로운 경험을 해볼 수 있었던 프로젝트였던 것 같습니다. (영어는 어려워요...) 아래는 소개 영상입니다!

예전에 해커톤에서 만들었던 기능 중 화면 하나를 Compose로 만들어 보았습니다. (사실 귀차니즘으로 일부는 하드코딩 되어 있습니다) 그렇습니다. iOS에서의 UI도 Compose iOS로 구현되었습니다. UI는 컴포즈. API는 Ktor. 비동기는 Coroutine. iOS에서는 KMM에서 생성된 ComposeView를 draw 해준 것 외 작성된 swift 코드는 전혀 없습니다. (와!) import SwiftUI import shared struct ComposeView: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> UIViewController { IosKt.MainViewController() } ..

기존 Skiko를 활용하여 Web 내 순수 Compose 그리는 것에 성공한데 이어 iOS도 성공하였습니다! 다만 iOS는 빌드되지만 AOS 관련하여 빌드 이슈가 발생하기에... (gradle 관련 추가 작업이 필요한데 힘들군요) 아직 추가적인 수정 및 테스트가 필요할 것 같지만 1차적으로 성공하였기에 너무 행복하네요 헤헤 사실 그동안 실패하여 막막하다 이번에 다른 GDSC Lead들과 함께 부산으로 MT오는 길에 KTX 코딩 + 음주 코딩을 통해(?) 성공하였습니다. 역시 무언가 개발하다 막힐 때에는 환경을 변화시키는 것이 새로운 해결책일 수 도 있지 않을까 싶습니다.

Compose Web에 Skiko를 입히니 기존 Compose 로직 그대로 Web에서도 UI를 그릴 수 있네요. Canvas에 그려지는 형태이기에 SEO는 불가능할 것 같아 아쉽지만 차후 Flutter SEO 라이브러리처럼 구현된다면... 이번 발견(?)으로 이제 정말 Flutter처럼 Compose 단일 UI 코드로 AOS, iOS, Desktop(Windows, Linux), Web 모두 구현이 가능할 것 같습니다. 물론 아직 Web에서 몇 가지 테스트를 해보니 몇몇 인터렉션이 작동되지 않기에 수 작업으로 연결이 필요하는 등 stable 한 것 같지는 않기에 정식 product 사용은 어려워 보이긴 하지만 언젠가 정말 stable 하게 출시된다면 Compose로 세계 대통합을 할 수 있지 않을까.....

multi-module 방식으로 대대적인 리팩토링을 진행하였습니다. 물론 로직 자체는 방대하지 않기에 대대적이라고 표현할 정도는 아니긴 하지만, 결과적으로는 패키지를 모두 뜯어 고쳤습니다. 기존 고안은 Ktor server, client에서 사용되는 공통 request, response 모델을 common-data 패키지에 두고 이를 server, plugin에서 사용하는 방식으로 구상하였습니다. 이를 통해 모델이 중복 생성되는 일종의 보일러플레이트를 방지할 것이라 생각하였습니다. 안드로이드 개발하면서 멀티모듈로 분리하는 것은 매번 하던 것이기에 별다른 걱정을 하지 않았으나 각 플랫폼에서 타 모듈을 인식하지 못하는 이슈가 발생하여 끙끙 고생하다 알게 된 사실은, 기존 백엔드와 플러그인 프로젝트를 생성할 ..

개발하다 보니 자주 사용하는 네이밍과 사용자 수 같은 통계 및 Exception 발생 시 해결을 위해 로깅을 하면 좋겠다는 생각에 DB를 함께 구축하고 있습니다. 간단하게 2, 3일 개발하고 출시하려고 하였는데 점점 욕심이 생겨 무언가 추가되는 것 같네요. DB 관련하여 Ktorm과 Exposed 둘 중 어떤 것을 사용할지 많이 고민하였습니다. 사실 두 라이브러리 모두 유사한 구조(?)를 지니고 있기에 차후 라이브러리를 바꾼다하더라도 러닝커브가 크지 않을 것 같기도 하고, libhunt 기준 Exposed가 Ktorm 보다 많은 인기를 지니고 있기에 Exposed를 택하였습니다. (물론 그 외의 이유들도 있지만, 밥이 다 되었기에 자세한 설명은 생략하고 차후 기회가 된다면 풀어보겠습니다.) 사실 해커톤 ..

개발자의 최대 난제 변수/함수 이름 짓는 플러그인을 만들고 있습니다. Ktor server를 통해 백엔드를 구축하고 Ktor client를 통해 플러그인 내에서 백엔드와의 통신을 진행, 즉 클라이언트/서버 모두 Ktor로 구현되었습니다. 이전부터 IDE 플러그인을 만들어보고 싶었는데 문득 떠올라 재밌게 만들고 있네요. 안정성을 보완하고 바로 JetBrains Marketplace에 업로드 및 VS Code로도 구현할 예정입니다.

컴포즈 웹 프로젝트를 생성 후 빌드를 시도하자마자 아래의 오류가 발생하였습니다. KJS / Gradle: Configuration failed: Could not find node-14.17.0-darwin-arm64.tar.gz (org.nodejs:node:14.17.0) 연계된 레포지토리가 삭제된 것인가 생각을 하다, 이전 gRPC를 다루는 과정에서 M1에 해당되는 ARM64 바이너리가 릴리즈 되지 않아 고생했던 기억을 떠올리며 방법을 찾던 중 노드의 버전을 변경해보라는 내용을 찾아 적용해보았습니다. build.gradle.kts repositories { rootProject.plugins.withType { rootProject.the().nodeVersion = "16.0.0" } 적용 후 s..