Риски при запуске деятельности из контекста приложения? - PullRequest
Новая
       37

Риски при запуске деятельности из контекста приложения?

1 голос
/ 23 мая 2019

Одноэлементный класс неактивности управляет вызовами API сервера во всем приложении.В случае сбоя связи класс менеджера должен запустить действие входа в систему (launchMode="singleTask").

Класс менеджера не содержит контекста, поэтому действие входа в систему запускается из контекста приложения: 

Intent intent = new Intent(App.getInstance().getApplicationContext(), LoginActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_CLEAR_TASK | Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_NO_ANIMATION);
App.getInstance().getApplicationContext().startActivity(intent);

App.getInstance() в этом отношении возвращает синглтон экземпляра MultiDexApplication.

Кажется, что он работает.

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

Единственный недостаток, который я обнаружил, заключается в том, что контекст приложения является «не тематическим», ноактивность выглядит как и ожидалось.Так что, похоже, это не проблема?

Есть ли проблемы с этим подходом?

1 Ответ

1 голос
/ 23 мая 2019

Единственный недостаток, который я обнаружил, заключается в том, что контекст приложения "не тематический", но активность выглядит так, как ожидалось.Так что, похоже, это не проблема?

У действия есть свой собственный Context, который будет связан с его собственной темой.Правило «не использовать Application для пользовательского интерфейса» больше подходит для раздувания макетов - если вы находитесь в упражнении, используйте упражнение для такого рода работы.

Есть ли какие-либопроблемы с этим подходом?

Я не фанат, мне пришлось некоторое время поддерживать приложение, которое использовало этот подход:

  • Это сделаеттестирование синглтона затруднительно, особенно с помощью этой жестко запрограммированной ссылки на ваш Application

  • Пользователь может не оценить, как вы стираете задний стек, если у вас нет других способов возвратапользователь, где он находился в то время

  • Это затруднит выполнение фоновой работы, так как вам не нужно показывать аутентификационные действия на ровном месте (до точки, где они запрещены)на Android Q и выше)

  • Это может вызвать дополнительные проблемы в многооконных средах (как с разделенным экраном, так и в произвольной форме)

  • Източка зрения разделения проблем, этоэто просто уродливо (синглтон без UI не должен делать вещи UI, такие как показ UI)

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

...