Android использует класс приложений в качестве контллера ОК?

Я бы хотел, чтобы все мои действия (от 7 до 10 разных экранов) отправляли данные "контроллеру" (извините, если я пропустил этот термин).

Внутри данные контроллера будут либо загружены, либо сохранены в данных для загрузки, когда нет Интернета. Контроллер будет выполнять проверки и обработку, такие как:

  • Проверка действительного сеанса.
  • Прикрепите другие необходимые учетные данные перед загрузкой и т.д. Данные сеанса/пользователя будут храниться в файле Shared Preferences, на который ссылается контроллер.

Моя цель состоит в том, чтобы действия не делали ничего, кроме как собирать данные и вызывать соответствующий метод (с объектом данных) асинхронно. Контроллер должен знать, как обрабатывать данные для загрузки или сохранения в базе данных.

Помещать эти методы в расширение приложения было бы плохой идеей?

Было упомянуто, что в зависимости от размера приложения это возможно, но могут быть лучшие решения.

1 ответ

В зависимости от размера вашего проекта это было бы подходящей идеей. Однако перед выбором метода, который вы на самом деле реализуете, вы должны знать несколько других способов:

  • Используя ContentProvider для ваших данных, AccountAuthenticator и затем синхронизируйтесь с сервером с помощью SyncAdapter. Преимущества - хорошая абстракция, независимость от действий и множество встроенных функций (например: Android выполняет ваш код без значительного воздействия на батареи). Тем не менее, реализация всего материала - это, в первую очередь, работа. Если вы не хотите использовать ContentProvider, тот же метод работает и с реализацией заглушки, то же самое и для AccountAuthenticator.
  • Использование Service, возможно IntentService, для ваших загрузок. Преимущество заключается в том, что Служба имеет независимый жизненный цикл и, следовательно, напрямую не связана с вашей деятельностью; Служба может быть перезапущена, если она была убита системой. Еще больше работы, чем использование некоторых статических методов.
  • Используя статический метод, который вы предлагаете (в вашем случае, объект Application, не полностью статический, но сравнимый). Довольно легко реализовать, возможно, лучший способ, если в нескольких действиях есть похожие задачи; ваш AsyncTask s может отправить свой результат непосредственно AsyncTask которое запустило его. Однако не подходит для длительных задач.
  • Реализация в рамках Мероприятия; Если код используется только один раз; перечисленные только для полноты, а не для вашего дела. В основном то же самое, что и при использовании статического метода.

Это те, которые появились у меня в голове, могут быть и другие. Не стесняйтесь добавлять/предлагать дополнительные.

licensed under cc by-sa 3.0 with attribution.