Передача значений между активностями

Добрый день. Как можно передавать значения переменных между активностями? У меня задача такая: имею четыре активности, одна это заголовок, вторая и третья имеют по два радиобаттона , нажатия на которых прибавляют значения к переменым(а и b). А на четвертой выводятся переменные(a,b), и их значения(то есть сколько нажали первый радиобаттон и сколько нажали второй).

0

Снова споры о высших материях, смысл того, что вместе с extra я предложил sharedPref просто потому, что для ТС разницы никакой, а вот ошибку при нажатии назад на какой-нибудь 3-4й активити словит точно.

0

ExFau$t, позвольте с вами не согласиться, коллега) статика хотя бы дает проверку имени и типа, а засовывание в sharedPref кроме гемороя с самим засовыванием/высовыванием дает возможность налететь на лишнюю букву в имени записанном в виде строки или несоответствие содержимого. в sharedPref надо класть если нужно обеспечить сохраняемость между запусками. в остальных случаях это ад адский, но вы его предлагали как один из вариантов костылей, поэтому претензий не имею, да, логически - это один из вариантов.

Добавлено через 2 минуты
..хотя может быть я просто не знаю молниеносных и безопасных способов трансформации произвольного объекта в экстру или не сильно от нее в плане разработки отличающийся преф

0

vxg, не пользуюсь статиками, вот и не предлагаю, коллега). Да ошибка в имени переменной может случиться с такой же вероятностью, как и полях SharedPref. Хотя, действительно, это тоже один из вариантов.

Добавлено через 4 минуты
Ну не знаю, на вкус и цвет.. Но лично мне SharedPref очень нравится не только в плане хранения каких-то настроек, но ещё как мини-бд, в некоторых случаях даже логгер, невероятно удобная штука.

1

я уже раз 5 точно писал что практически что угодно можно передавать как строку
кладем
достаем

2

Паблито, у меня это до сих пор перед глазами - это реально мощно хоть я ни разу и не делал так, но все равно остаётся проблема ошибки в имени и типе. Да и просто стремно туда сюда переливать то что уже у тебя есть

0

Паблито, может быть проблема при декодировании сложных типов. Также при преобразовании вещественных в целые, в этом случае приходится писать обработчики.

0

пример класса в студию, а я покажу как это сделать

и я повторю очевидное - если возникает необходимость передавать сложные структуры (объекты) между активностями, значит что-то хромает в архитектуре
активити, по идее, это малосвязанные или вообще не связанные между собой компоненты

0

Сообщение от Паблито пример класса в студию, а я покажу как это сделать

Да не, я уже делал, у людей на SO такая проблема встречалась, так что не стану.

Сообщение от Паблито если возникает необходимость передавать сложные структуры (объекты) между активностями, значит что-то хромает в архитектуре

Я использую обычно фрагменты, но перейду на активности. Допустим, есть регистрация заказа в несколько шагов. Эти данные передаются между фрагментами или активностями (не важно) через Bundle. Данные достаточно объёмные могут быть. Никакой ошибки в архитектуре не вижу.
Кроме того, хотел сказать, что SharedPreferences не есть противник Intent, их можно использовать одновременно как раз для случая выхода из программы или неожиданного перехода с активности 3 на активность 2.

0

Раз холивар, то выскажу свое ИМХО.
ExFau$t, есть отличная либа Hawk для упрощения работы с запись\восстановлением объектов в SharedPreferences. Юзается в паре проектов, отлично себя показывает. Может вам пригодится. Но я все же придерживаюсь мнения, что для передачи объектов между View SharedPreferences излишни.
vxg, чтоб избежать ошибки в имени и типе, создание bundle должно происходить там, где он используется. И объекту можно дать интерфейс Serializable и без проблем передавать через Intent.
По поводу потери типа или ключа: только View должна знать какие ей параметры нужны. Поэтому создание intent+bundle, fragment+bundle, view+bundle должно происходить в самой View в статик методе. Пример этому то, как AS создает getInstance для фрагментов. И использование констант вместо magic string|numbers. Тогда всегда видно какой тип передан и какой ключ. И не приходится искать по всем другим классам, где же был создан этот bundle.
CoolMind, согласен с Паблито, если между View передаются сложные объекты - это не правильно. Должны передаваться идентификаторы, а сами объекты должна хранится в каком нибудь хранилище (просто в кеше, в SharedPreferences, DB, etc). И по идентификатору извлекаться из него. Соответственно они там будут в единичном экземпляре и всегда актуальны, если правильно все сделано.

0

demixdn, у меня нет проблем с SharedPref, спасибо за заботу. Я не передаю объекты "между View". Да и связывать активити редко приходится, просто нет в этом необходимости.

0

demixdn, бинго - они должны хранится в хранилище и извлекаться по идентификатору - просто представьте статик объект в виде умного хранилища)

0

vxg, не обязательно он статик. это зависит от подхода. да, скорей всего он будет существать в одном экземпляре. Может это будет синглетон, а может его кто-то будет инжектить с помощью DI. И совсем не обязательно что это хранилище для всего. Всегда можно что-то декомпозировать и разбить на более мелкие независимые части.
И уровень хранения тоже вполне зависит от задач. Либо этот кеш есть в презентере, либо он есть в репозитории, либо просто класс MemoryCache для своих репозитариев, либо вообще отдать на откуп какой-нибудь либе типа Store (но еще не находилось случая, чтоб пришлось использовать столь наворочанную либу).

0

Сообщение от demixdn если между View передаются сложные объекты - это не правильно

Совершенно не согласен. Во-первых, зачем тогда вообще Intent, Bundle, давайте всё делать через SharedPreferences, там же и будем отслеживать актуальность переданных данных (и не дай бог, где-то что-то перезапишется, пока вы что-то передаёте через SP).
Во-вторых, при пересоздании активности (фрагмента) надо уметь восстанавливать данные, которые хранятся в Bundle. Опять пойдём в SP?

0

CoolMind, bundle используется только для передачи идентификатора или пути на что-то (файл, url). Объекты хранить в другом хранилище, отвязанном от жизненного цикла activity|fragment.
Пересоздание - это вообще отдельная тема. Все хорошо, если у вас поток один и у вас все поля инициализируются и заполняются в onCreate, что что если какие то данные асинхронные и прилетают после onResume. После переворота старые данные в onCreate в полях записались, после в onRestoreInstanceState перезаписались на новые (но не сохраненные). Но исходный bundle содержит старые данные. И в соответствии с ними какой нибудь поток вернет данные и перезапишет их снова, поверх измененных. И поэтому приходится выкручиваться, записывать руками в Bundle savedInstanceState свои данные, чтоб уже в оnCreate у нас были актуальные данные. Да, случай частный. Но я часто видел, что некоторые данные в поля пишутся в onResume, что опять же ставит ту же проблему, руками прописывать свой bundle.
Вот это все нужно держать в голове и помнить о таких моментах. Вместо того чтоб юзать идентификаторы и в onPause вызывать функцию saveMyObject.
В любом случае, мне так удобней. Если вам удобней в bundle все совать, ну ладно. Главное, чтоб все работало и тестировалось.

0

demixdn, возможно, мы друг друга не так поняли. Я в целом с вами согласен, всё это очень интересно, но имел в виду, что я передаю в Bundle сложный класс, состоящий из множества других классов, может быть. Он Serializable, не содержит внутри себя Bitmap, файлов или каких-то затратных по памяти объектов. Просто сам по себе сложный. В этом случае SP тоже не выручает, если мы передаём данные через JSON. Т.е. по сути, JSON с классом что в Bundle, что в SharedPreferences одинаков.
Выше Паблито писал про
intent.putExtra,
new Gson().fromJson(intent.getStringExtra.
Это же самое я могу сделать и в SharedPreferences. Возможно, вас смутила фраза:

Сообщение от CoolMind Данные достаточно объёмные могут быть.

Да, я малость неправильно выразился. Конечно, никаких Bitmap, ресурсов не передаю через Bundle. Просто достаточно сложный класс. И в этом случае возникает проблема декодирования JSON (и это уже не зависит от SP, Bundle).

0