Я конечно рад за вас что вы делаете игры со 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.
Сохраняется как раз таки объект, а вьюшка умирает. Более подробно — здесь
Я читал на хабре про гугл, не помню к о чем речь шла, но суть такова: Ларри Пейдж говорил, что поначалу они хотели обойтись без менеджеров, но очень скоро пришло понимание, что разработчики тратят много времени «не туда», ибо сваливается множество организационных вопросов и прочего.
Я считаю, что наша главная особенность – качество нанимаемых нами инженеров. Главное их свойство в способности быть проактивным. Люди, работающие с нами, сами себе предприниматели – им не нужен человек, который постоянно проверяет, работают ли они.
Ну если команда небольшая и у вас вот только такие проактивные люди, которые заинтересованы в росте Вашей компании, то поначалу такое и прокатит. Думаю это пройдет, если ваше дело перенесет бурный рост и разработчиков уже будет не хватать, и придется нанимать других разработчиков.
>Айфон является фактически полным подмножеством андройда, практически ничего не добавляя в плане удобства/функционала. Может, поэтому андрой, сколько там, 80 с лишним процентов рынка занимает?
Ага, и при этих 80 с лишним процентов, имеет меньше 20 процентов выручки по сравнению с Apple. Я вам как Android разработчик скажу, даже спрошу: где будет качественней софт написан, на ОС где есть всего несколько устройств и где есть премодерация автоматическая и ручная, или где премодерация пропускает весь отстой и где 15 000 разных устройств со своими аппаратными багами?!
Жесткая политика Apple отсеяла много сырого софта, а также разработчиков (не каждый захочет покупать Mac + устройства, + 100 долларов в год платить, против гугла, где 25 долларов на всю жизнь).
И я еще молчу про то, что скоро Google перейдёт на Art, а еще Google движется к цели, что теперь нельзя будет устанавливать приложения на внешнюю память и похоже скоро будет другая политика безопасности к внешним папкам, нежели сейчас. Это я только вскользь вспомнил. И еще раз замечу, я под Android пишу, при этому у меня было много Android устройств и пару айфонов.
Тема из серии холиваров, в которые я не хочу вступать, я просто хочу заметить, что помыслите более глобально, не только с точки зрения железа и самой ОС. В наше время ОС удовлетворяет 99.99 процентам юзеров (любая).
Кстати, я бы хотел еще услышать мнение минусующих. Мне порой кажется, что на хабре появилась каста, которая только и делает что минусует, при этом боится раскрывать своих стопроцентно правильных умозаключений.
Да и что лукавить, каждый третий комментарий о монетизации Android проекта об этом говорит.
Так что хотелось бы услышать конструктива.
Сериализация удобная штука, но тут я не вижу в ней пользы. Более того, человек, который будет читать ваш код, вполне вероятно будет знать как работать с базой данных, а ваш код воспримет как непонятный и в который надо будет вникать.
Это просто шедеврально сравнивать вещи, где используется ОЗУ с тем, где используется еще и сохранение на внешний носитель
Вы пишете «много писанины», я пишу что пишите меньше и говорю как. Вы начинаете говорить что есть вариант получить проблемы, я говорю что пишите больше и правильней.
Опять же, если у вас стоит задача железно выполнить операцию, даже когда выключился телефон, то создайте класс «Задача» и пишите его в базу, после чего база пусть работает с сервисом, который будет проверять наличие неотправленных задача.
Если задача не стоит обязательно доставить задачу, если телефон выключился, то задача отправляется в лодере/сервисе обычным образом.
Более того, а почему вы просто не взяли класс унаследованный от Application и не сделали там ваши статические переменные и прочее? Класс Application последним
покидает судно кораблявыгружается.Писанины? Ну это Java, тут везде писанина. Хотите правильно — пишите отдельный Loader в отдельном классе, а если не хотите — то создайте поток в пару строк.
Процесс — это не поток, а уж тем более не объект (ну если говорить абстрактно). Пересоздается именно объект в рамках того же самого потока. А процесс в большинстве случаев — это всё ваше приложение. Если Ваш процесс умрёт — умрёт и всё приложение со всеми вашими статическими ссылками и прочим.
1. Вы имели дело с Loaders, к примеру AsyncTaskLoader? Он грамотно обрабатывает фоновые задачи при поворотах. Единственный минус — это пересоздание фоновой задачи при повороте. На эту проблему приходит пункт два
2. IntentService — запустил и биндись к нему в onResume для получения статуса задачи, после чего делать вывод, нужны нам данные или нет.
Вы серьёзно? (метод называется setRetainInstance(boolean state) )
Сохраняется как раз таки объект, а вьюшка умирает. Более подробно — здесь
Ну если команда небольшая и у вас вот только такие проактивные люди, которые заинтересованы в росте Вашей компании, то поначалу такое и прокатит. Думаю это пройдет, если ваше дело перенесет бурный рост и разработчиков уже будет не хватать, и придется нанимать других разработчиков.
Ага, и при этих 80 с лишним процентов, имеет меньше 20 процентов выручки по сравнению с Apple. Я вам как Android разработчик скажу, даже спрошу: где будет качественней софт написан, на ОС где есть всего несколько устройств и где есть премодерация автоматическая и ручная, или где премодерация пропускает весь отстой и где 15 000 разных устройств со своими аппаратными багами?!
Жесткая политика Apple отсеяла много сырого софта, а также разработчиков (не каждый захочет покупать Mac + устройства, + 100 долларов в год платить, против гугла, где 25 долларов на всю жизнь).
И я еще молчу про то, что скоро Google перейдёт на Art, а еще Google движется к цели, что теперь нельзя будет устанавливать приложения на внешнюю память и похоже скоро будет другая политика безопасности к внешним папкам, нежели сейчас. Это я только вскользь вспомнил. И еще раз замечу, я под Android пишу, при этому у меня было много Android устройств и пару айфонов.
Тема из серии холиваров, в которые я не хочу вступать, я просто хочу заметить, что помыслите более глобально, не только с точки зрения железа и самой ОС. В наше время ОС удовлетворяет 99.99 процентам юзеров (любая).