วิธีการติดตามการพัฒนาแอปพลิเคชันที่กำหนดเป้าหมายหลายแพลตฟอร์ม

สำหรับแอปพลิเคชันที่กำหนดเป้าหมายหลายแพลตฟอร์มฉันเห็นสองแนวทางการพัฒนา -

• ใช้แพลตฟอร์มการพัฒนาแบบ JAVA มีโซลูชันรหัสเดียวและให้รันไทม์ระดับกลางจัดการแพลตฟอร์มที่แตกต่างกัน หากมีสิ่งใดผิดพลาดในแพลตฟอร์มใด ๆ ให้ปรับแต่งโค้ดเล็กน้อย แต่เก็บไว้เหมือนกันสำหรับทุกคน

• สร้างรหัสแยกส่วนตรรกะหลักและ UI พัฒนา UIs แยกต่างหากสำหรับแพลตฟอร์มที่เกี่ยวข้องซึ่งจะเรียกไลบรารีหลักเดียวกัน สร้างแอปพลิเคชันแยกต่างหากสำหรับแต่ละแพลตฟอร์มเป้าหมาย

ดังนั้นอันไหนที่ควรติดตาม? ฉันรู้คำตอบจะเริ่มต้นด้วย " มันขึ้นอยู่กับ " แต่ฉันต้องการฟังความคิดเห็นของคุณเกี่ยวกับวิธีการเหล่านี้และปัจจัยที่ต้องพิจารณาเพื่อเลือกสิ่งใด

การทะเลาะกันระหว่าง Oracle / Apache / Google ปัจจุบันก็ยังยากที่จะเอาชนะ JVM เพื่อจุดประสงค์นี้ มันมีคุณภาพสูงมากในแพลตฟอร์มส่วนใหญ่ทั่วไปและคุณมีภาษาให้เลือกมากมาย (Java, Clojure, Scala และอื่น ๆ ) ช่วยให้คุณกำหนดเป้าหมายสถาปัตยกรรมเครื่องเดียว (VM) และไม่ต้องกังวลมากเกินไปเกี่ยวกับฮาร์ดแวร์ของผู้ใช้ปลายทางเฉพาะ

ที่กล่าวว่ามีแอปพลิเคชั่นบางประเภทที่อาจไม่เหมาะสำหรับ: เครือข่ายระดับต่ำมาคำนึงถึงเช่นเดียวกับการประมวลผลกราฟิก / วิดีโอขนาดใหญ่

ไปสำหรับ HTML5 แพลตฟอร์มใด ๆ ที่มีเบราว์เซอร์ HTML5 สามารถเรียกใช้แอปพลิเคชันของคุณ แม้ว่า HTML5 จะยังไม่พร้อมเป็นครั้งใหญ่

ในโปรแกรมแก้ไขเสียงความกล้าเราใช้ wxWidgets เป็นห้องสมุดข้ามแพลตฟอร์มของเรา เนื่องจากเราต้องการเชื่อมโยงไปยังไลบรารี C และเราต้องการความเร็วและการเข้าถึงระดับต่ำแนวทาง JVM จะไม่ทำงานสำหรับเรา รหัส GUI 95% เหมือนกันในทุกแพลตฟอร์ม เราใช้ #ifdefs สำหรับรูปแบบขนาดเล็ก อย่างไรก็ตามเราพบว่าจำเป็นที่จะต้องมีนักพัฒนาซอฟต์แวร์ที่ทำงานบนแต่ละแพลตฟอร์มทั้งสาม (Mac, Windows Linux) เพราะแม้แต่การใช้ไลบรารีข้ามแพลตฟอร์มมันง่ายเกินไปที่จะเปลี่ยนเครื่องหนึ่งเพื่อแยกสิ่งอื่น

หากคุณได้รับประสิทธิภาพที่คุณต้องการให้ไปที่ JVM ถ้าคุณทำไม่ได้ให้ใช้ QT หรือ wxWidgets และฉันอยากจะแนะนำ QT มากกว่า wxWidgets เพราะมันใช้งานได้น้อยกว่าเพื่อให้มันดูดี

ในฐานะนักพัฒนาเรียลไทม์ฉันได้ใช้ตัวเลือกที่คล้ายกับ 2 - แยกโมดูลเฉพาะแพลตฟอร์มกับ API ทั่วไปที่ใช้โดยแกนตรรกะ อย่างไรก็ตามไม่มีสิ่งใดที่ฉันทำมี UI - เครือข่าย, เสียง, การสตรีมข้อมูล - ในกรณีนี้มันเป็นอินเตอร์เฟสฮาร์ดแวร์ระดับต่ำที่เป็นแพลตฟอร์มเฉพาะ

ฉันทำแบบนี้ด้วยเหตุผลหลายประการ:

1) เพื่อให้ได้ประสิทธิภาพสูงสุดในแต่ละแพลตฟอร์ม

2) เพื่อใช้ประโยชน์จากคุณสมบัติที่มีให้เฉพาะบน 1 แพลตฟอร์ม

3) (J) VMs ไม่มีอยู่สำหรับบางแพลตฟอร์ม (ระบบฝังตัวคอนโซลเกม ... )

มันขึ้นอยู่กับสิ่งที่สำคัญสำหรับคุณ :)

เมื่อเราเผชิญกับตัวเลือกนี้สำหรับแอพ Mac / Windows ข้ามแพลตฟอร์มเมื่อประมาณ 10 ปีที่แล้วเราได้ดูรอบตัวเลือกข้ามแพลตฟอร์มที่หลากหลาย - Java, Qt, wxWidgets เป็นต้นปัญหาที่เรามีคือรูปลักษณ์และความรู้สึกของ UI นั้นสำคัญสำหรับเรามากและแอพ "ข้ามแพลตฟอร์ม" ทั้งหมดก็ดูดี เราลงเอยกัดกระสุนและสร้างคอร์ข้ามแพลตฟอร์มของเราเองพร้อม UI แบบกำหนดเองสำหรับแต่ละแพลตฟอร์มด้านบน (เขียนใน PowerPlant สำหรับ Mac และ MFC บน Windows) เมื่อเวลาผ่านไปเรามีดีที่นี้และส่วน "ข้ามแพลตฟอร์ม" มีความหนาโดยไม่สูญเสีย UI

ตอนนี้เรากำลังพิจารณาการตัดสินใจครั้งนี้อีกครั้งสำหรับโครงการใหม่ ดูที่ตัวเลือกตอนนี้ฉันอาจจะไปกับ Qt - ได้ฟรีและดูเหมือนว่าจะสุกเต็มที่ Java อาจเป็นตัวเลือก แต่เราไม่สามารถใช้ประสิทธิภาพได้อย่างแท้จริง (เรากำลังทำการประมวลผลภาพ 3 มิติ)

หาก UI มีความสำคัญต่อคุณจริงๆฉันคิดว่าคุณจะต้องลงทุนค่อนข้างมากในการทำให้สิ่งต่าง ๆ ดูถูกต้องในแต่ละแพลตฟอร์มไม่ว่าคุณจะใช้ Qt หรือม้วนของคุณเอง สำหรับแอปภายในหรือผู้เชี่ยวชาญที่ผู้ใช้อาจยอมรับ UI ที่ขัดน้อยกว่านี้ก็อาจใช้ได้!

ทุกคนสร้างความกังวลอย่างมากเกี่ยวกับภาษาเช่น Java ที่เป็น "แพลตฟอร์มข้าม" แต่สิ่งที่พวกเขาพูดถึงคือคุณสามารถรวบรวมและเรียกใช้ทุกที่ แม้แต่ในภาษาอย่าง Java (หรือ C # / mono) คุณยังคงต้องการเลเยอร์นามธรรมเพื่อจัดการกับรายละเอียดเฉพาะของระบบปฏิบัติการในบางพื้นที่

C ++ และในความเป็นจริงภาษาส่วนใหญ่เป็นแพลตฟอร์มข้ามคุณเพียงแค่ต้องคอมไพล์เพื่อกำหนดเป้าหมายแต่ละแพลตฟอร์ม

คีย์คือกระบวนการแทนที่จะใช้เครื่องมือ / ภาษา:

1. ตรวจสอบให้แน่ใจว่าคุณมีการสร้างกระบวนการบูรณาการที่สร้างและวิ่งทดสอบหน่วยสำหรับแพลตฟอร์มเป้าหมาย
2. ตรวจสอบให้แน่ใจว่านักพัฒนาซอฟต์แวร์ทุกคนทำการทดสอบบนแพลตฟอร์มเป้าหมายทั้งหมดก่อนที่จะเช็คอินรหัส - ซึ่งหมายถึงการทำให้แน่ใจว่านักพัฒนาซอฟต์แวร์สามารถเข้าถึงจำนวนเครื่อง / vms ที่เหมาะสม
3. บทคัดย่อดี สรุปทุกอย่างที่เรียกว่า apis พื้นเมือง เขียนไลบรารีที่ล้อมสายเหล่านี้
4. หากคุณกำลังทำสิ่งใด ๆ นอกเหนือจากรูปแบบ UI ที่ค่อนข้างเรียบง่ายซึ่งเป็นเพียงส่วนสำคัญสำหรับตัวหารร่วมที่ต่ำที่สุดให้ยอมรับว่ารหัส GUI นั้นไม่ได้ข้ามแพลตฟอร์ม สรุปเลเยอร์ GUI / งานนำเสนอของคุณออกมาและกำหนดรหัสแยกต่างหากสำหรับแต่ละแพลตฟอร์ม ใช่มีชุดเครื่องมือ GUI ข้ามแพลตฟอร์มซึ่งใช้ได้สำหรับแอปส่งต่อตรง แต่ถ้าคุณทำอะไรขั้นสูงกว่านี้คุณจะต้องใช้รหัสในความสามารถของแพลตฟอร์มดั้งเดิม

ขั้นตอนเหล่านี้เหมือนกันไม่ว่าคุณจะใช้ภาษา / ชุดเครื่องมือ / กรอบอะไร

ใช้ประโยชน์จากเว็บ!

อย่างจริงจังถ้าคุณต้องการที่สุดของเจ้าชู้เขียนเว็บแอปพลิเคชัน

ทำไม?

• ลูกค้าเว็บไม่ต้องการพลังพีซีมากนัก
• เว็บไคลเอ็นต์อยู่ทุกที่ ไม่เพียงแค่ PC / MAC / Linux แต่บนโทรศัพท์มือถือและอื่น ๆ
• ไม่มีอะไรพิเศษที่จะดาวน์โหลดสำหรับผู้ใช้! (โดยทั่วไปแล้วถ้าคุณไม่ต้องการสิ่งที่แปลกใหม่และใช้แฟลชหรือ Silverlight)
• ส่วนประกอบทั่วไปทั้งหมดอยู่ที่ฝั่งเซิร์ฟเวอร์และสามารถเป็น Java, .NET, PHP หรือเป็นส่วนประกอบของส่วนประกอบที่มีอยู่เดิมที่คุณมี ลูกค้าไม่ควรสนใจ!

แม้แต่สองวิธีที่คุณพูดถึงก็คล้ายคลึงกันมาก เว็บเบราว์เซอร์แสดงผล HTML สำหรับสถาปัตยกรรมพื้นฐานหลายรายการ ในทำนองเดียวกัน JVM ตีความโค้ด Java ในลักษณะที่เหมาะสมสำหรับฮาร์ดแวร์ที่เกี่ยวข้อง อย่างไรก็ตามเว็บมีฐานลูกค้าที่กว้างขึ้น!

ฉันโชคดีกับโมโน ฉันสามารถเขียนรหัสเดียวกันสำหรับเครื่อง windows เช่นเดียวกับเครื่อง Linux และส่วนใหญ่ทำงานได้ทั้งสองอย่าง และฉันสามารถใช้ทักษะที่ฉันรู้จักใน C # และ Winforms ได้แล้ว

ทำหลักฐานแนวคิดก่อน

ถ้ามันเป็นแอพพลิเคชั่นที่ซับซ้อนพอสมควรการพิสูจน์หลักฐานของแนวคิดจะทำให้คุณเข้าใจว่าคุณต้องการใช้ภาษาอะไรและคุณต้องใช้ประโยชน์จากกรอบงานหรือห้องสมุดของบุคคลที่สามแบบใด

ฟีเจอร์ภาษาและไลบรารีที่คุณต้องการจะกำหนดภาษาที่คุณจะต้องเลือก (ดังนั้นคุณจะเข้าไปใกล้การสนับสนุนข้ามแพลตฟอร์ม)

ฉันสร้างระบบโดยเริ่มจากแอปเดสก์ท็อปเมื่อ 15 ปีก่อนเมื่อ Java ยังอยู่ในช่วงเริ่มต้นและยังไม่พร้อมที่จะใช้ในการสร้างแอพประเภทนี้ ฉันรู้ว่าฉันต้องมีคอร์ใน C ++ และออกแบบมันตั้งแต่เริ่มต้นจนถึงข้ามแพลตฟอร์มรวมถึงการใช้งานขนาดต่าง ๆ (เช่น int32 แทนที่จะเป็น int หรือยาว) ดังนั้นมันจึงสามารถทำงานบน Mac, Windows และ UNIX (pre-Linux วัน)

ตอนที่ฉันพยายามมองหาสภาพแวดล้อม UI ข้ามแพลตฟอร์มที่ดีมีอยู่สองสามอย่างรวมถึง XVT ฉันผ่านการฝึกอบรมสำหรับ XVT และเมื่อฉันเริ่มสร้างแอปจริงฉันรู้ว่าฉันจะไม่สามารถสร้างรูปลักษณ์และความรู้สึกที่สะอาดเป็นธรรมชาติบนแพลตฟอร์ม (เริ่มต้นด้วย Mac) ดังนั้นฉันจึงเลิกใช้ความคิดนั้นและสร้าง UI ดั้งเดิมของ Mac (PowerPlant) ที่ด้านบนของคอร์แบบพกพา

สองสามปีต่อมาเราย้ายเข้าสู่ Windows (UI ใน MFC) มันเร็วกว่าการสร้าง UI ในครั้งที่สองเราทำการบำรุงรักษา Mac และ Windows UI ควบคู่กันในช่วงเวลาสั้น ๆ จากนั้นไปที่ Windows แกนกลางได้ย้ายไปสู่รสชาติต่าง ๆ ของ UNIX และ Linux เพื่อให้เราเรียกใช้การคำนวณบนเซิร์ฟเวอร์ แกนทำพอร์ตได้ดีโดยมีการปรับเปลี่ยนบางอย่างเมื่อเราเตรียมให้พร้อม 64- บิต

ตอนนี้ฉันกลับมาใช้ Mac และฉันหวังว่าเราจะได้กลับมาที่ Mac แต่ขนาดและความซับซ้อนของแอพทำให้เป็นตัวเลือกที่ยาก มันยังคงสมเหตุสมผลสำหรับแอพนี้มากที่จะเป็นแอพเดสก์ท็อป - มันเหมือนกับสภาพแวดล้อม CAD แต่แทนที่จะสร้าง UI อีกครั้งในภาษา C / C ++ เฉพาะแพลตฟอร์ม (และดำเนินการต่อเพื่อรักษา UI ที่ใช้ MFC) ฉันมีแนวโน้มที่จะเขียนสแต็กทั้งหมดใหม่ใน Java เพื่อให้สามารถทำงานบนหลายแพลตฟอร์มได้

อาจมีเหตุผลในการเรียกใช้คอร์ที่ไม่ใช่ Java พูด C ++ เหมือนที่เราทำ แต่ฉันจะต้องการทดสอบการทำงานก่อนเพื่อดูว่าจำเป็นจริงๆหรือไม่ และฉันจะพิจารณา UI ของฉันอย่างรอบคอบเพื่อดูว่าฉันสามารถสร้างมันเป็นแอปพลิเคชันเว็บเชื่อมต่อกับแกนหลักผ่านบริการเว็บหรือไม่ ถ้าฉันต้องการชิ้นส่วนใน C หรือ C ++ มันสามารถเขียนได้ภายใต้เลเยอร์ของ Java หรือไม่? หรือเป็นบริการเว็บ?

การพิจารณาอื่น - แอปของคุณจะอยู่ได้นานเท่าไหร่? มันจะซับซ้อนแค่ไหน? หากคุณมีแนวคิดใด ๆ เกี่ยวกับเรื่องนี้ให้พิจารณาอายุการใช้งานที่ยาวนานของไลบรารี UI ใด ๆ ที่คุณใช้และความสามารถของคุณในการมีคนคอยดูแลพวกเขาตลอดเวลา นี่อาจเป็นเรื่องยากที่จะพิจารณาในตอนนี้ แต่คุ้มค่ากับความคิด

- อเล็กซ์

หากคุณสามารถทำให้มันเป็นเว็บแอปให้กลายเป็นเว็บแอป การใช้ชุดเครื่องมือเช่นExtJSมันค่อนข้างง่ายที่จะทำให้ส่วนติดต่อผู้ใช้ที่เข้ากันได้กับ GUI ที่มีลักษณะคล้าย GUI ข้ามเบราว์เซอร์

มิฉะนั้น Java หรือ QT + C ++ หรือ C + Wx เป็นตัวเลือกที่เป็นไปได้ที่จะมีแหล่งที่มาสำหรับทุกคน

วิธีที่สองของคุณเหมาะสมถ้าคุณต้องการให้แอพพลิเคชั่นดูและมีความเป็นพื้นเมืองในทุกแพลตฟอร์มเป้าหมาย แอพ Native Mac มีรูปลักษณ์และความรู้สึกที่แตกต่างจากแอพ Windows ดั้งเดิมเพียงแค่ใช้สกินอื่นและปุ่มลัดจะไม่เพียงพอที่จะครอบคลุม