В каких случаях лучше использовать фрагменты, а в каких активити?
У меня есть приложение на основе гугл карты. Пользователю даётся возможность искать объекты, соответственно они отображаются на карте и есть фильтры, список результатов и вид отдельного результата.
Сейчас в уже написанном приложении это один activity, внутри которого карта, и поверх ряд фрагментов - с фильтрами, списком объектов и видом отдельного объекта. Все эти фрагменты полноэкранные, то есть заслоняют собой всю родительскую активити.
В виду проблем с бекстеком я задумался правильно ли я сделал, возможно эти фрагменты должны быть полноценными активити?
Хотя там я вижу проблему связей и передачи данных между разными активити, в то время как сейчас я спокойно могу использовать нужные методы фрагмента из родительского активити.
И второй вопрос - есть ли хорошие статьи по поводу архитектуры андроид приложений?
Upd: кажется что при использовании активити - медленнее происходят переключения.
upd2:
Подробнее: есть главный экран(активити) с картой, на ней поверх поля ввода (отдельный фрагмент), счетчик метров и времени (отдельный фрагмент), пара кнопок.
Есть дополнительные экраны, закрывающие собой весь родительский экран и оформлены они в виде фрагментов:
выбор фильтров, список объектов, информация об одном объекте.
Вопрос касается последний трёх, хотя судя по тому что это выглядит как отдельные экраны, они вероятно должны быть именно активити. Но тогда не очень удобно информацию передавать туда-обратно (к примеру инфу о том какие выбраны фильтры передавать на активити с картой, где происходит поиск)
То есть, вы не пользуетесь стандартным API для отображения меток на карте? Marker они называются. Опишите подробнее UX-схему приложения, тогда можно будет понять, что должно быть чем.
Activity и Fragment - вещи весьма разного уровня. Fragment нужен, когда у вас есть необходимость переиспользовать большой кусок UI и функциональности на разных экранах. Activity - стандартная единица навигации между экранами. Это не вопрос уровня "быстрее-медленнее переключается". А накладывать друг на друга фрагменты или активити - почти всегда плохая идея, если это не DialogFragment.
Алексей Ершов: Пользуюсь ими, они на карте и отображаются, но физически с ними связаны entity объекты, в которых нужная пользователю информация и которые используются на этих экранах (объекта и списка объектов.
Если возникает требование закрыть полностью родительский экран, то стоит задуматься о том, что это, на самом деле, отдельный экран. Единственный легитимный случай, когда можно закрыть части родительского экрана - это диалог.
Пердавать данные между Activity приложения, действительно, не всегда удобно. Однако поддержка такой связи между экранами позволит вам, например, открывать экран карты из совершенно другого места (например, Push-уведомления, или вообще другого приложения), используя тот же самый протокол, Extras в Intent. Это принцип организации Android-приложения. Слабо связанные между собой экраны-модули приложения. Для того, чтобы уйти на какой-то экран специально с целью вернуть оттуда данные, есть механизм startActivityForResult.
Максим: Неудобство в том, что все объекты должны быть Parcelable, конечно, есть. Есть разные способы обхода архитектурных стандартов Android, вроде разных реализаций EventBus для передачи событий и данных между разными экранами, но при использовании этих способов повышается вероятность появления странных ошибок, утечек памяти и крэшей. И уменьшается гибкость приложения, например, ухудшается работоспособность при пересоздании Activity.
Один из нормальных вариантов - сделать хранилище данных о состоянии приложения, в памяти, или какую-нибудь персистентную реализацию, и изменять его с разных экранов. Например, в хранилище может быть пункт "список активных фильтров", который вы считываете с одного экрана и изменяете с другого.
Алексей Ершов: да, по сути фильтры у меня и хранятся как SharedPreferences, просто я решил что правильнее управлять этим в одном месте, чтобы никто другой вообще не мог знать подробности реализации.
Parcelable - я пока не использовал, пользовался Serializable. Но подозреваю что почти одно и тоже.
по своему опыту, использую фрагменты только в виде DialogFragment. Все.
На счет передачи данных между активити - Parcelable чрезвычайно удобен. Либо класс сериализовать в жсон. Либо перегнать его в byte[]->Base64 строка->передать ч/з интент->Base64>new String();
Да и некий bus для app-wide notifications нужен для любого мало мальски большого приложения... через него тоже можно данные гонять.
упаковать в отдельный класс-наследник вью?
Понимаешь, фрагменты дают 2 фичи - корректную работу с кнопкой "назад" и сохранением viewstate. Взамен - много проблем.
Работать с этим можно, но я бы посмотрел в сторону flow https://github.com/square/flow
Простой
