안녕하세요. 이광석입니다.
몇 달전 Slog을 통해 아발로니아를 통한 블로그 개발을 진행했었습니다만,
기술적인 문제(HtmlRenderer WebFont 적용안됨, 페이지 Link 이슈 등)로 인해 해당 프로젝트를 전부 날렸습니다!
대신 제 개인 블로그는 리액트로 변경하여 관리하고 있는 상태입니다.
블로그 : Lukewire Devlog
아발로니아 블로그 폐기 후 아쉬운 마음에 다른 방안을 생각하던 와중
그동안 제가 WPF로 구현 된 것들과 SNS에 웹으로 구현된 것들을 아발로니아로 변경한 것들을 전시해보기로 하였습니다.
git push 시 파일 크기로 인해서 호스팅서버를 교체했습니다.(github pages → netlify)
아발로니아 전시관 : https://delightful-profiterole-0fa25d.netlify.app/
감사합니다.
새해 복 많이 받으세요.
와…! 전시관 아이디어 멋지네요!!
오 훈륭 하군용…
그런데 우노와 아발로니아
어떤 기준으로 플랫폼 선택을 하는 걸까요 ?
Uno의 룩엔필은 디바이스에서 제공하는 그것과 동일합니다. Avalonia의 룩엔필은 디바이스와 상관없이 동일하게 제공합니다. 이는 두 프레임워크의 구현 정책에 의해 결정되었습니다.
Uno는 MAUI와 유사하게 UX의 동작성을 디바이스에서 제공하는 UI 컴포넌트를 대부분 차용합니다. 예를 들어 안드로이드 디바이스의 경우 안드로이드의 UI 컴포넌트를 그대로 사용해서 동작하는 것이죠.
하지만 Avalonia의 경우 디바이스 플랫폼과 상관없는 동일한 렌더링 인터페이스를 통해 UI를 렌더링 하기 때문에 플랫폼과 상관없이 동일한 UX를 제공합니다. 즉, 안드로이드 디바이스와 윈도우스 디바이스는 동일한 화면 UX를 가지게 됩니다. 이것을 픽셀 퍼펙트라고 합니다.
각 프레임워크는 각기 고유한 특징이 있습니다만 위의 내용만으로 설명할 때 서로 다른 뚜렷한 장/단점을 살펴볼 수 있습니다.
Uno의 경우 동작하는 디바이스의 플랫폼을 그대로 따라가기 때문에 네이티브 앱과 거의 유사한 동작성을 제공할 수 있습니다. 이에 반해 Avalonia는 네이티브 앱과 별개의 화면 렌더링을 하므로 필연적으로 다른 화면 컴포넌트 및 동작성을 제공하게 됩니다.
Avalonia의 경우 디바이스 플랫폼과 직접적인 상관없는 동일한 UI 렌더링 및 인터페이스를 제공하므로 플랫폼마다의 특성에 크게 영향받지 않습니다. 이에 따라 실제로 Uno보다 Avalonia가 좀 더 빠르고 안정적인 동작성을 제공하는 경향이 있습니다. Uno의 경우 어느 플렛폼은 동작하는데 다른 플렛폼은 동작하지 않는 케이스가 다수 있습니다.
또한 Avalonia의 경우 Uno보다는 모바일쪽의 후발주자로 모바일 앱 구현 시 아쉬운 면이 있습니다.
이에 따라 적절히 Uno 또는 Avalonia를 선택할 수 있습니다.
LLM 기술이 놀라울 정도로 발달했네요. 호기심에 위의 내용을 Copilot에 맞는 말인지 물어보니 다음 처럼 답하였습니다. 아래의 Copilot 요약 내용을 살펴보셔도 되겠습니다.
제가 우노를 대신해서 아발로니아를 선택했던건
wpf와 유사하기도 하고 html의 css처럼 다중스타일적용 등 자유로운 디자인처리때문이였습니다.
개인적으로 @dimohy 님께서 댓글남겨주신대로 모바일은 데스크탑처럼 프리뷰 기능이 없어서 디자인하기엔 불편합니다만
데스크탑 계열과 (wpf, mac os, lnux) 웹은 거의 같은 크기이기 때문에 무리 없이 할 수 있다는 사용 할 수가 있었습니다
그럼 안드로이드 탭 과 윈도우 용으로만 쓰려면 우노로 가는게 맞는걸까여 ?
아발로니아로 만들고 웹에 띄워 안드로이드와 윈도우에 띄워야 하나??
흠 뭔가 정리가 안되는 군요 ㅠㅠ
안드로이드 탭과 윈도우용으로 갈꺼면… Maui만으로 충분히 가능합니다만… (Uno를 쓰실려는 이유가 따로있으시겠죠…?)
현재 상황을 좀 더 알려주시면 같이 고민해드릴 수 있을 것 같아요 
윈도우 에서 쓰던걸 OS 를 바꿔 볼려고 하는 것입니다.
안드로이드 최 우선으로요
주변장치를 물려야 해서요
윈도우에서 COM PORT에 물리던 프린터나 신용카드 결제리더기 요
주변장치 연동은… UI 프레임워크와는 거리가 먼 것 같네요
시리얼 통신에 적합한 플랫폼은 셋중에서 MAUI 라고
챗G선생 께서 그러는 군요 …
MAUI 는 안드로이드 API 호출이 용이 하다고…
@windowmini 님께서
이 2단계로 나뉘어서 프레임워크를 선정하셔야 할 것 같아요.
1 단계
사실 우노에서든 아발에서든 안드로이드 API를 가져와 사용할 때에도 Maui 라이브러리를 이용하여 사용하시는게 마음 편할 수 도 있을 거 에요.
(아직 우노랑 아발에서 샘플들이 없기에…)
2 단계
제가 위에 언급드렸다시피 아발에서의 웹뷰로 띄운다고 하더라도 핫리로드나 미리보기 기능 같은 것 이 없기에 개발 퍼포먼스 면에서 우노, 마우이보단 살짝 느린 감이 있을 순 있을 것 같으니 패쓰!
그렇다면 우노, 마우이 인데,
어떤 것이든 상관이 없습니다. 몇 달전 우노 관련 행사에서 '한글 텍스트 입력이 안된다’는 얘기를 들었기 때문에 이게 문제다싶으시면 Maui로…!
우노든 Mau로 하셔서 웹뷰 띄우시고 JS 연결하시면 되니 … 이건 @windowmini 님이 취향적으로 선택하시면 될것같아요.
와우 감사합니다… 살짝 선명해졌습니다.
아발로니아로 기존 WPF 제품을 모바일용으로 포팅하는 작업을 진행하고 있습니다. 저도 우노와 아발로니아 사이에서 고민을 좀 했었는데 Xamarin.Forms에서 고생했던 경험을 바탕으로 아발로니아로 결정해서 작업을 진행하고 있습니다.
WPF에는 Expression Blend라는 좋은 XAML 디자인 도구가 있지만 Xamarin.Forms 를 비롯한 대부분의 크로스플랫폼 프레임웍에서는 디자인 관련 기능의 부족 및 느린 속도(에뮬레이터나 실 기기에서 확인해야 하므로) 등으로 디자인 생산성이 매우 떨어집니다.
그런데, 아발로니아는 Xamarin.Forms, MAUI, 우노와 달리 모든 플랫폼에서 Skia로 동일하게 랜더링되므로 데스크탑 버전으로 개발하다가 중간 중간 가끔식만 모바일 버전으로 테스트해보면 되므로 수정 후 빌드->Run까지 시간이 매우 짧아지는 장점이 있습니다.
그리고, Visual Studio 2022에서 아발로니아 axaml의 화면 프리뷰가 별도 프리뷰가 아닌 사실상 리얼타임 axaml 랜더링 결과가 화면에 바로 표시되고, 뷰모델의 속성도 디자인 타임에서 값을 수정하여 화면상에 미리 적용해볼 수 있는 디자인 전용 DataContext 기능도 있어서 Xamarin.Form와 같은 기술들에 비해서는 디자인 생산성이 비교가 되지 않게 좋습니다.
아발로니아 앱을 데스크탑 버전으로 실행한 후 F12를 누르면 브라우저 개발자 도구와 비슷한 기능의 디버깅 창이 열리는데 여기에서 Logical Tree, Visual Tree 등 화면 구조 파악도 쉽고 일부 속성들은 브라우저 개발자 도구처럼 바로 수정해볼 수 있습니다.
그리고, 모바일 기능 지원과 관련해서는 검색이나 AI 문의 결과를 보면 우노가 더 낫다고 하는데, 우노에서는 Navigation 기능이 기본적으로 제공되고 샘플이나 쇼케이스가 모바일 앱이 좀 더 많은 것은 사실입니다.
하지만, FluentAvalonia에는 Frame과 NavigationView라는 컨트롤이 있어서 네이게이션 기능을 크로스 플랫폼으로 사용할 수 있고, FluentAvalonia에 웬만한 UI 개발에 필요한 컴포넌트들이 다 있어서 개발할 만 합니다.
각 OS 전용 기능들은 의존성 주입을 이용해서 각 OS용 프로젝트에 구현하면 됩니다. 다만, 이렇게 구현하는 예가 공식 문서에 정확히 나와있지 않아서 아발로니아 Github의 Discussion에서 참고 내용을 찾아서 예전에 Xamarin.Form에서 했던 경험을 살려 필요한 기능들 다 만들 수 있었습니다. .NET 8 부터 MAUI.Essentials가 MAUI에서 분리되었기 때문에 각 모바일 OS 프로젝트에서 MAUI.Essentials 사용하면 됩니다.
잠깐 짬을 내서 그냥 생각나는데로 막 적었는데, 실제 한달 이상 아발로니아로 작업하면서 생각외로 모바일 앱 개발에도 쓸만하구나 하는 생각이 들었습니다.
화면 네비게이션 관련해서 Shell 이라는 라이브러리 한번 봐보시면 좋을 것 같아서 공유드립니다.
실제 개발 들어가기 전에 모바일 개발을 위해 필요한 사항들을 다양하게 살펴보면서 Shell 프로젝트도 같이 살펴봤는데 Shell은 거의 Xamarin.Forms의 Shell을 포팅한 느낌인데, FluentAvalonia 샘플을 스마트폰에서 직접 구동해보니 기능이나 확장성 면에서 FluentAvalonia쪽이 더 완성도도 높고 개발하다보면 꼭 필요한 Dialog 기능도 잘 되어서 있어서 다른 아발로니아 Dialog 패키지 필요없이 FluentAvalonia하나면 되겠더군요.
Shell 프로젝트는 아직 개발된 지 얼마 안되었지만 앞으로 더 발전하면 괜찮을 것 같은 아발로니아 프로젝트 중 하나인 것 같습니다.
아 그리고, 아발로니아 Discussions 페이지에서 본 내용인데 아발로니아 자체로 네비게이션 프레임웍을 추가할 계획이 있다는군요.
네, 말씀하신 FlunetAvalonia가 더 좋아보일 수 있겠네요.
