, если оба вида ваших действий, используйте достойную модель данных. Android не поощряет очень хорошо разработанное приложение. Или поверните это по-другому, это позволяет быстро разрабатывать приложения и не продвигает большую часть принципа хорошего программного приложения.
Решение @ Jean-Philippe Roy (québec?) Интересно, но синглтон - это довольно антипаттерн, когда речь идет о более сложных вещах, а именно о моделях Statefull или сервисах.
Лучший вариант - использовать класс приложения. Этот класс - твой синглтон, по природе в андроиде. Таким образом,
- определить класс приложения в манифесте
- предоставляет статический метод для доступа к уникальному экземпляру класса приложения (это всегда одноэлементный).
- дайте ему метод получения и хранения ваших данных, вызовите его из вашего первого действия
- и второй, чтобы вернуть их во второе занятие
--- Обновлено после ответа @ straya и еще 18 месяцев программирования на Android:)
Вопрос о совместном использовании структуры данных или процессов в приложении, действиях, представлениях, фрагментах всегда возникает при создании приложения для Android. Важно знать и учитывать, что область приложения является подходящим местом для хранения разделяемой структуры, но использование самого класса приложения для помещения структуры данных в эту область нецелесообразно в отношении:
- Качество кода: если все приложения и структуры общего доступа известны о приложении, оно быстро станет раздутым со средствами доступа для всех этих объектов.
- существует только один глобальный общий пул сущностей, который не является достаточно детализированным и может привести к трудностям в обнаружении способов соединения сущностей
Сейчас я предпочитаю использовать управляемые синглтоны Dependency Injection. Dagger или RoboGuice позволяют создавать и внедрять один экземпляр данного класса в другие классы. Эта техника и DI в целом предлагают большие возможности для хороших дизайнов Android:
- не ухудшают качество кода, он даже значительно сокращен. Используйте @Inject для внедрения зависимостей, и они будут внедрены.
- не возлагайте 2 ответственности на одноэлементный класс: он не будет обрабатывать создание одноэлементного экземпляра, фреймворк сделает это.
- проще перейти от одиночного к нормальному экземпляру
- , поскольку эти синглтоны становятся обычными классами с простой аннотацией, они больше не содержат статических методов, что позволяет очень легко их высмеивать. И это важный момент.
- и, конечно, аннотации DI очень ясно показывают, когда класс зависит от другого класса, помогая больше самостоятельно документировать код.