Всем привет! Решил я поделиться с Вами опытом «бесплатного пиара» в Google Play, а именно способами для достижения 2K установок в день без денежных вложений. Вся статистика прилагается +информация о доходах

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

Статистика, указанная в статье, собрана с нового приложения, которое живет с 24 мая 2017

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

Отзывы, конечно, со временем появятся, но что делать, если приложение опубликовано недавно и требуется быстро получить обратную связь в виде оценок и комментариев?

Согласно статистике, отзывы и оценки оставляет не более 5% пользователей. Это очень мало. Но, к счастью, существуют способы увеличить это число:

• Шантаж: заблокировать приложение пока не будет поставлена пятерка
• Покупка оценок и отзывов
• Привлечение бирж по обмену отзывами
• Попросить существующих пользователей

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

Использование бирж по обмену отзывами (например, Exchange App Reviews, AppReviewMe) кажется более честным вариантом, но всё же и там есть свои недостатки: рецензенты удаляют приложения после написания комментария, что снижает его вес в магазине приложений.

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

Компания IBM уже много лет публикует материалы о своих разработках на Хабрахабре. Мы рады, что многие статьи интересны читателям. Тем не менее, мы также не раз видели желание наших читателей начать работу с сервисами и ресурсами IBM на бесплатной основе. И сегодня мы рады сообщить о том, что теперь многие пользователи смогут получить бесплатный доступ к большинству ресурсов Академического хаба, IBM Bluemix, когнитивным технологиям IBM Watson и Интернета вещей.

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

Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.

Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.

Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.

Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):

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

Поскольку современный Андроид не предоставляет инструментов для автоматического форматирования произвольного текста, эту задачу каждый решает своими костылями силами. Сначала в наших проектах эта задача решалась по месту: возникла необходимость — напиши свой TextWatcher и форматируй как надо. Но мы быстро поняли, что так делать не стоит — количество локальных костылей и специфических багов росло экспоненциально. Кроме того, задача весьма общая, так что и решать её надо системно.

Для начала хотелось следующего:

1. Указал маску вроде +7 (___) ___-__-__
2. Повесил её на EditText
3. ...
4. PROFIT

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

Начав работать над этим направлением, мы осознали, что создание полноценного языка описания формата — это сродни написанию своего RegEx-движка, что, честно говоря, в наши планы не входило. В итоге мы пришли к варианту, когда такой язык при необходимости можно добавить в любой момент (даже в клиентском коде) или пользоваться простеньким DSL, доступным из коробки (что в нашей практике решило 90% задач).

Посмотрев на то, что получилось, мы решили, что это круто, и надо бы поделиться с сообществом. Так у нас и родилась библиотека для Android-разработки Decoro. И сейчас я покажу пару фокусов из её арсенала.

Решил я однажды таки попробовать дико популярный нынче Rx. А заодно и Retrofit. И посмотреть, как с их помощью реализовать стандартную задачу: получить с сервера набор данных, отобразить их и при этом ничего не терять при поворотах экрана и не делать лишних запросов. Первый вариант у меня получился сразу почти — просто взял и вызвал cache() на Observable, получаемый из синглтона, но он меня не устраивал — для принудительного обновления приходилось, по какой-то причине, пересоздавать экземпляры классов Retrofit и его же реализации моего интерфейса для API. Пересоздание же самого Observable эффекта не давало — всегда возвращались старые данные вместо запуска нового сетевого запроса и получения новых данных.

После долгих мучений с новой для себя технологией выяснил, что во всём был виновен cache() (точнее, наверное, моё неправильное оного понимание). В итоге сделал так: фрагмент запускает метод, подписывающий Subscriber синглтона на Observable retrofit-a, коий запускает onNext и onError BehaviorSubject-a, на который подписывается уже Subscriber фрагмента. Код на GitHub тут, подробности — под катом.

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

Данная статья является переводом статьи Emrullah Luleci, а также её продолжения.

Нижний экран (Здесь и далее под «нижним экраном/слоем» будет подразумеваться элемент bottom sheet — прим. пер.) — компонент, выезжающий снизу экрана, который используется для отображения дополнительного контента. Подробнее об этом элементе можно узнать на официальной сайте посвященном материальному дизайну.

Вслед за инструкцией по публикации приложения в App Store выкладываем внутренний свод правил Лайв Тайпинг по публикации приложений в Google Play, составленный отделом менеджеров при активном участии тимлида отдела Android-разработки Александра Мирко. Вне зависимости от того, насколько ты крутой и опытный проджект-менеджер, всегда есть шанс забыть что-нибудь. Эта инструкция призвана облегчить вам жизнь.

Итак, что нужно сделать PM`y в ходе публикации:

1. Создать аккаунт в Google Play Developer Console для заказчика, если у заказчика такового нет, или предложить произвести публикацию с нашего аккаунта.
2. Оформить privacy policy.
3. Подготовить маркетинговые материалы (иконка, скриншоты, APK, баннер, текст, проморолик).
4. Обеспечить сборку наличием сертификата цифровой подписи.
5. Настроить оплату за пользование приложения.
6. Отправить сборку в Google Play.

Все подробности — под катом.

UPD от 25.04.2017: добавлены разделы про альфа- и бета-тестирование и поэтапное внедрение, дополнены разделы «Обеспечение сборки наличием цифровой подписи» и «Технические требования к apk-файлу», сделано замечание про ASO и внесены косметические правки.

1. Чтобы быстро скопировать/переименовать файл с длинным именем, можно набрать:

cp /home/user1/myfile123456789.txt{,-new}

и обратно:

cp /home/user1/myfile123456789.txt{-new,}

2. Бесполезная, но прикольная форк-бомба (правда, не сработает, если у Вас задан ulimit для количества процессов):

:(){ :|:& };:

3. Эмулятор сетевого принтера на локальном компьютере:

nc -l -p 9100 > job.prn

4. Простейшее нагрузочное тестирование веб-сайта:

for i in {1..1000}; do echo ya.ru; done | xargs -P 20 wget &>/dev/null

5. Удобочитаемый вывод команды mount:

mount | column -t

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.