Bir Etkinlik ve diğer tüm Parçalar [kapalı]

Bir ekranı Activityve diğer tüm ekranları Fragmentsvemanaging all the fragments thru the activity .

İyi bir fikir mi? ve cevabım HAYIR ama yine de bu düşünce hakkında daha net bilmek istiyorum.

Bu fikrin artıları ve eksileri nelerdir?

Not:

Lütfen bana parça ve aktivite bağlantısı vermeyin.

DÜZENLE:

Parçalar ve aktivite hakkında bir şeyler:

Artıları:

1. Fragmanlar, aktivitelerde alt aktivite olarak kullanılmalıdır.
2. Parçalar etkinliklerin yerini tutmaz.
3. Parçalar tekrar kullanılabilirlik içindir (Yeniden kullanılabilirliğin nasıl elde edilebileceğini bilmeniz gerekir.).
4. Parçalar, hem tabletleri hem de telefonları desteklemek için kod yazmanın en iyi yoludur.

Eksileri:

1. Verileri parçalardan almak için arayüzü uygulamamız gerekir.
2. Diyalog için bunu göstermek için uzun bir yol kat etmemiz gerekiyor.

Tabletleri düşünmüyorsak neden parçaları kullanmalıyız? Aktivite ve fragman arasındaki başlangıç ​​zamanı farkı nedir?

Oluşturduğunuz uygulamaya bağlıdır. Her iki yaklaşımı kullanarak birkaç uygulama oluşturdum ve bir yolun her zaman diğerinden daha iyi olduğunu söyleyemem. Oluşturduğum son uygulama tek bir Activityyaklaşım ve bir Facebook tarzı navigasyon kullandım. Gezinme listesinden öğe seçerken, Fragmentbu bölümü görüntülemek için tek bir kapsayıcıyı güncelleştiriyorum .

Bununla birlikte, tek bir kişiye sahip olmak Activityda birçok karmaşıklık getiriyor. Bir düzenleme formunuz olduğunu ve kullanıcının seçmesi veya oluşturması gereken bazı öğeler için yeni bir ekrana gitmelerini gerektirdiğini varsayalım. Faaliyetler ile yeni ekranı çağırırız, startActivityForResultancak Fragmentsböyle bir şey yoktur, böylece değeri Activitydepolarsınız ve ana düzenleme parçasının Activityverilerin seçilip seçilmediğini ve kullanıcıya gösterilmesi gerektiğini kontrol edin .

Aravind'in tek bir Activitytüre yapışması hakkında söyledikleri de doğrudur, ancak bu sınırlayıcı değildir. Etkinliğiniz bir FragmentActivity olacaktır ve ihtiyacınız MapViewolmadığı sürece gerçek bir sınırlama yoktur. Haritaları görüntülemek istiyorsanız, yapılabilir, ancak herkese açık olan android-support-v4-googlemaps'iFragmentActivity genişletmek MapActivityveya kullanmak için Android Uyumluluk Kitaplığı'nı değiştirmeniz gerekir .

Nihayetinde bir Activityrotaya gittiğini biliyorum devs çoğu kodlarını basitleştirmek için birden fazla Faaliyet geri döndü. UI akıllıca, bir tablette, Activitytasarımcılarınızın ortaya çıkardığı çılgın etkileşimi elde etmek için bazen tek bir tane kullanıyorsunuz :)

-- DÜZENLE --

Google nihayet MapFragmentuyumluluk kütüphanesine yayınlandı , böylece artık android-support-v4-googlemaps kesmek kullanmanıza gerek yok. Güncelleme hakkında buradan bilgi edinin: Google Maps Android API v2

- DÜZENLEME 2 -

Modern (2017) parçaların durumu hakkındaki bu harika gönderiyi okudum ve bu eski cevabı hatırladım. Paylaşacağımı düşündüm: Parçalar: Android'in Tüm Sorunlarına Çözüm

Tamamen tam ekran 1 aktivitesi ve 17 parçası olan bir projeyi (geliştirme aşamasında 5 ay) bitirmek üzereyim. Bu benim ikinci parça tabanlı projem (önceki 4 aydı).

Artıları

• Ana faaliyet 700 satır kod, sadece parçaları navigasyon sırasını güzelce yönetiyor.
• Her parça kendi sınıfına güzelce ayrılır ve nispeten küçüktür (~ birkaç yüz ui şeyler satırı).
• Yönetim "hey, bu ekranların sırasını nasıl değiştirdiğimize" diyebilir ve bunu çok kolay yapabilirim, çünkü bu parçalar birbirine bağlı olmadığından, hepsi etkinlik yoluyla iletişim kurar. Birbirlerini nerede arayacaklarını bulmak için bireysel aktiviteleri araştırmam gerekmiyor.
• benim app çok grafik ağır ve asla 1 ekran 1 aktivite olarak işe yaramaz. Hafızadaki tüm bu alt aktiviteler, uygulamanın her zaman hafızasını bitirir, bu yüzden finish()tüm görünür olmayan aktivitelere ihtiyacım olur ve navigasyon için aynı kontrol mantığını, parçalarla yaptığım gibi yapardım. Sadece bu yüzden parçalarla da yapabilir.
• bir tablet uygulaması yaparsak, her şeyi zaten güzel bir şekilde ayırdığımızdan, şeyleri yeniden faktoring etmenin daha kolay bir zamanına sahip olacağız.

Eksileri

• parçaların nasıl kullanılacağını öğrenmek zorundasın

İlk olarak, ne yaparsanız yapın, bir Etkinliğe veya Parçaya son derece bağımlı olmayan model, görünüm, sunucu kullanan modüler bir tasarıma sahip olduğunuzdan emin olun.

Etkinlikler ve Parçalar gerçekten ne sağlar?

1. Yaşam döngüsü olayları ve backstack
2. Bağlam ve kaynaklar

Bu nedenle, bunları SADECE kullanın . Yeterli sorumlulukları var, onları fazla zorlamayın. Bir Etkinlikte veya Parçada bir TextView başlatmanın bile kötü bir uygulama olduğunu iddia ediyorum. Public View findViewById (int id) gibi KAMU gibi bir yöntem vardır .

Şimdi soru daha basit: Birden fazla, bağımsız yaşam döngüsü olaylarına ve backstacks'a ihtiyacım var mı? Eğer evet diye düşünürseniz, parçaları kullanın. Hiç düşünmüyorsanız, parça kullanmayın.

Sonunda, kendi backstack ve yaşam döngülerinizi yapabilirsiniz. Peki, neden tekerleği yeniden yaratıyoruz?

EDIT: Neden aşağı oy? Tek amaçlı sınıflar insanlar! Her aktivite veya fragman, bir görünümü başlatan bir sunucuyu başlatabilmelidir. Sunum yapan kişi ve görünüm değiştirilebilen bir modüldür. Bir faaliyet veya parçanın neden bir sunum yapan kişinin sorumluluğunda olması gerekir?

Artıları

Parçalarınızı tek bir aktiviteden kontrol edebilirsiniz, çünkü tüm fragmanlar birbirinden bağımsızdır. Fragmanları bir yaşam döngüsünü (var onPause, onCreate, onStartkendi ...). Bir yaşam döngüsüne sahip olarak, parçalar olaylara bağımsız olarak yanıt verebilir, durumlarını kaydedebilir onSaveInstanceStateve geri getirilebilir (örneğin, gelen bir aramanın ardından devam ettirildiğinde veya kullanıcı geri düğmesini tıklattığında olduğu gibi).

Eksileri

1. Etkinlik kodunuzda karmaşıklık yaratın.
2. Parçaların sırasını yönetmelisiniz.

Daha azı, birkaç görünüm göstermek istediğiniz bir uygulama oluşturmanız gerekiyormuş gibi, oldukça iyi bir fikirdir. Bu fikir sayesinde, birkaç parçayı tek bir görünümde görüntüleyebilirsiniz.

Uygulamanızın tasarım düzenine bağlıdır. Tasarım düzeninde ActionBar'daki Sekmeleri kullandığınızda, uygulamanın Tek Etkinlik'te Sekme tıklamasında parçaların değiştirilebileceğini varsayalım. Şimdi bir Etkinliğiniz olduğunu ve ActionBar'da üç Sekme olduğunu ve Parçalar tarafından sağlanan sekmelerin görünümünün diyelim ki bu da yönetmeyi kolaylaştıran artı da mümkündür. Bu nedenle, her şey uygulamanızın tasarım şemasına ve bunun için nasıl karar verdiğinize bağlıdır.

Artıları:

• Xml düzenleri aracılığıyla birden çok ekran boyutu ve yönlendirmesi ile kullanılabilen tek bir arabirim oluşturmak için kullanılabilir.

Eksileri:

• Etkinliğinizde daha karmaşık kodlar gerektirir.

Bunun iyi bir fikir olduğuna inanıyorum, çünkü mevcut ekran boyutuna ve yönüne göre farklı xml düzenleri kullanmak uygulamayı daha kullanışlı hale getirebilir ve uygulamanızı hem telefonlar hem de tabletler için yayınlamayı planlıyorsanız uygulamanızın birden çok sürümünü yayınlama ihtiyacını azaltabilir. Uygulamanız asla hem tabletler hem de telefonlar tarafından kullanılmayacaksa, muhtemelen sorun yapmaya değmez.

Daha iyi esneklik sağlamak için tüm görünüm enflasyonunu parçalara ertelemenin savunucusuyum. Örneğin, birden fazla parçayı toplayan ve aynı parçacıkları bir parçada bir ekran göstermek üzere bir telefonda yeniden kullanan bir tablet için tek bir iniş etkinliğine sahip olmak. Ancak telefon uygulamasında her ekran için ayrı bir aktivite olurdu. Faaliyetlerin, enflasyon muhalefeti için parça muadillerine derhal erteledikleri için çok fazla koda sahip olmayacaktı.

Sekme veya menü gezintisi tamamen yeni bir ekranla sonuçlandığından, sekmeler veya bir kaydırma menüsü tanıtıldığında telefon uygulamasının tek bir açılış etkinliğine geçmek zorunda olması kötü bir fikirdir.

Tek aktivite yaklaşımını kullanmamamın en önemli nedeni, aktivite yaşam döngüsünün kullanılabilmesidir. Etkinlikler, uygulamanın belirli bir bölümünün bağlamsal davranışını içerir ve bu davranışı tamamlayan parçalar. Etkinlik yaşam döngüsü içinde geçersiz kılınabilir adımların yararlanmak becerisi gibi yöntemlerle başka birini etkinliğin davranışını ayırmak için yardımcı olur onPauseve onResume. Bu yaşam döngüsü ayrıca önceki bağlama geri dönmenizi sağlar. Tek aktivite yaklaşımıyla, bir parçadan ayrıldıktan sonra, ona geri dönmek için bir mekanizma oluşturmanız gerekir.