Хотел бы с Вами поделиться опытом создания своей первой мобильной игры. Весной 2012 года глядя на аркадные «мотоциклы» своего знакомого, которые занимали верхние места в рейтинге Google Play, загорелся тоже сделать нечто подобное. Выбор пал на зомбодавилку, таких игр целая масса, но я думал выделиться полноценной 3d графикой, гаражом с возможностью прокачки техники. Опыт создания игр на движке Unity3d уже был, но под мобильные устройства делал впервые. Разумеется, делал не сам, а с художником, в свободное время.

Рейтингов рекламных сетей много, и я не претендую на составление еще одного. Просто я уже давно выпускаю игры для iOS и Android и раньше применял во всех одну и ту же схему монетизации. Со временем она сильно устарела и перестала приносить стабильный доход. Пришлось что-то менять и усиленно экспериментировать с другими рекламными сетями. Именно этими экспериментами я и хочу поделиться. И сразу же хочу уточнить, что ниже речь пойдет в основном о российском трафике, который в моих приложениях составляет порядка 90%.

Предисловие: Я — самый обычный индивидуальный разработчик Android-приложений, одно из своих детищ я уже давненько опубликовал в Google Play, после чего усердно над ним работал. В какой-то момент я решил — «Почему бы не попробовать продвинуть приложение?». Для этого я принялся усердно читать различную литературу на эту тему. В последствии пришел к идее попробовать купить мотивированные установки (о том, что это читайте ниже). Было принято решение продвигаться конкретно в США. Собственно далее — то, что у меня получилось, что я попробовал.

Мои правила

Каждый раз, когда у меня возникает проблема в производительности, я следую этим правилам:

• Всегда измеряйте — оптимизация с помощью глаз плохая идея. Когда вы просмотрели ту же анимацию несколько раз, вам кажется, что она выполняется быстрее. Цифры не врут. Используйте инструменты, о которых я расскажу, и измеряйте поведение вашего приложения несколько раз до и после того как делаете изменения.
• Используйте медленные устройства — Если вы хотите найти все слабые места, вам больше помогут медленные устройства. Новые и производительные устройства не будут показывать ваши возможные проблемы производительности и не у всех ваших пользователей есть топ устройства.
• Компромиссы — Оптимизация производительности всецело состоит из компромиссов. Вы оптимизируете одно в обмен на другое. Во многих случаях этот другой компромисс может быть потраченным временем на нахождение и исправление производительности, также он может быть качеством ваших растровых изображений или количеством данных которые вы должны хранить в определенной структуре данных. Приготовьтесь жертвовать чем-либо.

Статья была создана для разработчиков которые желают найти новые инструменты и библиотеки для дальнейшего упрощения рутинной жизни.

Итак, начнем.

Butterknife

Библиотека была разработана компанией Square и сразу же прижилась у разработчиков. ButterKnife был создан на замену findViewById для того чтобы уменьшить и без того раздутые activity:

View someView = (View) findViewById(R.id.someView)

Вы только посмотрите какая длинная строка! А если это поле класса — то это целых две строки:

View someView; //Первая строка
...
@Override 
 protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        someView = (View) findViewById(R.id.someView); //Вторая строка
}

А теперь перейдем к ButterKnife. Вот простой пример кода с ButterKnife:

    @BindView(R.id.someView1) View view1;
    @BindView(R.id.someView2) View view2;
    @BindView(R.id.someView3) View view3;
    ...
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this); //Важная строка
    }

Все очень просто: с помощью аннотации @BindView мы говорим какая вьюха нам нужна, и потом главное не забыть про ButterKnife.bind(this);(Так делать нужно в активити, для других мест вроде holder или fragment это делают немного по-другому. Смотрите здесь.

Как добавить к проекту?

Используя и изучая приложения с открытым исходным кодом, вы можете научиться, как создавать хорошие приложения самостоятельно.

Ниже перечислены лучшие проекты под Android с открытым исходным кодом. Благодаря им вы сможете узнать массу отличных практик для разработки под Android.

Нам бы хотелось поделиться с вами опытом, который мы, в Futurice, получили, разрабатывая Android-приложения. Надеемся, эти советы уберегут вас от создания собственных велосипедов. Если вы интересуетесь iOS или Windows Phone разработкой, обратите внимание на соответствующие документы на нашем сайте.

Знакомая картина?

Рано или поздно любого начинающего андроид-разработчика перестает удовлетворять стандартный набор элементов управления. При этом имеется в виду как внешний вид, так и функциональность. И если с внешним видом все более или менее понятно, все достаточно легко кастомизируется, то функционала часто не хватает.

Когда (уже достаточно давно) в одном из своих проектов я столкнулся с необходимостью выбора в настройках одного из трех параметров, решение было очевидно — RadioButton. Но по ряду причин, типа экономии места на экране и некоторых других, возникло желание использовать нечто вроде ToggleButton. Поскольку стандартный Toggle имеет лишь два состояния, был использован костыль в виде программной обработки некоей циклично меняющейся переменной, в зависимости от которой менялись свойства стандартного элемента вроде обычной Button или ImageButton – уже даже не помню. Способ вполне работоспособный, однако не без греха. Первый и самый главный – нарушается Генеральная линия партии, призывающая к раздельному хранению ресурсов и программного кода. Ну и при большом количестве подобных элементов управления код теряет всю свою изящность и привлекательность. Инкапсуляция, опять же, жутко страдает. Посему было решено создать кастомный элемент.

Вместо введения

Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).

Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.

Лично мне такое поведение Android логичным не кажется. Пользователь зачастую просто чистит Recent Apps от давно забытого хлама, совсем не обязательно он при этом желает отказаться от тех благ, которые ему предоставляла выполняющаяся служба. Однако разработчики Google мыслили немного по-другому. По-другому, так по-другому, их право, но в конце концов нам с вами тоже надо как-то жить.

Всем привет! В последнее время появилось много средств, библиотек, которые существенно облегчают написание кода под Android. Только успевай за всем следить и все пробовать. Одним из таких средств является библиотека Dagger 2.

В сети уже много различного материала, посвященного данной библиотеке. Но когда я только начинал ознакамливаться с Dagger 2, читал статьи, смотрел доклады, я во всем этом находил один общий недостаток — мне, как человеку, не работавшему со Springом и прочими подобными фреймворками/библиотеками, было довольно сложно понять, откуда берутся зависимости, как они "провайдятся" и что вообще там происходит. На слушателей/читателей обычно сразу "вываливается" большое количество кода с новыми аннотациями. И это как-то работало. В итоге, после доклада/статьи в голове все никак не могло сложиться в единую понятную картину.

Сейчас, оглядываясь назад, я понимаю, что мне тогда очень не хватало схематичного отображения, картинок, явно показывающих "что, откуда и куда". Поэтому в своем цикле статей я постараюсь восполнить данный пробел. Надеюсь, это поможет новичкам и всем заинтересованным лучше понять Dagger 2 и решиться попробовать его у себя в проекте. Могу сразу сказать, это стоит того.

И да, изначально я хотел написать одну статью, но материала и картинок вышло уж как-то много, поэтому информацию я буду выкладывать небольшими порциями, чтобы читатель мог постепенно погружаться в тему.

В жизни каждого андроид разработчика настаёт момент, когда количество самописных утилит и хелперов, качующих из проекта в проект, переваливает за десяток. В этом случае хорошей практикой будет оформление подобных хелперов в виде самостоятельных «модулей» в терминах Android Studio. Еще лучше, если Вы собираетесь поделиться Вашими наработками с комьюнити, снабдив исходный код подходящей лицензией. Но просто залить исходники на GitHub в этом случае будет недостаточно – хочется, чтобы любой желающий мог подключить библиотеку с помощью однострочной Gradle зависимости, например такой:

dependencies {
   compile 'com.github.romangromov:simpleprefs:0.0.8'
}

О том, как этого добиться и пойдет речь в данной статье.

Android-проекты бывают большими. Иногда действительно большими. Один из наших проектов — новостное приложение, которое разрабатывается одновременно под две альтернативные платформы: Android и FireOS, что от Amazon. Это позволяет расширить круг читателей новостей, ведь пользователи читалок Kindle Fire любят почитать:). Однако, это же накладывает обязательство считаться с особенностями каждой из платформ. Например, если в Android вы используете GCM для push-сообщений, то в FireOS вы должны использовать для этого Amazon AWS. Аналогично и для систем покупок внутри приложения: Google in-app billing vs. In-App Purchasing. Но большой размер проекта != большой размер приложения!

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

Что готовим?

Привет, Хабр! Настало время, когда можно сказать, что «new build system» Gradle является стандартом отрасли Android-разработки. Инструмент сделан настолько просто и удобно, что большинство разработчиков не испытает трудностей, даже не зная, как он устроен, и какие дополнительные возможности в нём есть — возникающие проблемы легко решаются с помощью 5 минут на StackOverflow, путем копирования «магического кода» в конфигурационные файлы. Возможно, в том числе из-за этого не все разработчики изучают Gradle детально и не знают о многих его полезных возможностях, которые существенно облегчают жизнь.

В данном материале можно будет увидеть различные инструменты и подсказки, которые здорово облегчают жизнь Android разработчикам. Большая часть собрана напрямую от знакомых разработчиков и содержит вещи, которые должен знать каждый. Дополнения и расширения приветствуются, и если вы знаете о каком-то крутом механизме, который не был упомянут в статье, не поленитесь перейти в оригинал и открыть pull request.

Несколько лет назад, я, как и другие начинающие Android-разработчики, решил найти работу в этой области. Если вы начинающий специалист, и не знаете, с чего начать изучение Android, или если вы уже обладаете определёнными знаниями в этой теме и планируете в скором времени устраиваться на работу, то этот материал для вас. По задумке, к данной статье вы будете возвращаться по мере накопления опыта: смотреть на каком этапе в данный момент находитесь и что изучать дальше.