Pendekatan mana yang harus diikuti untuk mengembangkan aplikasi yang menargetkan berbagai platform?


9

Untuk aplikasi yang menargetkan banyak platform, saya terutama melihat dua pendekatan pengembangan -

  • Pergi untuk beberapa platform pengembangan seperti JAVA. Memiliki satu solusi kode dan biarkan runtime menengah menangani berbagai platform. Jika ada kesalahan di platform apa pun, sesuaikan sedikit kode. Tapi tetap sama untuk semua.

  • Buat kode modular memisahkan logika inti dan UI. Kembangkan UI terpisah untuk platform masing-masing yang akan memanggil pustaka inti yang sama. Bangun aplikasi secara terpisah untuk masing-masing platform target.

Jadi, mana yang harus diikuti? Saya tahu, jawabannya akan dimulai dengan " Itu tergantung ". Tetapi saya ingin mendengar pendapat Anda tentang pendekatan ini dan faktor-faktor yang harus dipertimbangkan untuk memilih salah satu dari mereka.


2
Adapun pertanyaan ini, tidak ada cara untuk menjawabnya tanpa menggunakan "itu tergantung". Itu tergantung pada begitu banyak faktor, seperti apa platform aktual yang ada dalam pikiran Anda, apakah Anda merencanakan aplikasi desktop yang berdiri sendiri atau berencana untuk menggunakan beberapa layanan web, apa rencana Anda untuk UI (sama untuk setiap platform atau beragam?) Dan begitu seterusnya. Apakah Anda pikir model pengembangan Qt atau Gtk cocok untuk model pertama atau tidak? Bagaimana dengan .Net dan Mono? Haruskah saya melanjutkan ...?
Paweł Dyda

@ Gulshan Maaf, pertanyaan yang jelas - apakah ada alasan mengapa ini bukan aplikasi web dan / atau dilakukan dengan sesuatu seperti Adobe Air?
Ubur

Situs ini lebih untuk pertanyaan dan jawaban subyektif, tetapi juga dapat menjadi alasan untuk diterima. Itu hanya membuat kami merasa seperti Anda bermain bersama. Saya cenderung mencari pertanyaan yang baru diposting dan bukan yang belum terjawab.
JeffO

Jawaban:


3

Di samping Oracle / Apache / Google berselisih, masih sulit untuk mengalahkan JVM untuk tujuan ini. Ini benar-benar sangat berkualitas pada kebanyakan platform, universal, dan Anda memiliki sejumlah bahasa yang baik untuk dipilih (Java, Clojure, Scala dll.). Ini memungkinkan Anda menargetkan arsitektur mesin tunggal (VM), dan tidak terlalu khawatir tentang perangkat keras pengguna akhir tertentu.

Yang mengatakan, ada beberapa jenis aplikasi tertentu yang mungkin tidak cocok untuk: jaringan tingkat rendah terlintas dalam pikiran, seperti halnya pemrosesan grafis / video yang berat.


2

Gunakan HTML5. Platform apa pun dengan browser HTML5 dapat menjalankan aplikasi Anda. Meskipun HTML5 belum siap untuk waktu yang besar, pendekatan aplikasi Web adalah.


2
Tidak ada fitur lengkap browser HTML5.
Craig

2

Di editor suara Audacity kami menggunakan wxWidgets sebagai pustaka lintas platform kami. Karena kita perlu menautkan ke pustaka C, dan kita membutuhkan kecepatan dan akses tingkat rendah, pendekatan JVM tidak akan bekerja untuk kita. Kode GUI adalah 95% sama di semua platform. Kami menggunakan #ifdefs untuk variasi kecil. Namun, kami merasa penting untuk memiliki pengembang yang bekerja pada masing-masing dari tiga platform (Mac, Windows Linux), karena bahkan menggunakan perpustakaan lintas platform itu terlalu mudah untuk perubahan pada satu mesin untuk memecahkan sesuatu pada yang lain.

Jika Anda bisa mendapatkan kinerja yang Anda butuhkan, gunakan JVM. Jika Anda tidak bisa, gunakan QT atau wxWidgets, dan saya sarankan QT lebih dari wxWidgets karena itu kurang bekerja untuk membuatnya terlihat bagus.


1
+1 untuk "penting agar pengembang bekerja di setiap platform". Proyek lintas-platform dengan cepat menjadi platform tunggal jika Anda hanya mengembangkan untuk satu platform pada suatu waktu.
AShelly

2

Sebagai pengembang waktu nyata, saya telah berhasil menggunakan opsi yang mirip dengan 2 - memisahkan modul khusus platform dengan API umum yang digunakan oleh logika inti. Namun, tidak ada yang saya lakukan memiliki UI - jaringan, audio, streaming data - dalam hal ini adalah antarmuka perangkat keras tingkat rendah yang khusus untuk platform.

Saya telah melakukannya dengan beberapa alasan:

1) Untuk mendapatkan kinerja optimal pada setiap platform

2) Untuk memanfaatkan fitur yang hanya ditawarkan pada 1 platform

3) (J) VM tidak ada untuk beberapa platform (sistem embedded, konsol game ...)


2

Itu tergantung pada apa yang penting bagi Anda :)

Ketika kami menghadapi pilihan ini untuk aplikasi lintas-platform Mac / Windows sekitar 10 tahun yang lalu, kami telah melihat dengan baik berbagai opsi lintas-platform - Java, Qt, wxWidgets dll. Masalah yang kami miliki adalah tampilan dan nuansa dari UI benar-benar penting bagi kami, dan semua aplikasi "lintas platform" tampak terganggu. Kami akhirnya menggigit peluru dan membangun inti lintas-platform kami sendiri, dengan UI khusus untuk setiap platform di atas (ditulis dalam PowerPlant untuk Mac dan MFC pada Windows). Seiring berjalannya waktu, kami cukup pandai dalam hal ini, dan bagian "lintas platform" semakin tebal tanpa mengurangi UI.

Kami sekarang melihat keputusan ini lagi untuk proyek baru. Melihat opsi sekarang, saya mungkin akan pergi dengan Qt - ini gratis dan sepertinya telah matang dengan baik. Java mungkin menjadi pilihan tetapi kita tidak bisa benar-benar mengambil hit kinerja (kita sedang melakukan pemrosesan gambar 3D).

Jika UI benar-benar penting bagi Anda, saya curiga Anda harus menginvestasikan banyak waktu untuk mendapatkan hal-hal yang terlihat benar pada setiap platform apakah Anda menggunakan sesuatu seperti Qt atau roll sendiri. Untuk aplikasi internal atau spesialis di mana pengguna mungkin lebih menerima UI yang kurang dipoles, mungkin tidak apa-apa!


1

Semua orang membuat keributan besar tentang bahasa-bahasa seperti Jawa sebagai "lintas platform" tetapi yang sebenarnya mereka bicarakan adalah Anda dapat mengompilasi satu kali dan menjalankannya di mana-mana. Bahkan dalam bahasa seperti Java (atau C # / mono) Anda masih perlu lapisan abstraksi untuk menangani detail spesifik OS di beberapa area.

C ++, dan pada kenyataannya sebagian besar bahasa, adalah cross platform, Anda hanya perlu mengkompilasi untuk menargetkan setiap platform.

Kuncinya adalah proses dan bukan alat / bahasa:

  1. Pastikan Anda memiliki proses build terintegrasi yang membangun dan menjalankan tes unit untuk semua platform target .
  2. Pastikan setiap pengembang menguji pada semua platform target sebelum memeriksa kode - Ini jelas berarti memastikan pengembang pernah memiliki akses ke jumlah mesin / vms yang sesuai.
  3. Abstrak dengan baik. Abstrak semua yang memanggil apis asli. Tulis pustaka yang membungkus panggilan ini.
  4. Jika Anda melakukan sesuatu di luar bentuk UI yang cukup sederhana yang hanya melayani penyebut umum terendah, cukup terima bahwa kode GUI bukan lintas platform. Abstraksi GUI / lapisan presentasi Anda dan kode secara terpisah untuk setiap platform. Ya ada toolkit GUI lintas platform, yang baik untuk aplikasi langsung tetapi jika Anda melakukan sesuatu yang lebih maju Anda akan ingin kode ke kemampuan platform asli.

Langkah-langkah ini sama, apa pun bahasa / perangkat / kerangka yang Anda gunakan.


1

Memanfaatkan Web!

Serius, jika Anda menginginkan yang terbaik, tulis aplikasi web.

Mengapa?

  • Klien web biasanya tidak membutuhkan banyak daya PC.
  • Klien web adalah MANA SAJA. Bukan hanya PC / MAC / Linux, tetapi di ponsel, perangkat seluler, dan banyak lagi.
  • Tidak ada tambahan untuk diunduh bagi pengguna! (Biasanya, kecuali Anda menginginkan sesuatu yang mewah dan menggunakan Flash, atau Silverlight)
  • Semua komponen umum ada di sisi server, dan bisa Java, .NET, PHP, atau gado-gado sekelompok komponen yang ada yang Anda miliki. Klien seharusnya tidak peduli!

Bahkan dua pendekatan yang Anda sebutkan sangat mirip. Browser web merender HTML untuk beberapa arsitektur yang mendasarinya. Demikian pula, JVM mengartikan kode Java dengan cara yang masuk akal untuk perangkat keras yang mendasarinya. Web, bagaimanapun, hanya memiliki basis klien yang lebih luas!


0

Saya sudah cukup beruntung dengan Mono. Saya dapat menulis kode yang sama untuk mesin windows seperti yang saya lakukan untuk mesin Linux, dan sebagian besar, ia berfungsi pada keduanya. Dan saya bisa menggunakan skill yang sudah saya ketahui di C # dan Winforms.


UI apa yang Anda gunakan, atau maksud Anda untuk aplikasi berbasis server? Saya ingin tahu karena saya memiliki aplikasi yang berfungsi menggunakan Winforms, dan saya telah porting ke Mono dan itu menyenangkan, tetapi akan mengambil jumlah pekerjaan yang BESAR menjadi seperti winforms "nyata". Mungkin GTK # lebih baik? MonoDevelop itu bagus, tapi mungkin agak kikuk.
Dan Rosenstark

Dengan Mono kedua pendekatan dapat diikuti. Seperti Yar, yang mana yang Anda ikuti dan mengapa? Itu pertanyaannya.
Gulshan

Ya, saya tidak menyadari Anda sedang mencari bentuk yang sempurna antara platform. Anda mungkin mendapatkannya dengan GTK #, tetapi Anda akan mendapatkannya dengan mengorbankan "cantik," karena toolkit umum seperti itu harus digunakan untuk "penyebut umum terendah." Saya cenderung setuju dengan StartClass0830: HTML5 akan banyak pekerjaan, tetapi Anda bisa melakukan beberapa hal lintas platform yang sangat keren dengannya.
Robert Harvey 3-10

0

Lakukan pembuktian konsep terlebih dahulu.

Jika itu adalah aplikasi yang cukup kompleks, memoles bukti konsep akan memberi Anda gambaran tentang fitur bahasa apa yang Anda butuhkan dan bidang apa yang Anda perlukan untuk memanfaatkan kerangka kerja atau perpustakaan pihak ketiga.

Fitur bahasa dan pustaka yang Anda butuhkan akan menentukan bahasa apa yang akhirnya akan Anda pilih (dan dengan demikian, bagaimana Anda akan mendekati dukungan lintas platform)


0

Saya membangun sebuah sistem, dimulai dengan aplikasi desktop, 15 tahun yang lalu ketika Java masih dalam masa pertumbuhan dan tidak siap untuk digunakan dalam membangun aplikasi semacam ini. Saya tahu saya perlu memiliki inti dalam C ++ dan mendesainnya dari awal menjadi cross platform, termasuk menggunakan tipe berukuran (mis. Int32, bukan int atau panjang), sehingga bisa berjalan di Mac, Windows, dan UNIX (pra-Linux) hari).

Pada saat saya mencoba mencari lingkungan UI lintas-platform yang baik, ada beberapa saat itu termasuk XVT. Saya mengikuti pelatihan untuk XVT dan ketika saya mulai membangun aplikasi nyata, saya menyadari bahwa saya tidak akan dapat membuat tampilan dan nuansa asli yang bersih di platform (dimulai dengan Mac). Jadi saya menyerah ide itu dan membangun UI Mac (PowerPlant) asli di atas inti portabel.

Beberapa tahun kemudian, kami pindah ke Windows (UI di MFC). Itu lebih cepat membangun UI untuk kedua kalinya, kami mempertahankan Mac dan Windows UI secara paralel untuk waktu yang singkat dan kemudian pergi ke Windows. Inti kemudian pindah ke berbagai rasa UNIX dan Linux, untuk memungkinkan kita menjalankan perhitungan berbasis server. Inti melakukan port dengan baik, dengan beberapa penyesuaian ketika kami membuatnya 64-bit siap.

Sekarang saya kembali menggunakan Mac dan saya berharap kita bisa kembali ke Mac, tetapi ukuran dan kompleksitas aplikasi membuat ini pilihan yang sulit. Masih masuk akal bagi sebagian besar aplikasi ini untuk menjadi aplikasi desktop - itu seperti lingkungan CAD. Tapi daripada membangun UI lagi dalam bahasa C / C ++ platform-spesifik (dan terus mempertahankan UI berbasis MFC), saya lebih cenderung untuk menulis ulang seluruh tumpukan di Jawa sehingga dapat berjalan pada beberapa platform.

Mungkin masih ada alasan untuk menjalankan inti non-Java, katakanlah C ++ seperti yang kami lakukan. Tetapi saya ingin menjalankan tes kinerja awal untuk melihat apakah itu benar-benar diperlukan. Dan saya akan melihat dengan hati-hati pada UI saya untuk melihat apakah saya dapat membangunnya sebagai aplikasi web, terhubung ke inti melalui layanan web, sehingga saya dapat memiliki berbagai klien - aplikasi desktop, aplikasi seluler, aplikasi web, dll. Jika saya membutuhkan bagian dalam C atau C ++, dapatkah itu ditulis di bawah lapisan Java? Atau sebagai layanan web?

Pertimbangan lain - berapa lama aplikasi Anda akan ada? Seberapa rumit hal itu akan tumbuh? Jika Anda memiliki ide tentang ini, pertimbangkan umur panjang yang mungkin dari perpustakaan UI yang Anda gunakan dan kemampuan Anda dari waktu ke waktu agar orang-orang membantu memeliharanya. Ini mungkin sulit untuk dipertimbangkan sekarang tetapi patut dipikirkan.

- Alex


JVM telah terbukti sangat stabil dalam hal kompatibilitas runtime library mundur. Untuk skenario ini, itu akan menjadi sangat cocok ...

0

Jika Anda bisa menjadikannya aplikasi web, buatlah aplikasi web. Menggunakan toolkit seperti ExtJS , relatif mudah untuk membuat antarmuka pengguna yang kompatibel dengan cross-browser yang mirip GUI.

Jika tidak, Java atau QT + C ++ atau C + Wx adalah opsi yang memungkinkan untuk memiliki satu sumber untuk semua.

Pendekatan kedua Anda sesuai jika Anda ingin aplikasi terlihat dan terasa asli di setiap platform target. Aplikasi Mac asli terlihat dan terasa berbeda dari aplikasi Windows asli, hanya menggunakan skin lain dan keybinds tidak akan cukup untuk menutupi itu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.