Xamarin.forms: Xamarin.Forms의 유비쿼터스 기능은 어떻습니까?

FWIW @juepiezhongren 여기에서 Ooui를 조사하고 있습니다.
https://github.com/praeclarum/Ooui

Trigger.io 로 패키징할 수 있는 방법이 있다면 iOS, Droid, Windows 및 웹의 주요 4가지 식품 그룹 모두에서 .NET을 실행할 수 있습니다.

아직 약간의 데모 상태이지만 내 관심을 끌었습니다. 👍

OP는 이해하기 어렵지만 "ubi"는 "SkiaSharp 또는 이와 유사한 것을 사용하여 플랫폼 독립적인 방식으로 렌더링된 Xamarin.Forms 보기"를 의미합니다. 이 경우 "ubi" 컨테이너는 ubi가 아닌 것을 포함할 수 없습니다. OP가 더 많은 사람들이 "ubi" 보기를 생성하기 위한 요청이라고 가정합니까? "ubi" 보기가 생성된다면 우리 대부분은 그것을 사용하는 데 반대하지 않을 것이라고 확신합니다.

여기서 문제의 일부는 "네이티브" 애플리케이션을 보는 방식, 즉 렌더링 방식을 변경해야 한다는 것입니다. HTML5는 여기에서 정말 최고의 예입니다. 모든 기기에서 HTML5 페이지를 볼 수 있으며 기본적으로 기기에 관계없이 동일하게 보입니다. IMO 이것이 모든 애플리케이션이 렌더링되는 방식입니다. "플랫폼별" 렌더링 또는 상호 작용을 원하면 스타일링 및/또는 템플릿의 문제여야 합니다(WPF 😉로 쉽게 가능했던 것). 즉, 개발자는 테마를 적용하는 것만으로 iOS 기반의 UX를 Droid 기기에서 또는 그 반대의 경우에도 제시할 수 있어야 합니다.

모든 의도와 목적을 위해 HTML5 는 유비쿼터스 렌더링 메커니즘이지만 JavaScript에 너무 뿌리내렸기 때문에 .NET과 결합할 때 엄청난 TCO가 발생합니다. Ooui가 소개하는 것은 HTML5/CSS를 렌더링 메커니즘으로 활용하는 동시에 나머지 모든 개발에 .NET을 독점적으로 사용하여 지식을 유지하고 기존 투자를 활용하여 _전체 개발 비용을 절감할 수 있다는 것입니다. 그러면 개발자는 프레젠테이션과 지원 인프라 모두에 대해 하나의 코드베이스만 남게 되며 iOS, Droid, Windows 및 웹에서 작업하게 됩니다. 많은 .NET 개발자들이 몇 년 동안 요구해 온 것입니다.

단점은 .NET 개발자가 CSS를 처리해야 하지만 진정한 유비쿼터스 솔루션을 오랫동안 기다려온 이 시점에서 우리가 기꺼이 양보할 수 있다는 점입니다. 적어도, 나는 할 것이다. 😛

uservoice 스레드는 Xamarin.Forms와 같은 것에 대한 호출이었습니다. Microsoft가 Xamarin을 인수하기 전인 2015년에 게시되었습니다. 요구 사항 중 Xamarin.Forms는 1) Windows 10 4) Droid 5) iOS에서 릴리스되었으며 3) *nix(Unix/Linux) 6) Macintosh에서 미리 보기로 제공되며 2) Legacy Windows로 시작되었으며 이제 막 7) 너무 다른 HTML5를 하지 마십시오. 실제로 Windows 10, Droid, iOS, Legacy Windows 및 Mac은 클라이언트 장치의 99.5%를 차지합니다. Xamarin.Forms가 존재하고 지금 이 모든 작업을 수행하므로 다른 훌륭한 솔루션이 필요하지 않습니다.

필요한 유일한 사항은 다음과 같습니다.

• Xamarin.WPF 속도를 높여 Xamarin.Forms를 WPF와 결합
• Xamarin.Forms 광고: 분명히 아직 이에 대해 모르는 일부 .Net 개발자가 있습니다.

원하는 것은 다른 것입니다. 동일한 크로스 플랫폼 렌더링입니다. 나는 이 필요를 이해할 수 있다. Xamarin.Forms의 경우 해당 프로젝트는 다음과 같이 분할될 수 있습니다.

• 다양한 Xamarin.Forms 컨트롤 간의 플랫폼 차이점을 문서화합니다. 정확히 동일한 렌더링이 필요하지 않더라도 많은 개발자가 이것을 흥미롭게 생각할 것이라고 생각합니다.
• 플랫폼 간에 특정 컨트롤이 너무 다르게 보인다고 생각하는 사람은 누구나 동일하게 렌더링되는 컨트롤을 만들 수 있습니다.

@charlesroddie, 시간을 내어 의견을 제시해주셔서 감사합니다. 나는 그들을 매우 감사합니다.

7) 너무 다른 HTML5를 수행하지 않습니다.

불행히도 이것이 바로 우리가 여기서 싸우고 있는 사고방식/태도입니다. 웹은 기본 플랫폼이 애플리케이션을 위한 환경을 호스팅하는 방식과 정확히 동일한 호스팅 환경입니다. 웹을 "다른" 것으로 보면 두 개의 별도 코드 기반을 개발하고 유지 관리해야 하는

또 다른 큰 해결책이 필요하지 않습니다.

여기에 있는 아이디어는 또 다른 훌륭한 솔루션이 아니라 더 간단한 솔루션입니다. 그 UserVoice의 의견을 읽는 데 시간을 들이면(매우 생생합니다. 😄), 거기에는 Xamarin.Forms의 팬이 많지 않습니다. 나 자신도 프로젝트(및 Xamarin의 모든 것!)를 지원하지만 결국에는 각각 고유한 특성과 고려 사항이 있는 n개의 프레젠테이션 스택을 지원하고 있습니다(우리 모두가 알고 있듯이 이 때문에 품질이 매우 낮습니다. 이제 막 스스로를 처리하고 있습니다). 또한 플랫폼별로 특정 렌더링이 필요한 경우를 대비하여 번거로운 전체 사용자 지정 렌더러가 있습니다. 이를 단순히 하나의 프레젠테이션 기술(HTML5)을 유지 관리하는 패러다임과 플랫폼이 수년 동안 지원하고 수행할 수 있는 HTML5를 단순히 렌더링하는 것과 대조됩니다. 특정 스타일을 적용하는 것만으로 플랫폼별 렌더링이 적용됩니다.

나는 그것이 완벽하다고 말하지는 않지만 장기적으로 훨씬 더 가볍고 유지 보수가 용이하다는 느낌이 듭니다. 더 싸고, LOL!

즉, HTML5 디자인 공간은 특히 CSS와 관련된 노련한 재능으로 가득 차 있다는 점을 고려하십시오. 비즈니스 관점에서 이것은 하나의 프리젠테이션 기술 오퍼링(n+가 아닌)에 관심을 가질 뿐만 아니라 이 공간에서 양질의 작업을 제공하기 위해 작업할 수 있는 많은 리소스가 있기 때문에 TCO를 줄입니다. 예를 들어 회전율이 있는 경우 n+(일반화 - 낮은 품질)를 알고 있는 것과 비교하여 하나의 프레젠테이션 기술(전문 - 높은 품질)을 알고 있는 리소스를 찾는 것이 더 쉬울 것입니다.

나는 우리 커뮤니티에서 웹을 "다르다"고 생각하는 것이 뿌리가 있다는 것을 알고 있지만, "다르다"는 것이 .NET 공간에서의 프레젠테이션에 대해 우리가 알고 있는 모든 것을 뒤집을 수 있다는 것이 점점 더 많이 보입니다.
그것이 적어도 일어나고 있는 일에 대한 나의 인상입니다. 그러나 나는 때때로 잘못된 것으로 알려졌습니다. 😉

나는 웹 기술에 대한 전문 지식이 없으며 너무 다르다고 말했을 때 현재 기술이 기본 구조와 웹 앱 구조 사이의 간극을 메우는데는 멀게 보인다는 것을 의미했습니다. Xamarin.Web은 좋은 아이디어지만 구현하기가 어렵습니다. 비록 이미 Ooui를 기반으로 하는 개념 증명 이 있을 수 있지만 말입니다. Xamarin.Forms 컨텍스트에서 이것은 물론 더 적은 것이 아니라 더 적은 html을 의미합니다.

여기가 바로 아아입니다. 생각해보면 그렇게 어렵지는 않은 것 같아요. Ooui는 (아직) 데이터 바인딩 또는 모든 종류의 Xaml 구성을 지원하지 않지만 구현하기에 충분히 쉬워야 합니다. 또한 저는 HTML의 팬이 아니기 때문에 여기에서 오해하지 마십시오. 사실 Xaml은 위에서 언급한 UserVoice에 div 및 yuck 태그를 처리할 필요가 없습니다. 😉 무엇보다도 여기에서 내 관심을 끌었습니다.

@Mike-EEE Avalonia는 정말 좋은 실험입니다.

Xamarin Forms 개발자에게 가장 생산적인 것은 SkiaSharp로 이식하여 https://github.com/chrfalch/NControl 을 되살리는 것입니다. 그러면 특정 유형의 상호 작용만 필요한 컨트롤을 쉽게 만들 수 있으며 이러한 컨트롤은 플랫폼 간에 동일하게 작동하고 SkiaSharp가 지원하는 모든 플랫폼을 즉시 지원합니다.

Flutter가 눈사태처럼 다가오고 있습니다. 해당 프레임워크와 해당 문서를 만드는 데 많은 작업이 진행되었습니다. 그러나 운 좋게도 오픈 소스입니다!

플러터 엔진은 C++이고 Dart는 거의 C#의 하위 집합이며 C# 및 Xamarin으로 "변환 가능"해야 합니다.

스키 열차에 탑승하는 가장 생산적인 방법은 Xamarin이 Flutter를 수용하고 Google이 앞으로 나아가도록 돕는 것이라고 생각합니다. Xamarin은 더 나은 플랫폼 통합을 제공할 수 있습니다.

예, Forms 작업은 아니지만(예: Redux가 MVVM보다 더 확실한 선택임), 정말 멋질 것입니다. :)

가자 MS. 어제처럼 포용하고 확장하십시오. Fuchia가 물건이 된다면 어쨌든 해야 합니다.

오 소년. 따라서 flex, CSS 및 실제로 완전히 작동하지 않는 기타 미친 것들 이후에 이제 Flutter? Xamarin Forms, 모든 거래의 잭, 누구의 주인도 아닙니다.
먼저 Xamarin Forms를 진정으로 성숙하고 안정적인 일급 프레임워크로 만드는 것은 어떻습니까? 하지만 잠깐만요, 그건 너무 기한이 지난 것 같아요...

@timahrentlov 는 내가 알고 싶어하는 redux와 mvvm의 비교를 보여줄 수 있습니까?

@juepiezhongren 나는 플러터에 대한 그런 비교를 본 적이 없습니다.

@timahrentlov xamarin.forms와 mvvm 대 redux를 고려하여 네이티브 반응을 비교하는 것을 의미합니다.

@Mike-EEE 블레이저와 프랭크의 ooui-wasm에서 폭풍우를 눈치채셨나요?

@juepiezhongren 정말... 상황이 뜨거워지기 시작했습니다! 🎉

@Mike-EEE는 wasm에 대한 ubis를 고려하고, skiasharp는 좋은 선택이 아닙니다.

@samhouts t-enhencement는 무엇을 의미합니까?

솔직히 @juepiezhongren , 나는 유일한 장기적 옵션이 HTML5/CSS라고 생각합니다. 이것이 내가 WebSocket Bridge(Ooui) 접근 방식에 관심을 갖는 이유입니다. WASM보다 가볍고 오버헤드가 적습니다. CSS는 형편없지만 약간의 기름기가 있으면 개발자로서 우리가 그것을 작동시킬 수 있다고 생각합니다. 😉 어쨌든, 나는 우리가 정말로 실행 가능한 무언가로부터 약 12-18개월이 남았다는 느낌을 받습니다. 정말 대단합니다. Ooui와 Blazor는 시작에 불과합니다.

또한 저는 MSFT와 @stevesanderson 이 Blazor 이니셔티브를 통해 실험적이고 혁신적

@Mike-EEE 예, baidu가 후원하는 echarts.js와 마찬가지로 html5의 CANVAS로 렌더링이 매우 좋습니다. 따라서 렌더 엔진은 분리되어야 합니다.

순수 HTML5가 더 빠릅니다, @juepiezhongren. 가장 이상적인 시나리오는 렌더링이 이미 NATIVE 캔버스에서 발생하고 있기 때문에 HTML5 DOM 컨트롤을 활용하는 것입니다. 😉 그렇지 않으면 HTML5 Canvas에서 렌더링하고 비교 및 ​​리소스 집약적인 JavaScript를 통해 업데이트합니다. 물론 HTML5 Canvas는 복잡한 비 기본 컨트롤(예: 차트 작성 등)에 계속 사용할 수 있지만 렌더링 표면인 IMO로 사용해서는 안 됩니다.

순수한 HTML5는 무엇입니까? @Mike-EEE js가 아닌 것은 무엇입니까?

맞아, @juepiezhongren ... HTML5 canvas 컨트롤을 통해 렌더링할 새 컨트롤을 만드는 대신 HTML5의 기본 "네이티브"(LOL이라는 단어에 주의해야 함) 컨트롤을 모두 활용합니다. Unity 또는 JSIL 에서 볼 수

물론 이는 구축 중인 컨텍스트와 애플리케이션에 따라 다릅니다. 내 모든 대화에서 기본적으로 비즈니스/LOB를 가정/고려하므로 "순수한" HTML5를 사용하는 것이 좋습니다. 게임/그래픽 집약적인 시나리오를 수행하는 경우 WASM이 첫 번째 선택이고 그 다음이 canvas 컨트롤입니다.

나는 HTML5가 SkiaSharp보다 XF에 찬성하여 뒤에 남겨지는 것이 가장 좋다고 생각합니다. ooui는 좋지만 항상 XF 컨트롤을 HTML로 변환해야 하는 어려움을 겪을 것입니다. 그냥 캔버스로 바로 이동합니다. 접근성/SEO가 이제 문제가 되지만 GDI를 사용하는 winforms에 액세스할 수 있는 것과 같은 방식으로 극복할 수 없는 이유를 알지 못합니다.

맞아 @yowl ... 시나리오에 따라 다릅니다. 간단한 LOB 응용 프로그램은 Ooui의 접근 방식과 매우 잘 작동합니다. 구체적으로 Ooui가 아니라 접근 방식(WebSocket 브리지)을 말합니다. Ooui는 합법적 인 초강대국이되는 것과는 거리가 멀습니다.

SkiaSharp는 웹에서 작동하지 않으므로 웹에서 실행하려면 다른 응용 프로그램이 있어야 합니다. 물론 WASM을 사용하지 않는 한. 그러나 그것은 더 큰 다운로드입니다. 요즘 모든 것이 HTML5/웹/경량화되고 있습니다. 더 빠르게 로드되고 더 빠른 응용 프로그램은 사용자를 확보하여 시장 견인력을 얻는 응용 프로그램이 될 것입니다. 우리는 PWA와 웹 기술 전체에서 이것을 보고 있습니다.

네이티브/스토어는 웹이 점점 더 그들과 유사해지고 그들의 힘을 차지함에 따라 지나쳐 가고 있습니다. 그리고 중앙 집중식/권한 부여/질식/검열/저장/등록/지침 BS 없이 부팅합니다. 😉 기술은 원래 설계, 의도 및 의도된 방식인 탈중앙화/자유로운 비즈니스 방식으로 다시 이동하고 있습니다.

그럼에도 불구하고 여기에는 궁극적으로 두 가지 시나리오가 있다는 데 동의합니다. 대부분의 응용 프로그램(접근성/SEO 😄이 필요함)을 위한 HTML5와 전문화/그래픽 집약적/게임 등을 위한 WASM입니다. 이상적인 프레젠테이션 기술은 개발자가 둘 중 하나의 차이점(예: 골치아픈)을 알거나 처리할 필요가 없도록 두 진영 모두에 원활하게 제공됩니다.

SkiaSharp는 웹에서 작동하지 않으며 내가 아는 한 아무도 wasm을 위해 구축하지 않았지만 Skia는 그렇게 한다고 나는 상상합니다. 또는 Skia 백엔드로 XF를 빌드해도 마찬가지입니다. 모노 사람들은 자신의 소매에 뭔가가 있다고 확신합니다. Build in May에서 뭔가를 찾으십시오.

예, //build가 흥미로운 것을 보여주기 위해 지금 _년_을 기다리고 있습니다, @yowl. 심지어 Connect(); 이벤트는 .NET을 웹 페이지(매우 높은 가치)가 아닌 냉장고 및 기타 기기(매우 낮은 가치)에서 실행하는 것에 대해 자랑하는 것으로 축소되었습니다.

요즘은 '보면 믿겠다'는 식으로 접근하고 있다. 😉 올해의 서커스에서 저는 Progressive Web Applications, 그리고 MSFT가 어떻게 .NET 개발자와 함께 작업하는 데 비용을 최대한 많이 들이면서도 이를 우리 생태계에 "통합"할 수 있었는지 외에 다른 중요한 소식을 듣게 될 것으로 기대하지 않습니다. 🎉 당신을 위한 약간의 낙관론이 있습니다. 🎉

Skia + Canvas는 http://webassembly.org에서 작동 http://webassembly.org/demo/Tanks/ 는 Skia 비즈니스 앱일 수도 있습니다.

@timahrentlov 스키아+캔버스? 10M 다운로드, 정말 큽니다.

xamarin.flutter는 어떻습니까?

@juepiezhongren 에 동의합니다 ,

흥미로운 토론. 한편 ListView와 같은 기본 컨트롤은 여전히 ​​iOS 및 Android에서 문제가 있습니다. XAML 미리 보기도 완전히 작동하지 않습니다. 아직 구현되지 않은 기본 컨트롤이 있습니다. 성능은 여전히 ​​뒤쳐져 있습니다. 이야기하고 꿈꾸는 것은 좋은데 XF의 상태는 거의 3년이 되었음에도 불구하고 실제로 있어야 할 위치가 아닙니다.

XF의 문제는 글레쳐 위에 집을 짓는 것과 같다는 것입니다. 그것은 거대한 UI 플랫폼 발자국을 가지고 있으며 아래에 균열과 틈새가 형성됩니다.

그것들을 수정하고 새로운 기능을 추가하는 것은 더 많은 플랫폼이 추가될수록 악화되는 끊임없는 오르막 싸움입니다. Mac OS x, OOUI/Web, Tizen 등. 그것은 멈출 것입니다. 거의 그랬습니다. DOA 방식입니다. 그리고 flutter와 같은 도구는 XF 주변에서 원을 그리며 실행됩니다.

XF는 자체 UI를 가져와 절대적으로 필요한 특정 플랫폼 UI만 통합해야 합니다. 지도, 카메라 보기 등. 머지 않아 Xamarin은 Fuchia 또는 호출되는 모든 것을 지원하려는 경우 어쨌든 구현해야 합니다(오픈 소스 플러터 엔진!).

나는 Flutter나 Tizen 또는 다른 것들에 대해서는 별로 신경 쓰지 않습니다. 모바일 개발 측면에서 중요한 것은 iOS와 Android뿐입니다. 그렇다면 아마도 UWP. 사람들의 말에도 불구하고 나는 Mac OS X와 ​​WPF에 대해 그다지 신경을 쓰지 않았습니다. 모바일(iOS와 안드로이드)도 제대로 다룰 수 없는 상황에서 모바일과 데스크톱을 하나로 통합하려는 것은 슬픈 일이다.
Xamarin Forms는 정말 모든 거래의 대가인 Jack의 가장 좋은 예입니다. 주말 프로젝트로 시작한 OSS 프로젝트입니다. 유일한 중요한 작업은 XAML 컴파일입니다.
그 외에 Xamarin은 개발자가 작업을 계속하기를 기다리고 있습니다. 프레임워크를 실제로 어떻게 만들어야 하는지에 대한 진지한 약속은 아직 없습니다.
빌드 회의가 다가오고 있으며 Xamarin Forms 3.0이 얼마나 훌륭한지 알릴 것입니다. 실제로는 여전히 동일한 버그와 제한 사항이 있습니다.

네이티브와 ubi가 모두 필요합니다. xf는 C#과 함께 모든 기본 API를 사용하기 때문에 충분히 좋습니다. 유비스도 중요합니다.

누군가 Xamarin Forms와 같은 많은 방향이 있는 다른 프로젝트/프레임워크/도구의 예를 제공할 수 있습니까? "길찾기"가 의미하는 것은 Android, iOS, UWP, Mac OS X, CSS, Flexbox, Tizen, WPF입니다. 내가 놓친 게 있니? 웹/HTML? 미친...
누군가가 계속해서 "오늘 우리가 할 수 있는 다른 게임이 있어요"라고 말하는 것과 비슷합니까? 누군가가 끊임없이 실험하는 것과 같습니다. 실험하는 것이 잘못된 것은 아니지만, 실제로 모든 것이 실험인데, 마치 단단한 것처럼 작업 중인 작업에 대해 이야기하는 것이 이상합니다.

XF가 iOS와 안드로이드에만 집중했다면..
MS가 자체 앱에 XF를 사용하기 시작했다면..
MS가 더 많은 리소스와 휴먼 테스터를 적용했다면..
Xamarin이 기술 이벤트를 주요 릴리스의 초점으로 만드는 데 열중하지 않았다면..
을 텐데..

지난 몇 년 동안 집에 어른이 아무도 없었던 것 같습니다. 누가 운전대를 잡고 코스를 계획했습니까? 무슨 코스?

릴리스는 기술 데모 품질을 가졌고 안정적인 것은 확실히 안정적이지 않았으며 물건은 일반 전략에 적합했기 때문에 릴리스된 것이 아니라 기술 전문가가 아이디어를 얻었고 그렇게 할 수 있었기 때문에 릴리스되었습니다. 그리고 기조연설에 대한 콘텐츠를 생성하는 것 외에도 XF는 우리 모두가 바라던 성공을 거두지 못했습니다. 지금쯤이면 그랬어야 했다.

나는 여전히 XF가 죽음의 문턱에서 벗어날 수 있기를 바라고 있습니다. 나는 여전히 어른이 운전을 해주기를 바라고 있다. 게임 후반에는 엄청난 노력이 필요합니다. 적어도 MS가 XF의 현재 UI 패러다임을 사용하여 성공하기를 원한다면.

MS는 스스로를 더 쉽게 만들 수 있고, 글쎄요, 플러터처럼 만들 수 있습니다. _XF는 자체 UI를 가져와야 합니다!_

지금 당장은 다트 쪽이 확실히 매력적으로 보입니다!

Microsoft는 Xamarin Forms에 대해 덜 신경 쓰지 않을 수 없었습니다. Microsoft는 Xamarin의 모바일 기능을 사용하여 .NET 과대 광고의 수준을 유지하고 전파하려고 시도하고 있습니다. Microsoft는 여전히 "개발자, 개발자, 개발자"라는 과거에 살고 있습니다. " 과대 광고 시대. 어느 쪽이 나쁘지 않은지, 나쁜 점은 지금 품질보다 과대 광고가 더 많다는 것입니다.
현실은 대부분의 개발자가 MacBook을 사용하며 오랫동안 Windows와 .NET에 대해 신경 쓰지 않는다는 것입니다. Microsoft는 모바일 및 하드웨어 분야에서 거의 모든 곳에서 실패했습니다. 그들은 과대 광고를 유지하기 위해 고군분투하지만 꽤 어려웠습니다. 관리 수준에서 Microsoft는 크게 실패했습니다. 오해하지 마세요. Microsoft에는 정말 훌륭한 기술 인력이 많이 있습니다. 저는 낮은 수준의 기술 인력에 대해 이야기하고 있습니다.

MS가 자체 앱에 XF를 사용하기 시작했다면..

어떻게 그럴 수 있었습니까? 성능은 있어야 할 곳에 있지 않습니다.

Reality is most of developers are on MacBooks 백업할 것이 있습니까?

당신은 그것을 뒷받침 할 것이 있습니까?

아니요, 하지만 가장 인기 있는 기술을 보면 해당 개발자의 대부분이 MacBook을 사용한다는 것을 확신할 수 있습니다.

@opcodewriter "인기 기술"이 "MacBook"과 어떤 관련이 있습니까? macOS에서 작동하는 대부분의 기능은 다른 Unix 기반 운영 체제에서도 작동합니다.

@encrypt0r 예, 저를 무시하십시오. 모든 것이 훌륭합니다. 👍

대 인기를 고려하면 대부분의 코더가 Mac을 사용하는 것이 어떻게 가능한가요?

파티에 조금 늦었지만 Xamarin도 이제 웹 기술에 참여하고 있습니다.
http://www.davidortinau.com/blog/styling_xamarin_forms_with_css

CSS를 Xaml 기반 기술에 결합하는 Frankenstein처럼 보이지만 이봐. 😉 또한 여기에 사용된 CSS는 CSS처럼 읽는 Xamarin 컨트롤 스타일을 위한 DSL에 가깝습니다. 어쨌든 요점은 WHEN USED CORRECTLY 😆 어디에서나 장치에서 사용할 수 있는 성숙한 표준입니다.

여기에 대한 몇 가지 추가 토론:
https://twitter.com/migueldeicaza/status/972525236301238272

@Mike-EEE, draw 및 materialShell 문제를 본 적이 있습니까?

@juepiezhongren 이 없습니다 ... 이것은 HTML 또는 Forms와 관련이 있습니까?

@마이크-이
https://github.com/xamarin/Xamarin.Forms/issues/2452
https://github.com/xamarin/Xamarin.Forms/issues/2415

그건 환상적이야

예, @juepiezhongren은 나쁘지 않지만 처음부터 유비쿼터스하지 않은 경우 시간/돈/노력/자원의 가치가 없습니다. :)

Material Shell은 이 문제와 관련이 있지만 여전히 스타일이 지정된 기본 컨트롤이며 진정한 유비쿼터스 컨트롤은 아닙니다.

@juepiezhongren
나는 당신이 그것을 배치한 방식은 아니지만 개념을 좋아합니다.

내 꿈에서 Avalonia와 같은 프레임 워크는 완벽한 옵션입니다. 네이티브 룩앤필은 저에게 그다지 큰 관심사가 아닙니다. 컨트롤이 필요한 사람들을 위해 각 플랫폼에 기본 모양과 느낌 테마를 추가할 수 있는 옵션과 함께 모든 곳에서 동일하게 렌더링되는 컨트롤을 선호합니다.
그것이 wasm 지원을 받는 즉시 Silverlight가 돌아오고 RIA Services를 그리워하는 일만 남습니다 😁

@MisterJimson 실제로 아이디어는 재료 쉘이 본질적으로 유비쿼터스 컨트롤을 제공한다는 것입니다.

@jassmith 정확히 어떻게? 원시 컨트롤을 렌더링하거나 기본 컨트롤을 스타일링하시겠습니까? 기본 컨트롤 스타일 지정에는 최소한의 경우에도 항상 약간의 불일치가 있습니다.

@MisterJimson 쉘은 skia 또는 ios CoreDraw API를 기반으로 한다고 생각합니다.
@jassmith 그래서 fluentShell 또는 cupertinoShell이 ​​있습니까?

@misterJimson as @juepiezhongren 네, 아이디어는 처음부터 완전히 그립니다. 그것은 대상 플랫폼에 그릴 수있을 실 거예요하지만 당신은 확실히 그것을 요청할 수 있습니다. 목표는 Material(최소한 MaterialShell 포함)을 모든 곳에 가져오는 것입니다.

@juepiezhongren 이상적으로는 그렇습니다. 현재 문제는 FluentShell과 CupertinoShell이 ​​모두 라이브 블러에 크게 의존한다는 것입니다. Android는 훌륭하지만 어떻게든 효율적인 라이브 블러 보기를 피하는 데 성공했습니다. 이 문제에 대해 정확히 무엇을 해야 하는지 알아내는 동안 Material은 자연스러운 첫 번째 대상이 되었습니다.

분명히 하자면, Shell은 그리기를 하지 않고 MaterialShell은 합니다.

이거 봤어- https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample ?
모바일 플랫폼이 아닌 데스크탑 전용입니다.

@gulshan 서버 측이 좋습니다

@juepiezhongren에 대한 생각
https://github.com/xamarin/Xamarin.Forms/issues/4435

태그가 되는 대신 어디에나 존재하는 속성이라는 점을 제외하고 여기에서 제안한 것과 유사하며 누군가가 관심이 있다면 Visual="Skia"를 만들 수 있습니다.

@PureWeen 나는 visual="skia"를 좋은 제안으로 취급하지 않습니다. 단순히 현재 xf의 컨트롤에는 개인 사용자 정의를 위한 두 가지 속성이 부족하기 때문입니다. 브러시, controlTemplate 등

또는 현재 컨트롤을 전체 API로 구현하고 래퍼 모드 동안 유효하지 않은 많은 속성을 만들고 skia 모드 동안 유효하게 만듭니다.

우리는 지난 몇 달 동안 Visual에서 많은 발전을 이루었습니다. 우리는 그것에 대한 귀하의 피드백을 받고 싶습니다. Visual Challenge를 시도해 보고 이 제안을 하게 된 문제가 해결되었는지 알려주십시오. 감사 해요! https://github.com/davidortinau/VisualChallenge

@samhouts 비주얼은 좋지만 그리기가 필요하고 완벽한 픽셀 솔루션이 필요합니다.

그렇다면 이 개선 요청은 시각적 및 도면 사양 https://github.com/xamarin/Xamarin.Forms/issues/2452 에 대해 보류될 때 어디에 해당합니까?

단순히 현재 xf의 컨트롤에 개인 사용자 정의를 위한 두 가지 속성이 부족하기 때문입니다. 브러시, controlTemplate 등

이것은 여기에서 달성할 수 있는 가장 좋은 방법을 찾는 연결된 속성을 통해 매우 쉽게 극복됩니다.

https://github.com/xamarin/Xamarin.Forms/issues/5005

@samhouts

우리는 지난 몇 달 동안 Visual에서 많은 발전을 이루었습니다.

저희는 Windows와 데스크탑을 최우선으로 생각합니다. Visual은 UWP를 지원하지도 않으며 시도조차 하지 않습니다.

#2452에서 진행 중이므로 이제 이 작업을 종료할 수 있다고 생각합니다. 감사 해요!