Satu Aktivitas dan semua Fragmen lainnya [ditutup]


158

Saya berpikir untuk mengimplementasikan satu layar dengan Activitydan semua layar lainnya dengan Fragmentsdan managing all the fragments thru the activity.

Apakah itu ide yang bagus? dan jawaban saya TIDAK, tetapi saya masih ingin tahu lebih jelas tentang pemikiran ini.

Apa pro dan kontra dari gagasan itu?

catatan:

Tolong jangan beri saya tautan untuk fragmen dan aktivitas.

EDIT:

Berikut ini sesuatu di atas Fragmen dan aktivitas:

Pro:

  1. Fragmen dimaksudkan untuk digunakan dengan kegiatan sebagai sub kegiatan.
  2. Fragmen bukan pengganti kegiatan.
  3. Fragmen dimaksudkan untuk reusability (Perlu tahu bagaimana reusability dapat dicapai.).
  4. Fragmen adalah cara terbaik untuk menulis kode untuk mendukung tablet dan ponsel.

Cons:

  1. Kita perlu mengimplementasikan antarmuka untuk mendapatkan data dari fragmen.
  2. Untuk dialog, kita harus menunjukkannya.

Mengapa kita harus menggunakan fragmen jika kita tidak mempertimbangkan tablet? Apa perbedaan waktu mulai antara aktivitas dan fragmen?


Bisakah Anda menguraikan mengapa menurut Anda jawabannya tidak? Saya kebetulan tidak setuju, tetapi lebih mudah untuk mengatasi masalah yang mungkin Anda miliki tentang pendekatan itu jika kita tahu apa kekhawatiran itu.
Alexander Lucas

1
@AlexanderLucas Jawaban yang saya berikan tidak karena melakukan hal itu membuat kode Anda kurang modular, meningkatkan kompleksitas.
Vineet Shukla

@Ski Anda lebih berkonsentrasi untuk mendapatkan jawaban Anda diterima, silakan berkonsentrasi pada apa yang ditanyakan dan apa jawaban terbaik yang bisa Anda berikan.
Vineet Shukla

3
Bagi siapa pun yang menemukan ini, saya menghentikan refactor karena semuanya menjadi sangat rumit sangat cepat.
theblang

18
Ini adalah pertanyaan yang bagus dan seharusnya tidak ditutup.
Jim In Texas

Jawaban:


94

Itu tergantung pada aplikasi yang Anda buat. Saya telah membuat beberapa aplikasi menggunakan kedua pendekatan dan tidak bisa mengatakan satu cara selalu lebih baik dari yang lain. Aplikasi terbaru yang saya buat saya menggunakan Activitypendekatan tunggal dan navigasi gaya Facebook. Ketika memilih item dari daftar navigasi saya memperbarui satu Fragmentwadah untuk menampilkan bagian itu.

Yang mengatakan, memiliki satu Activityjuga memperkenalkan banyak kompleksitas. Katakanlah Anda memiliki formulir edit, dan untuk beberapa item yang perlu dipilih, atau dibuat, pengguna harus membawanya ke layar baru. Dengan aktivitas kami hanya akan memanggil layar baru dengan startActivityForResulttetapi denganFragments tidak ada hal seperti itu sehingga Anda akhirnya menyimpan nilai pada Activitydan memiliki fragmen edit utama memeriksa Activityuntuk melihat apakah data telah dipilih dan harus ditampilkan kepada pengguna.

Apa yang dikatakan Aravind tentang terjebak pada satu Activitytipe juga benar tetapi tidak terlalu membatasi. Aktivitas Anda akan menjadi FragmentActivity dan selama Anda tidak membutuhkannya MapViewmaka tidak ada batasan nyata. Jika Anda ingin menampilkan peta, itu bisa dilakukan, tetapi Anda harus memodifikasi Perpustakaan Kompatibilitas Android untuk FragmentActivitymemperpanjang MapActivityatau menggunakan yang tersedia untuk umum android-support-v4-googlemaps yang tersedia untuk umum .

Pada akhirnya sebagian besar devs yang saya tahu yang pergi Activity rute telah kembali ke beberapa Aktivitas untuk menyederhanakan kode mereka. UI bijaksana, pada tablet, Anda beberapa kali terjebak menggunakan tunggal Activityhanya untuk mencapai interaksi gila yang pernah dibuat oleh desainer Anda :)

- EDIT -

Google akhirnya dirilis MapFragmentke perpustakaan kompatibilitas sehingga Anda tidak perlu lagi menggunakan hack android-support-v4-googlemaps. Baca tentang pembaruan di sini: Google Maps Android API v2

- EDIT 2 -

Saya baru saja membaca posting hebat ini tentang keadaan fragmen modern (2017) dan mengingat jawaban lama ini. Pikir saya akan berbagi: Fragmen: Solusi untuk Semua Masalah Android


6
Ada settargetfragmentdan Anda dapat menangani aktivitas seperti startforresultprosedur.
Lalith B

1
Menurut saya kegiatan ada hanya karena itu sistem lama. Fragmen tidak ada sebelumnya. Tidak ada yang bisa dilakukan oleh aktivitas dan fragmen, selain formalitas. Saya bahkan bisa membayangkan bahwa pada titik tertentu kegiatan dihapus dan semuanya adalah fragmen.
Ixx

1
Meringkas kontra-fragmen-hanya yang Anda berikan, sebenarnya tidak ada. startActivityForResult seperti yang dikatakan Lalith B memiliki rekanan, dan peta juga tidak menjadi masalah. Selain itu semuanya (tabungan negara, dll.) Dapat ditangani dengan metode siklus hidup fragmen.
Ixx

85

Saya akan menyelesaikan proyek (5 bulan dalam pengembangan), yang memiliki 1 aktivitas, dan 17 fragmen, semua layar penuh. Ini adalah proyek berbasis fragmen kedua saya (sebelumnya adalah 4 bulan).

Pro

  • Aktivitas utama adalah 700 baris kode, hanya mengelola urutan navigasi fragmen dengan baik.
  • Setiap fragmen dipisahkan dengan baik ke dalam kelasnya sendiri, dan relatif kecil (~ beberapa ratus baris barang ui).
  • Manajemen dapat mengatakan, "hei, bagaimana kalau kita mengganti urutan layar itu", dan saya bisa melakukannya dengan sangat mudah, karena fragmen-fragmen itu tidak saling bergantung, mereka semua berkomunikasi melalui aktivitas. Saya tidak perlu menggali melalui aktivitas individu, untuk menemukan di mana mereka saling memanggil.
  • aplikasi saya sangat berat grafis, dan tidak akan pernah berfungsi sebagai aktivitas 1 layar 1. Semua sub kegiatan dalam memori, akan membuat aplikasi kehabisan memori sepanjang waktu, jadi saya harus melakukannyafinish() semua kegiatan yang tidak terlihat, dan membuat logika kontrol yang sama untuk navigasi, seperti yang akan saya lakukan dengan fragmen. Mungkin juga melakukannya dengan fragmen hanya karena ini.
  • jika kita pernah melakukan aplikasi tablet, kita akan memiliki waktu yang lebih mudah untuk membuat ulang faktor-faktor, karena semuanya sudah dipisahkan dengan baik.

Cons

  • Anda harus belajar, cara menggunakan fragmen

1
tidak yakin memiliki terlalu banyak fragmen dan hanya aktivitas sekarang ... ada masalah pada produksi, dan kesalahan ada pada Anda !! :)
Shahar

1
@Dashash jangan biarkan os memulai kembali aktivitas Anda. menangani perubahan orientasi sendiri. baca lebih lanjut di sini: stackoverflow.com/questions/5913130/…
Tamas

1
@Tamas Apakah Anda memiliki layar multi-fragmen (mis. Detail master) dan jika demikian, bagaimana Anda mengatasinya?
theblang

7
@Tamas Pendekatan ini sangat anti-android. Anda berakhir dengan kelas ALLAH. Sistem Android dirancang untuk bekerja dengan aktivitas - misalnya Anda tidak memiliki cara yang baik untuk menangani Toolbar dalam banyak fragmen. Anda tidak memiliki fragmen mulai untuk hasil dan banyak lagi yang tidak memiliki. Itu berarti Anda harus menulis ulang seluruh logika yang sudah ada. Bagaimana dengan penerima siaran lokal, layanan, dan komponen android lainnya. Untuk memulai layanan, Anda harus melakukan yang berikut: getActivity ()! = Null ... ini benar-benar jelek. Juga komunikasi antara fragmen sangat aneh jika Anda memiliki banyak fr.
Teodor

9
700 baris !!!! "dengan baik" ???? Kelas gratis.
beplaya

16

Pertama, apa pun yang Anda lakukan, pastikan Anda memiliki desain modular menggunakan model, tampilan, presenter yang tidak terlalu bergantung pada suatu Kegiatan atau Fragmen.

Apa yang disediakan oleh Aktivitas dan Fragmen?

  1. Peristiwa siklus hidup dan backstack
  2. Konteks dan sumber daya

Karena itu, gunakan mereka untuk itu, SAJA . Mereka memiliki tanggung jawab yang cukup, jangan terlalu menyulitkan mereka. Saya berpendapat bahwa bahkan mengintensifkan TextView dalam Aktivitas atau Fragmen adalah praktik yang buruk. Ada metode alasan seperti public View findViewById (int id) adalah PUBLIK .

Sekarang pertanyaannya menjadi lebih sederhana: Apakah saya perlu beberapa peristiwa siklus hidup independen dan backstacks? Jika Anda berpikir ya mungkin, gunakan fragmen. Jika Anda berpikir tidak pernah, jangan gunakan fragmen.

Pada akhirnya, Anda bisa membuat backstack dan siklus hidup Anda sendiri. Tetapi, mengapa menciptakan kembali roda?

EDIT: Mengapa memilih ini? Kelas tujuan tunggal! Setiap aktivitas atau fragmen harus dapat membuat instantiate presenter yang instantiate tampilan. Presenter dan view adalah modul yang dapat dipertukarkan. Mengapa suatu kegiatan atau fragmen memiliki tanggung jawab presenter ??


Hm ... hubungan antara membuat instance tampilan menjadi praktik yang buruk dan publik findViewById () tidak jelas. Walaupun saya setuju tentang instantiation of views, saya juga menganggap memanggil findViewById dari kelas lain (mis. Aktivitas yang menampung fragmen menyebutnya sebagai fragmen) adalah praktik yang buruk. Tidak benar-benar tahu mengapa ini bersifat publik, karena, setidaknya dalam kasus yang dapat saya pikirkan, ini menghasilkan kode yang berantakan dan bukan desain modular.
Ixx

IMHO: Jika Anda memberikan aktvitas ke tampilan dan presenter (memanggil 2 gabungan "modul"), Anda dapat menggunakan kembali modul tersebut dengan aktivitas lain. Jika itu membantu, mungkin lebih baik untuk lulus kegiatan sebagai suatu intrusi yang memaparkan hanya hal-hal yang diperlukan. Jika Anda benci menemukan pandangan di luar aktivitas, maka Anda dapat menyuntikkan semua pandangan, melalui tampilan itu, ke dalam pres./view. Poin utama adalah bahwa saya percaya pengkodean Android harus dilakukan di luar konsep Actvities dan Frags, karena itu keduanya mudah. ​​Lalu, menjadi jelas apa yang pertama dan Anda tidak terjebak dengan satu atau yang lain di dalam web kode.
beplaya

3
Lepaskan MVP, Anda akan lebih baik tanpa itu Android. Anda dapat menghabiskan banyak waktu untuk mencoba memasukkan balok bentuk tertentu melalui lubang yang bentuknya berbeda, tentu saja ini merupakan tantangan, tetapi mungkin ada persyaratan fungsional yang akan membuat Anda lebih bijaksana menghabiskan waktu.
straya

12

Pro

Anda dapat mengontrol fragmen Anda dari satu aktivitas, karena semua fragmen independen satu sama lain. Fragmen memiliki siklus hidup ( onPause, onCreate, onStart...) mereka sendiri. Dengan memiliki siklus hidup, fragmen dapat merespons secara independen terhadap peristiwa, menyelamatkan negara mereka melaluionSaveInstanceState , dan dibawa kembali (yaitu seperti ketika melanjutkan kembali setelah panggilan masuk atau ketika pengguna mengklik tombol kembali).

Cons

  1. Buat kompleksitas dalam kode aktivitas Anda.
  2. Anda harus mengelola urutan fragmen.

Namun demikian, itu ide yang cukup bagus, seolah-olah Anda perlu membuat aplikasi, di mana Anda ingin menampilkan beberapa tampilan. Dengan gagasan ini, Anda akan dapat melihat beberapa fragmen dalam satu tampilan ..


2

Itu tergantung pada tata letak desain aplikasi Anda. Misalkan jika Anda menggunakan Tabs di ActionBar dalam tata letak desain maka dalam Aktivitas Tunggal aplikasi seseorang dapat memiliki fragmen yang diubah pada klik Tab. Jadi sekarang Anda memiliki Kegiatan dan anggaplah tiga Tab di ActionBar dan tampilan untuk tab yang disediakan oleh Fragmen, yang membuatnya mudah untuk mengelola plus juga layak. Jadi, semuanya tergantung pada skema desain aplikasi Anda dan bagaimana Anda mengambil keputusan untuk membuatnya.


1

Pro:

  • Dapat digunakan untuk membuat antarmuka tunggal yang dapat digunakan oleh berbagai ukuran dan orientasi layar melalui tata letak xml.

Cons:

  • Membutuhkan kode yang lebih kompleks dalam aktivitas Anda.

Saya percaya ini adalah ide yang baik, karena menggunakan tata letak xml berbeda berdasarkan pada ukuran dan orientasi layar saat ini dapat membuat aplikasi lebih bermanfaat dan mengurangi kebutuhan untuk merilis beberapa versi aplikasi Anda jika Anda berencana untuk merilis aplikasi Anda untuk ponsel dan tablet. Jika aplikasi Anda tidak akan pernah digunakan oleh tablet dan ponsel, itu mungkin tidak sepadan dengan masalahnya.


Untuk orientasi tidak perlu menggunakan tata letak berbasis xml yang berbeda.
Vineet Shukla

@VineetShukla benar, tetapi ini adalah opsi, sama seperti menggunakan tata letak xml berbeda berdasarkan ukuran layar. Misalnya, layar beranda ponsel Android saya memiliki tata letak yang berbeda ketika saya melihatnya dalam orientasi lanskap versus potret.
Ski

0

Saya seorang pendukung menunda semua tampilan inflasi ke fragmen untuk memberikan fleksibilitas yang lebih baik. Misalnya memiliki aktivitas pendaratan tunggal untuk tablet yang mengagregasi banyak fragmen dan menggunakan kembali fragmen yang sama pada ponsel untuk menampilkan satu layar per fragmen. Namun dalam implementasi ponsel saya akan memiliki aktivitas terpisah untuk setiap layar. Kegiatan tidak akan memiliki terlalu banyak kode karena mereka akan segera tunduk kepada mitra fragmen mereka untuk melihat inflasi.

Saya pikir itu adalah ide yang buruk untuk implementasi ponsel harus mengubah ke aktivitas pendaratan tunggal ketika tab atau menu geser diperkenalkan karena navigasi tab atau menu hanya menghasilkan layar yang sama sekali baru.


"Saya pikir itu adalah ide yang buruk untuk implementasi ponsel harus mengubah ke aktivitas pendaratan tunggal ketika tab atau menu geser diperkenalkan karena navigasi tab atau menu hanya menghasilkan layar yang sama sekali baru." -> Tidak dapat dimengerti apa yang sebenarnya Anda maksudkan, tetapi, baik tab atau menu samping tidak menjadi masalah dalam aplikasi aktivitas tunggal (tablet / ponsel).
Ixx

-1

Alasan paling penting yang akan saya berikan untuk tidak menggunakan pendekatan aktivitas tunggal adalah agar siklus hidup aktivitas dapat dimanfaatkan. Kegiatan mengandung perilaku kontekstual dari bagian tertentu dari aplikasi dan fragmen melengkapi perilaku itu. Memiliki kemampuan untuk mengambil keuntungan dari langkah-langkah yang dapat ditimpa dalam siklus hidup kegiatan membantu untuk memisahkan perilaku satu kegiatan dari yang lain dengan metode seperti onPausedan onResume. Siklus hidup ini juga memungkinkan Anda kembali ke konteks sebelumnya. Dengan pendekatan aktivitas tunggal, begitu Anda meninggalkan sebuah fragmen, Anda harus membuat mekanisme untuk kembali ke sana.


4
Saya tidak percaya ini benar. Dari dokumentasi siklus hidup Fragmen ( developer.android.com/guide/components/fragments.html#Lifecycle ): "Siklus hidup aktivitas di mana fragmen itu hidup secara langsung mempengaruhi siklus hidup fragmen, sehingga setiap panggilan siklus hidup untuk aktivitas tersebut menghasilkan panggilan balik yang sama untuk setiap fragmen. Misalnya, ketika aktivitas menerima onPause (), setiap fragmen dalam aktivitas menerima onPause (). "
Ski
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.