Есть ли какие-либо недостатки в создании класса Singleton со статическим полем для взаимодействия между действиями в Android?

Question

Существует 3 вида деятельности: A-> B-> C. Каждый из них содержит Button (для открытия следующей операции) и EditText.

Например: если я печатаю текст в C и вернуться к (нажатием кнопки Назад), как можно видеть тот же текст там?

Я знаю 3 решения:

• LocalBroadcastManager
• SharedPreferences
• Создать класс Singleton со статическим полем, а затем получить это поле в onStart методе А - , какие минусы этого решения?

Answer 1

ИМХО, всегда существуют недостатки в использовании шаблона проектирования Singleton в ваших приложениях.Некоторые из них (от верхней части моей головы):

• Связь между иначе связанных объектов и потоков через экземпляр Синглтон
• появление «глобального государства», что делает отладки намного сложнее
• Неумение для издевательства статических полей и методов с помощью «обычных» издевательств
• Тот факт, что ссылка на Singleton может быть легко получена в любой части приложения, приводит к полному беспорядку (люди перестают думать о графике зависимостей)
• Одиночные игры имеют тенденцию породы: вы вводите один, затем руга один, то вы оказываетесь с 10 одиночек, которые держат состояние приложения в «глобальном облачном состоянии»

Обратите внимание, что то, что вы пытаетесь сделать, это против Android принципов - если пользователь нажимает на «назад ", то он должен найти предыдущие Activity или Fragment в том же состоянии, в котором он был в последний раз, когда пользователь увидел его, без каких-либо дополнений (если вы явно не хотите сохранять его в back-stack).

Если вы все еще хотите это сделать, то я мог бы предложить несколько вариантов:

• Используйте SharedPreferences и хранить значение там. Получите значение в каждом Activity и запишите его в onResume()
• Используйте startActivityForResult() звонок, чтобы начать новый Activities и передать значение обратно в результат. Обратите внимание, что по умолчанию нажмите «назад», отменяет действие, поэтому вам придется переопределить метод onBackPressed().
• Переопределить метод onBackPressed() в Activity таким образом, чтобы он начинал с другого Activity (вместо того, чтобы просто вытаскивать задний стек) и передать значение в используемом вами Intent. В этом случае вы можете использовать FLAG_ACTIVITY_CLEAR_TOP.
• Используйте некоторую шину событий, которая поддерживает «липкие» события. Когда пользователь вводит текст, вы отправляете липкое событие в шину событий. В onResume() из Activity вы проверяете, существует ли событие этого типа, а если оно есть - вы обновляете интерфейс.

Еще раз - факт, что вы МОЖЕТЕ делать то, что вы хотите, не означает, что ДОЛЖЕН быть выполнен.

Answer 2

Просто установите в onResume() метод вашего класса А, при вызове экземпляра класса Singleton вы хотите сохранить (или istance класса Application, который является тем же самым)

Answer 3

• LocalBroadcastManager является не является надежным вариантом. Он предполагает, что нижняя активность все еще жива, что может быть и не так. Пока вы используете B, A может быть собрано для освобождения ресурсов. Кроме того, вы должны отменить регистрацию получателей LocalBroadcastManager onResume(). Итак, нет.

• Следует избегать синглетов со статическими полями. Это не беспокоит одну строку текста, но однопользовательские поля легко забываются и могут привести к утечке памяти. Лучше избегать этого шаблона, если это возможно, и в вашем случае это так.

Возможные варианты.

• Если поле является чем-то, что должно сохраняться, например. пользователь, редактирующий свое имя пользователя, используйте SharedPreferences или другое решение для хранения (сохранение на сервере, сохранение в кеш, сохранение в базе данных SQLite устройства).

• Если поле является временным и является результатом деятельности B, вы можете начать деятельность B с startActivityForResult(), а затем отправить результат обратно в действие A через Intent.

Answer 4

Для вашей проблемы самое простое решение - сохранить ваше значение в классе Application. Любое действие может получить к нему доступ и прочитать/записать значения. Недостатки в том, что если вы случайно сохраните статическую ссылку на активность, это вызовет утечку памяти.

Вы можете попробовать использовать EventBus для горизонтальной связи: Activity-> Service, Service -> Fragment и т. Д. По умолчанию он имеет статический экземпляр плюс вы можете подписаться/отказаться от подписки на него в onPause и onResume. Еще одно преимущество STICKY EVENTS - вы можете публиковать события из Сервиса, и он будет ждать, пока что-то его не обработает - Activity получит это событие, когда оно будет готово - после onResume().