현재 크로스 플랫폼 GUI 프레임 워크를 사용하는 경향은 무엇입니까 ? 더 많은 사람들이 크로스 플랫폼 프레임 워크 (GTK +, Qt 및 wxWidgets)를 사용하기 시작하거나 더 많은 플랫폼 연결 프레임 워크 (예 : Cocoa 또는 WPF)를 사용하는 사람이 더 있습니까? 다소 정체되어 있습니까? 롤러 코스터 같은가요? 예를 들어 지금부터 5 년 후에는 어떤 추세가 될 것이라고 생각하십니까?
Windows를 사용하는 사람이 적을수록 OS 환경이 바뀌고 있습니다 (개인 관찰). 이것은 크로스 플랫폼 툴킷에 대한 수요를 증가시킬 것입니다.
편집 : 또한 어떤 플랫폼 간 툴킷이 가장 많이 성장하고 있습니까?
답변:
크로스 플랫폼 키트에 대한 경향이있는 것 같습니다. 사람들이 한 번 작성하고 어디서나 실행하고 싶다면 HTML을 사용하는 경향이 있습니다. 웹 사이트를 만드십시오. 사람들은 예를 들어 iPhone과 같은 기본 모양과 느낌이 요구 될 때만 플랫폼 툴킷을 사용합니다. 따라서 웹 이외의 앱으로 고민하는 모든 이유가 기본 모양과 느낌을 얻는 것이라면 크로스 플랫폼 키트를 사용하는 것이 의미가 없습니다.
크로스 플랫폼 툴킷은 그다지 잘 작동하지 않았습니다. 데스크탑 플랫폼은 그다지 유사하지 않으며, 진정으로 추상화하기가 어렵습니다. 휴대 전화와 태블릿을 믹스에 추가하면 더 어려워집니다. 결과적으로 유출이 매우 심해집니다 ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html 참조 ). "엔진"을 UI에서 깔끔하게 분리하고 플랫폼별로 UI를 작성하는 것이 더 쉬운 경우가 많습니다.
Mac의 인기가 높아지면서 크로스 플랫폼 키트는 인기가 떨어질 수 있습니다. 사람들은 크로스 플랫폼 키트를 사용하여 모든 플랫폼에서 진정으로 좋은 결과를 얻는 것보다 크로스 플랫폼 확인란을 이론적으로 선택했다고 생각합니다. 실제로 여러 플랫폼에 관심이 있다면 ... 크로스 플랫폼 키트의 단점을 파악하기 시작합니다.
다음은 이러한 단점에 대한 Alex Payne의 블로그 게시물입니다. http://al3x.net/2011/01/15/user-hostile-platforms.html
많은 인기있는 크로스 플랫폼 앱이 자체 크로스 플랫폼 접근 방식을 개발한다고 말합니다 (Firefox, Chrome, Eclipse, OpenOffice.org는 염두에 두는 예입니다). 프레임 워크를 소유함으로써 필요할 때 추상화를 통해 펀치 다운 할 수 있습니다. 또한 이러한 응용 프로그램은 모든 플랫폼에서 동일하고 특히 고유하지 않은 것처럼 보입니다.
이 모든 것은, 나는 실제 통계 또는 아무것도 없습니다. 그러나 GTK +에서 많은 작업을 수행했으며 Firefox, Chrome 및 Eclipse를 포함한 코드베이스에 익숙합니다. 그래서 여기서 기술적 과제를 직접 보았습니다.
실제로 최근 몇 년간 크로스 플랫폼 UI 툴킷으로 향하는 경향이있었습니다. 해당 툴킷은 HTML / CSS / JavaScript입니다.
한 번 개발하는 것이 훨씬 간단하고 거의 모든 곳에서 동일하게 실행되는 것을 보았습니다.
그렇습니다. 개발은 데스크탑에서 웹으로 크게 이동하고 있습니다. 당신은 그것을 자신을 참조하십시오.
나는 크로스 플랫폼 툴킷을 사용하는 경향이 있습니다. 크로스 플랫폼 툴킷을 사용하려는 것이 아니라 더 나은 디자인을 가지고 있기 때문입니다. 예를 들어, 저는 Windows 플랫폼만을 대상으로하는 C ++로 작성된 프로젝트에서 작업합니다. 기본 툴킷에 사용할 수있는 유일한 옵션 인 win32 또는 MFC를 사용합니까?
이런 fsck 아니! 그들은 내가 본 것 중 최악의 스파게티 쓰레기 더미입니다! 기본 OS의 "메시지"시스템에 이벤트 시스템을 직접 연결하는 것은 매우 직관적이지 않으며 UI 프로그램을 빠르게 작성하는 데 필요한 표현력이 부족합니다. 현재 크로스 플랫폼 툴킷에서만 제공되는 상위 레벨 추상화는 작업에 절대적으로 필요합니다.
그것은 단지 하나의 예일뿐입니다. 크로스 플랫폼 툴킷으로 더 잘 수행 할 수있는 작업 목록을 적어 놓을 수 있습니다. 사실 그래픽 인터페이스는 서로 다른 인터페이스와 비슷합니다. 예를 들어 Windows의 윈도우 프로그램과 Linux의 윈도우 프로그램 사이에는 차이가 거의 없습니다. UI 프로그램을 만들 때 수행하는 작업은 대상 OS에 상관없이 거의 항상 동일하며 전화 / 팜 및 데스크톱과 같은 아키텍처 간의 사소한 차이 만 있습니다. 이 분야는 단순히 a) 많은 사람들에게 필요하고 b) 모두 같은 sh! t이기 때문에 크로스 플랫폼 방법론에 중점을 두었습니다.
크로스 플랫폼 프레임 워크 생성에 대한 한 가지 주장은 항상 가장 낮은 공통 분모를 목표로한다는 점입니다. 프레임 워크의 클라이언트는 코드를 한 번만 작성하고 '모든 곳에서'지원됩니다. 따라서 하나의 멋진 하드웨어 플랫폼은 플랫폼 별 기능을 활용할 수 없으므로 해당 프레임 워크를 실행하는 다른 플랫폼과 같습니다.
시간이 지남에 따라 불행히도 프레임 워크는 가장 인기있는 플랫폼에 기대어 다른 플랫폼에 대한 지원을 해킹하거나 예산 / 인기가 소진 될 때 프레임 워크를 제거합니다.
플랫폼 별 기능을 활용하는 한 가지 방법은 #if PLATFORM_FEATURE_X모든 특정 코드 또는 동등한 런타임 확인을 중심 으로 구성을 작성하여 코드 팽창을 유발하는 것입니다. 동일한 플랫폼의 변형에는 특정 처리가 필요하므로 매우 지루합니다. 예를 들어, 일부 XBox v1에는 하드 드라이브가 없었으므로 크로스 플랫폼 도구를 사용하는 게임에서는 하드 드라이브를 보장 할 수있는 PC 버전과 비교하여 캐싱에 사용할 수 없었습니다.
데스크톱 / 생산성 응용 프로그램의 경우 플랫폼 모양과 느낌이 중요해 보이지만 많은 응용 프로그램의 스타일이 고유하므로 AIR를 사용하여 제작 된 응용 프로그램과 같은 모든 플랫폼에서 동일하게 보이는 것은 문제가되지 않습니다.
Apple, Sony, Nintendo 및 Toshiba와 같은 하드웨어 공급 업체는 Touch, Accelerometers / Gryoscopes, Blu-Ray, 3D 디스플레이와 같이 자사 제품이 경쟁 업체와 차별화 할 수있는 제품을 제공하기를 원할 것입니다. 모든 경쟁 업체의 모든 기능을 하나로 묶은 플랫폼이있을 가능성은 낮습니다 (비용과 복잡성으로 인해).