มีแนวโน้มสำหรับชุดเครื่องมือ GUI ข้ามแพลตฟอร์มหรือไม่ [ปิด]


12

แนวโน้มเช่นนี้สำหรับการใช้เฟรมเวิร์ก GUI ข้ามแพลตฟอร์มในขณะนี้คืออะไร? ผู้คนจำนวนมากเริ่มใช้เฟรมเวิร์กข้ามแพลตฟอร์ม (เช่น GTK +, Qt และ wxWidgets) หรือมีผู้ใช้เฟรมเวิร์กที่เชื่อมโยงกับแพลตฟอร์มมากขึ้น (เช่น Cocoa หรือ WPF) หรือไม่ มันมากขึ้นหรือน้อยลง? มันเหมือนรถไฟเหาะไหม? คุณคิดว่าแนวโน้มจะเป็นเช่นไรพูดอีก 5 ปีจากนี้?

ภูมิทัศน์ระบบปฏิบัติการกำลังขยับโดยมีผู้ใช้ Windows น้อยลง (การสังเกตส่วนตัว) สิ่งนี้จะเพิ่มความต้องการชุดเครื่องมือข้ามแพลตฟอร์มใช่หรือไม่

แก้ไข: นอกจากนี้ชุดเครื่องมือ (ข้ามแพลตฟอร์ม) กำลังเติบโตมากที่สุดถ้าใช่

คำตอบ:


11

ดูเหมือนว่ามีแนวโน้มว่าจะมีชุดคิทข้ามแพลตฟอร์ม หากผู้คนต้องการที่จะเขียนครั้งเดียวทำงานได้ทุกที่พวกเขามักจะใช้ 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 ดังนั้นฉันเห็นความท้าทายด้านเทคนิคที่นี่โดยตรง


2
ฉันจะใช้ถ้อยคำนี้อย่างง่าย ๆ ว่า "แนวโน้มสำหรับชุดเครื่องมือข้ามแพลตฟอร์มนั้นมีความล้มเหลว"
ohmantics

14

ตามความเป็นจริงมีแนวโน้มไปสู่ชุดเครื่องมือ UI ข้ามแพลตฟอร์มในปีที่ผ่านมา ชุดเครื่องมือนั้นคือ HTML / CSS / JavaScript

มันง่ายกว่ามากในการพัฒนาเพียงครั้งเดียวและเห็นว่ามันทำงานเกือบเหมือนกันทุกหนทุกแห่ง

และใช่แล้วการพัฒนากำลังเคลื่อนห่างจากเดสก์ท็อปสู่เว็บ คุณเห็นมันเอง


+1 สำหรับเว็บที่เป็นแนวโน้ม UI ที่เพิ่มขึ้น แต่ฉันไม่คิดว่าสิ่งนี้จะตอบคำถามของ OP

Totaly เห็นด้วย เราพัฒนาแอปพลิเคชั่น IPTV ของเราบนกล่อง Settop ทั้งหมดโดยใช้ HTML5 / CSS3 / JavaScript นั่นคืออนาคตไม่ใช่กรอบ C / C ++ ขนาดใหญ่ที่เต็มเปี่ยม
Ernelli

1
พูดถึงได้ดี แต่จริงๆแล้วฉันสนใจชุดเครื่องมือเดสก์ท็อปข้ามแพลตฟอร์ม ยังคงถูกโหวต
Anto

@Anto - อาจต้องการเพิ่มคำถามของคุณ จากการอ่านฉันไม่ได้รับ "เดสก์ทอป" เลย แน่นอนผมโปรแกรมเมอร์เว็บและไม่รู้จักมากที่สุดของกรอบที่คุณกล่าวถึง :)
มาร์ซี่

@ ถึงคุณอาจต้องการพูดถึงเดสก์ท็อปในคำถามของคุณ
JBRWilkinson

7

ฉันมักจะใช้ชุดเครื่องมือข้ามแพลตฟอร์มเพราะมีการออกแบบที่ดีกว่าไม่ใช่เพราะฉันพยายามเป็นแพลตฟอร์มข้าม ตัวอย่างเช่นฉันทำงานกับโปรเจ็กต์ที่เขียนด้วย C ++ ซึ่งกำหนดเป้าหมายเป็นแพลตฟอร์ม Windows เท่านั้น ฉันใช้ win32 หรือ MFC ตัวเลือกเท่านั้นที่ใช้ได้กับชุดเครื่องมือพื้นเมืองหรือไม่

fsck ศักดิ์สิทธิ์ไม่! พวกมันเป็นกองขยะปาเก็ตตี้ที่แย่ที่สุดที่ฉันเคยเห็น! การเชื่อมต่อโดยตรงของระบบเหตุการณ์เข้ากับระบบ "ข้อความ" ของระบบปฏิบัติการนั้นไม่ได้ใช้งานง่ายและขาดความจำเป็นในการสร้างโปรแกรม UI อย่างรวดเร็ว abstractions ระดับที่สูงขึ้นซึ่งในปัจจุบันจัดทำโดยชุดเครื่องมือข้ามแพลตฟอร์มเป็นสิ่งจำเป็นอย่างยิ่งสำหรับงาน

นั่นเป็นเพียงตัวอย่างเดียว ฉันสามารถสั่นสะเทือนและในรายการสิ่งที่ทำได้ดีกว่าโดยชุดเครื่องมือข้ามแพลตฟอร์ม ความจริงก็คืออินเทอร์เฟซแบบกราฟิกจะคล้ายกันมากกว่าชัดเจน มีความแตกต่างกันเล็กน้อยระหว่างโปรแกรมหน้าต่างบน Windows กับอีกโปรแกรมหนึ่งบน Linux ชนิดของสิ่งที่คุณทำเมื่อสร้างโปรแกรม UI นั้นเกือบจะเหมือนกันทุกประการไม่ว่าคุณจะกำหนดเป้าหมายเป็นระบบปฏิบัติการ ... และมีความแตกต่างเพียงเล็กน้อยระหว่างสถาปัตยกรรมเช่นโทรศัพท์ / ฝ่ามือกับเดสก์ท็อป ฟิลด์นี้เน้นที่วิธีการข้ามแพลตฟอร์มเพราะก) มันเป็นสิ่งที่จำเป็นสำหรับผู้คนจำนวนมากและข) มันก็เหมือนกันทั้งหมด!


0

อาร์กิวเมนต์หนึ่งที่ต่อต้านการสร้างเฟรมเวิร์กข้ามแพลตฟอร์มคือมันจะถูกกำหนดเป้าหมายที่ตัวหารร่วมที่ต่ำที่สุดเสมอ - ไคลเอนต์ของเฟรมเวิร์กต้องการเขียนโค้ดเพียงครั้งเดียวและสนับสนุน 'ทุกหนทุกแห่ง' ดังนั้นแพลตฟอร์มฮาร์ดแวร์หนึ่งที่ยอดเยี่ยมก็จะดูเหมือนแพลตฟอร์มอื่น ๆ ที่รันเฟรมเวิร์กนั้นเนื่องจากคุณไม่สามารถใช้ประโยชน์จากคุณสมบัติเฉพาะแพลตฟอร์มได้

เมื่อเวลาผ่านไปสิ่งนี้น่าเสียดายที่เฟรมเวิร์กเอนไปสู่แพลตฟอร์มที่ได้รับความนิยมสูงสุดและการแฮ็คเข้าด้วยกันสนับสนุนแพลตฟอร์มอื่น ๆ หรือเพียงแค่ตัดพวกเขาออกเมื่องบประมาณ / ความนิยมหมดไป

วิธีหนึ่งที่จะใช้ประโยชน์จากความสามารถเฉพาะแพลตฟอร์มคือการสร้างสิ่ง#if PLATFORM_FEATURE_Xรอบตัวรหัสเฉพาะหรือการตรวจสอบรันไทม์ที่เทียบเท่าซึ่งส่งผลให้เกิดการขยายตัวของรหัส สิ่งนี้ค่อนข้างน่าเบื่ออย่างรวดเร็วเนื่องจากความหลากหลายของแพลตฟอร์มเดียวกันจะต้องการการจัดการที่เฉพาะเจาะจง ตัวอย่างเช่น XBox v1 บางรุ่นไม่มีฮาร์ดไดรฟ์ดังนั้นเกมที่ใช้เครื่องมือข้ามแพลตฟอร์มไม่สามารถใช้แคชได้เมื่อเปรียบเทียบกับพีซีเวอร์ชันที่คุณสามารถรับประกันฮาร์ดไดรฟ์

สำหรับแอปพลิเคชันบนเดสก์ท็อป / เพิ่มประสิทธิภาพดูเหมือนว่ารูปลักษณ์และความรู้สึกของแพลตฟอร์มจะมีความสำคัญ แต่แอพพลิเคชั่นจำนวนมากมีสไตล์เป็นของตัวเอง

ผู้จำหน่ายฮาร์ดแวร์เช่น Apple, Sony, Nintendo และ Toshiba จะต้องการให้แน่ใจว่าผลิตภัณฑ์ของตนทำสิ่งที่แตกต่างจากคู่แข่งเช่น Touch, Accelerometers / Gryoscopes, Blu-Ray, จอแสดงผล 3 มิติ ไม่น่าเป็นไปได้ที่จะมีแพลตฟอร์มที่มีคุณสมบัติทั้งหมดของคู่แข่งทั้งหมดที่รวมอยู่ในที่เดียว (เนื่องจากต้นทุนและความซับซ้อน) ดังนั้นจึงจะชนะได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.