Да тут и в месяц не факт. У меня музыкальное приложение на то время, что я пробовал рекламу во фри версии было ~80k через AdMob. Приносило копейки. Возможно, геймеры больше любят смотреть рекламу, чем музыканты.
100 000 активных пользователей? 500 баксов в день? ЛОЛШТО? 100000 еще не факт, что в месяц столько принесут. Особенно учитывая, что это еще и от приложения зависит.
Как-то попал в этот список год назад, провисел 2 недели. Что самое интересное, тогда приложение не соответствовало особо никаким UI guidelines. Просто было популярным в категории. Позже сделал редизайн, хороший сделал красивый дизайн с акшн барами и все такое, с анимациями. И чет пока не особо рекомендуют :(
О, Боги, да!!! Наконец-то появится шанс отвечать оленям, задающим вопросы в коментах к приложению и меняющим статус на 1 звезду, не получив ответа!!! Хотя, с другой стороны, я лично всегда боялся этого… потому что иногда хочется ответить такое, за что забанить могут :)
Если включить мозг и понять, что предложенный подход нигде ничем не обязывает использовать IntentService, то можно прийти к выводу, что нет, позволяет, только нужно реализовать свой сервис, скажем, с ExecutorService.
Я бы не стал AndEngine называть «оберткой» над OpenGL. Он позиционируется как полноценный движок со всеми преимуществами и недостатками. Наоборот, libgdx автором позиционируется скорее как framework, упрощающий работу с OpenGL. Т. е. гибкость libgdx, наряду с производительностью выше, в то время как, AndEngine проще в освоении, но не даст такой гибкости.
А звучит именно так. «Написанные стандартными SDK средствами приложения — говно, а разработчики, старающиеся выжать последнюю каплю производительности, скажем, используя курсор, bulkInsert с инсерт хелпером, компилирующим statement единожды для вставки, скажем, 10000 записей за 200мс на самом деле просто лохи, т. к. не используют навороченный ORM.»
«Но не типичных для Google Play, написанных, очевидно, задней левой mНогой, а приложений корректных и элегантных.» т. е., по-вашему, приложение, не использующее плюшек типа ioc, orm, и прочего мусора по-умолчанию считается написанным некорректно, неэлегантно, и вообще г*вно?
вот, кстати, второй вопрос тоже меня очень интересует — где пишут шейдеры? Есть ли какой-то «IDE» для этого или плагин хороший? Все, что я смог найти — это шейдертой, что не совсем то, конечно, хотя и полезно тоже.
Ну… не совсем прям азы, конечно. В очень базовых вещах я и сам разобрался, прочел хорошие книжки как по opengl, так и по геймдеву, т. е. в целом, о чем речь идет понимаю. Просто, очень сложно находить реальные примеры, на которых можно учиться, разбираться и т. п.
Спасибо! Это очень интересно. Я только начинаю осваивать азы графики, опенгл и т.п., поэтом, для меня такая статься — просто клад. Было бы очень здорово, если бы Вы написали статью и про загрузку моделей!!!
Код всей программы выложить не могу, т. к. это коммерческий продукт. В общем, код приведенный в статье содержит все основные элементы фреймворка, используемого в программе (с измененными именами переменных, но смыслом тем же), осталось собрать в кучу. Я постараюсь, как время будет, слепить простенький примерчик, основанный на этом подходе.
С интент сервисом особо элегантного способа и нет. Однако, простейшее прерывание можно организовать и на нем. Как я себе вижу:
Во-первых, командам добавляем флаг isCancelled и проверяем его во время выполнения команды, если он == true, немедленно прекращаем все действия. Т. к. в интент сервисе мы всегда знаем, какая команда выполняется, мы можем просто выставить ей этот флаг. Для этого просто оверрайдим onStartCommand(...) и, если приходит ACTION_CANCEL, тормозим текущую команду, иначе super.onStartCommand(...). Разумеется, если команда уже выполняется и, скажем, в середине HTTP запроса на 10 секунд (что тоже не фонтан, конечно, но бывает), то дождаться ее завершения в любом случае придется, ничего не поделаешь.
Если нужны более продвинутые прерывания, лучше всего сделать свой сервис и использовать пул потоков (ExecutorService). Там у нас всегда будет future выполняемых тасков и мы можем интерраптнуть выполнение. Организовать очередь по-прежнему можно при помощи newFixedThreadPool, а, если надо — всегда можем держать несколько потоков. Единственное — в этой ситуации (параллельное выполнение) лучше избегать stopService, а использовать именно stopSelf, когда завершает выполнение последняя задача завершится. Лично я предпочитаю всегда добавлять cooldown на минутку прежде, чем окончательно убивать сервис. Если за минутку приходит новая таска, кулдаун сбрасывается, и мы избегаем лишних завершений и стартов сервиса. Это легко делается Handler'ом.
Да, но когда я говорил, о том, что нужно в манифесте своего приложения добавить одну строчку, я именно об одном приложении и говорил, очевидно :) О взаимодействии разных package-ей — другая история, и у меня как раз назревает статья о том, как я делал плагин, играющий аудио семплы к своему MIDI приложению. Там как раз отдельный APK, другой пакет процесс, и т. п.
Если про этот, то да, ответ выполняется в UI потоке, и так и должно быть, т. к. уже непосредственно будет модифицироваться UI. По-поводу хендлера, да, Вы правы, каждый раз создавать новый инстанс бессмысленно, мой недочет. Ничего смертельного, конечно, но ненужные объекты, в общем-то не нужны :)
Во-первых, командам добавляем флаг isCancelled и проверяем его во время выполнения команды, если он == true, немедленно прекращаем все действия. Т. к. в интент сервисе мы всегда знаем, какая команда выполняется, мы можем просто выставить ей этот флаг. Для этого просто оверрайдим onStartCommand(...) и, если приходит ACTION_CANCEL, тормозим текущую команду, иначе super.onStartCommand(...). Разумеется, если команда уже выполняется и, скажем, в середине HTTP запроса на 10 секунд (что тоже не фонтан, конечно, но бывает), то дождаться ее завершения в любом случае придется, ничего не поделаешь.
Если нужны более продвинутые прерывания, лучше всего сделать свой сервис и использовать пул потоков (ExecutorService). Там у нас всегда будет future выполняемых тасков и мы можем интерраптнуть выполнение. Организовать очередь по-прежнему можно при помощи newFixedThreadPool, а, если надо — всегда можем держать несколько потоков. Единственное — в этой ситуации (параллельное выполнение) лучше избегать stopService, а использовать именно stopSelf, когда завершает выполнение последняя задача завершится. Лично я предпочитаю всегда добавлять cooldown на минутку прежде, чем окончательно убивать сервис. Если за минутку приходит новая таска, кулдаун сбрасывается, и мы избегаем лишних завершений и стартов сервиса. Это легко делается Handler'ом.