Не все задачи требуют записи в базу. вы что, каждый чих будете поддерживать, чтобы код обязательно выполнился? Что если юзер запросил адрес по координатам, но при повороте к примеру приложение выгрузилось? Вы что, это будете сериализовывать? Да это же бред.
И это никакое не громоздкое решение, а вполне нормальное, которое поддерживается стандартными средствами, при этом имеет такие фичи, как ContentProvider, CursorLoader и прочее (что позволяет автообновлять списки автоматически и прочие плюшки).
И более того, я не встречал в последнее время выгрузку приложений при поворотах. Ну работают они во многих случаях правильно. Поэтому я спокойно какие-то задачи пишу через лодеры и прочие штуки. Слышали про правило 80/20?
Я конечно рад за вас что вы делаете игры со 100+ закачек (хотя такого результата достигают далеко не все разработчики, стоит это понимать) и что они действительно приносят вам по 20 000 рублей в месяц, но это похоже быстрее на исключение. У вас есть еще примеры, где реклама так отлично работает? У меня к сожалению навалом обратных примеров. И множество статей говорит о том, что это перестало работать.
Кстати, я бы хотел еще услышать мнение минусующих. Мне порой кажется, что на хабре появилась каста, которая только и делает что минусует, при этом боится раскрывать своих стопроцентно правильных умозаключений.
Ну я исхожу из знакомых разработчиков, которые отказались от такой монетизации, ибо плата за рекламу практически ноль. Приложения со скачиваемостью от 100 000 и выше. У вас есть успешные примеры приложений, которые смогли заработать хоть какие-то вразумительные деньги со скачиваемостью от 10 000? Ибо 100 000 это уже очень неплохо (и то, отдачи ноль).
Да и что лукавить, каждый третий комментарий о монетизации Android проекта об этом говорит.
Так что хотелось бы услышать конструктива.
Никто не мешал. Кто хотел — отправлял и голубей, и тянул провода. Кто не хотел — соглашались с условиями тех, кто это сделал. Другими словами, выбор у Вас есть, так что это не монополия общения
Давайте так рассуждать: есть специальные вещи, которые работают с SQLite, такие как ContentProvider. Они работают быстрее и позволяют удобно делать CRUD операции с БД. Чем тут выигрывает механизм сериализации? Ну кроме того, что оно родное. А что если у нас будет стек однотипных задач? Для каждой делать статическую переменную?
Сериализация удобная штука, но тут я не вижу в ней пользы. Более того, человек, который будет читать ваш код, вполне вероятно будет знать как работать с базой данных, а ваш код воспримет как непонятный и в который надо будет вникать.
Дык вы используете механизмы сериализации, в чем тут преимущество перед записью в базу задачи?? Причем тут вообще жизненный цикл, когда речь идёт уже о сохранении задачи на внешний носитель?
Это просто шедеврально сравнивать вещи, где используется ОЗУ с тем, где используется еще и сохранение на внешний носитель
Опять же, если у вас стоит задача железно выполнить операцию, даже когда выключился телефон, то создайте класс «Задача» и пишите его в базу, после чего база пусть работает с сервисом, который будет проверять наличие неотправленных задача.
Если задача не стоит обязательно доставить задачу, если телефон выключился, то задача отправляется в лодере/сервисе обычным образом.
Вы пишете «много писанины», я пишу что пишите меньше и говорю как. Вы начинаете говорить что есть вариант получить проблемы, я говорю что пишите больше и правильней.
Так сделайте foreground! Только используйте его разумно. У нас за 3 года приложение не умирало никогда в данном режиме начиная с телефонов 2.1, а сейчас и подавно, а обработка задач там идет довольно немалая.
С чего это вдруг очистка памяти должна чистить работающие вещи приложения? Системе хватает памяти и она не будет чистить работающие составляющие.
Опять же, если у вас стоит задача железно выполнить операцию, даже когда выключился телефон, то создайте класс «Задача» и пишите его в базу, после чего база пусть работает с сервисом, который будет проверять наличие неотправленных задача.
Если задача не стоит обязательно доставить задачу, если телефон выключился, то задача отправляется в лодере/сервисе обычным образом.
Более того, а почему вы просто не взяли класс унаследованный от Application и не сделали там ваши статические переменные и прочее? Класс Application последним покидает судно корабля выгружается.
С чего это вдруг? Также в бекграунде и обрабатывайте свою картинку, кто же вам мешает. Разберитесь получше с сервисами и лодерами, ибо первые для долгоиграющих задач, вторые для коротких.
Писанины? Ну это Java, тут везде писанина. Хотите правильно — пишите отдельный Loader в отдельном классе, а если не хотите — то создайте поток в пару строк.
Но, если фоновая задача была потеряна при пересоздании процесса, она не запустится второй раз, и пользователь получит экран со значком вечного прогресса.
Когда процесс уничтожается и Activity пересоздаётся из сохраненного состояния, фоновые задачи автоматически перезапускаются.
Процесс — это не поток, а уж тем более не объект (ну если говорить абстрактно). Пересоздается именно объект в рамках того же самого потока. А процесс в большинстве случаев — это всё ваше приложение. Если Ваш процесс умрёт — умрёт и всё приложение со всеми вашими статическими ссылками и прочим.
1. Вы имели дело с Loaders, к примеру AsyncTaskLoader? Он грамотно обрабатывает фоновые задачи при поворотах. Единственный минус — это пересоздание фоновой задачи при повороте. На эту проблему приходит пункт два
2. IntentService — запустил и биндись к нему в onResume для получения статуса задачи, после чего делать вывод, нужны нам данные или нет.
2. Разрекламированная функция Fragment.setRetainInstanceState(true) тут не поможет, потому что такой Fragment сохраняется только для изменений конфигурации экрана.
Вы серьёзно? (метод называется setRetainInstance(boolean state) )
public void setRetainInstance (boolean retain)
Control whether a fragment instance is retained across Activity re-creation (such as from a configuration change). This can only be used with fragments not in the back stack. If set, the fragment lifecycle will be slightly different when an activity is recreated:
onDestroy() will not be called (but onDetach() still will be, because the fragment is being detached from its current activity).
onCreate(Bundle) will not be called since the fragment is not being re-created.
onAttach(Activity) and onActivityCreated(Bundle) will still be called.
Сохраняется как раз таки объект, а вьюшка умирает. Более подробно — здесь
И это никакое не громоздкое решение, а вполне нормальное, которое поддерживается стандартными средствами, при этом имеет такие фичи, как ContentProvider, CursorLoader и прочее (что позволяет автообновлять списки автоматически и прочие плюшки).
И более того, я не встречал в последнее время выгрузку приложений при поворотах. Ну работают они во многих случаях правильно. Поэтому я спокойно какие-то задачи пишу через лодеры и прочие штуки. Слышали про правило 80/20?
Кстати, я бы хотел еще услышать мнение минусующих. Мне порой кажется, что на хабре появилась каста, которая только и делает что минусует, при этом боится раскрывать своих стопроцентно правильных умозаключений.
Да и что лукавить, каждый третий комментарий о монетизации Android проекта об этом говорит.
Так что хотелось бы услышать конструктива.
Сериализация удобная штука, но тут я не вижу в ней пользы. Более того, человек, который будет читать ваш код, вполне вероятно будет знать как работать с базой данных, а ваш код воспримет как непонятный и в который надо будет вникать.
Это просто шедеврально сравнивать вещи, где используется ОЗУ с тем, где используется еще и сохранение на внешний носитель
Вы пишете «много писанины», я пишу что пишите меньше и говорю как. Вы начинаете говорить что есть вариант получить проблемы, я говорю что пишите больше и правильней.
Опять же, если у вас стоит задача железно выполнить операцию, даже когда выключился телефон, то создайте класс «Задача» и пишите его в базу, после чего база пусть работает с сервисом, который будет проверять наличие неотправленных задача.
Если задача не стоит обязательно доставить задачу, если телефон выключился, то задача отправляется в лодере/сервисе обычным образом.
Более того, а почему вы просто не взяли класс унаследованный от Application и не сделали там ваши статические переменные и прочее? Класс Application последним
покидает судно кораблявыгружается.Писанины? Ну это Java, тут везде писанина. Хотите правильно — пишите отдельный Loader в отдельном классе, а если не хотите — то создайте поток в пару строк.
Процесс — это не поток, а уж тем более не объект (ну если говорить абстрактно). Пересоздается именно объект в рамках того же самого потока. А процесс в большинстве случаев — это всё ваше приложение. Если Ваш процесс умрёт — умрёт и всё приложение со всеми вашими статическими ссылками и прочим.
1. Вы имели дело с Loaders, к примеру AsyncTaskLoader? Он грамотно обрабатывает фоновые задачи при поворотах. Единственный минус — это пересоздание фоновой задачи при повороте. На эту проблему приходит пункт два
2. IntentService — запустил и биндись к нему в onResume для получения статуса задачи, после чего делать вывод, нужны нам данные или нет.
Вы серьёзно? (метод называется setRetainInstance(boolean state) )
Сохраняется как раз таки объект, а вьюшка умирает. Более подробно — здесь