На этой неделе мы изучали, как стабилизировать Android, возможности его новой версии для Интернета вещей, как пробиться в топы App Store, оптимистичный UI и многое другое.

Работая с Android часто можно видеть, как весь функциональный код помещается в методы жизненного цикла activity/fragment. В общем-то такой подход имеет некоторое обоснование — «методы жизненного цикла» всего лишь хэндлеры, обрабатывающие этапы создания компонента системой и специально предназначенные для наполнения их кодом. Добавив сюда то, что каркас UI описывается через xml файлы, мы уже получаем базовое разделение логики и интерфейса. Однако из-за не совсем «изящной» структуры жизненного цикла, его зависимости от множества флагов запуска, и различной (хоть и похожей) структуры для разных компонентов, эффективно воспользоваться подобным разделением не всегда бывает возможно, что в итоге выливается в написании всего кода в onCreate().

Писать программки для смартфонов — мое хобби. Все началось с того, что я купил свой первый смартфон Nokia E51 на Symbian и мне очень нравилось что его функционал можно было расширить через установку дополнительных программ.
Но однажды я не нашел необходимой программы и решил написать ее сам. Так и началось мое увлечение программами для смартфонов.

После того как глава Nokia заявил, что дни Symbian сочтены, я решил изучить платформу Android.

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

Совсем недавно, 26 октября, мы провели открытый митап Rambler.Android #4. Это наш первый Android-митап после долгого перерыва. И мы с уверенностью можем заявить, что возвращение состоялось.

В предыдущей статье я сделал беглый обзор async-await в Android. Теперь пришло время погрузиться немного глубже в грядущий функционал kotlin версии 1.1.

Для чего вообще async-await?

Когда мы сталкиваемся с длительными операциями, такими как сетевые запросы или транзакции в базу данных, то надо быть уверенным, что запуск происходит в фоновом потоке. Если же забыть об этом, то можно получить блокировку UI потока еще до того, как задача закончится. А во время блокировки UI пользователь не сможет взаимодействовать с приложением.

На недавнем DroidCon Moscow 2016 был доклад о MVVM c Databinding Library и доклад о библиотеке Moxy, помогающей работать с MVP. Дело в том, что за последние полгода мы успели опробовать оба подхода на живых проектах. И я хочу рассказать о своём пути от освоения Databinding Library и выпуска в продакшн проекта на MVVM до осознания, почему я больше не хочу использовать этот паттерн.

Splash Screen (прим.: тут и далее — экран загрузки) просто отнимает ваше время, верно? Как Android разработчик, когда я вижу экран загрузки, я тут же представляю как некоторые плохие разработчики добавляют трехсекундную задержку в коде.

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

Project Tango от Google — проект по созданию мобильных устройств, способных анализировать пространство вокруг себя в трёх измерениях. Благодаря проекту Device Lab мне удалось поиграться одним из таких устройств.


Статья автора Сергея Мелехина, в рамках конкурса «Device Lab от Google».

Привет, Хабр. Хочу вам признаться. Я — Лентяй. Эта тёмная тайна, тщательно скрывается от окружающих. Поэтому, чур никому ни слова.
Чтобы никто из окружающих не догадался про это, приходится постоянно работать. Но частенько во время работы, отвлекаюсь на всякие посторонние вещи. Новости почитать, посмотреть почту, историю сообщений. В результате, отвлекающие занятия, занимают слишком много времени, и страдает имидж. Иногда, я близок к разоблачению.
Но однажды я нашел методику управления своим рабочим временем, под названием «Pomodoro». И написал приложение «Таймер Трудового Человека». Потому, что я — Android-Разработчик!


Итак, ниже под катом я расскажу о творческих метаниях, головоломаниях, и прочих сопуствующих творческому процессу прелестях.

Я опубликовал первую статью «50 советов по работе с Unity» 4 года назад. Несмотря на то, что бóльшая её часть всё ещё актуальна, многое изменилось по следующим причинам:

• Unity стал лучше. Например, теперь я могу доверять счётчику FPS. Возможность использования Property Drawers снизила необходимость написания пользовательских редакторов (Custom Editors). Способ работы с префабами стал меньше требовать заданных встроенных префабов (nested prefabs) и их альтернатив. Скриптуемые объекты стали более дружелюбными.
  
  
• Улучшилась интеграция с Visual Studio, отладка стала намного проще и уменьшилась потребность в «обезьяньем» дебаггинге.
  
  
• Стали лучше сторонние инструменты и библиотеки. В Asset Store появилось очень много ассетов, упрощающих такие аспекты, как визуальная отладка и логирование. Большая часть кода нашего собственного (бесплатного) плагина Extensions описана в моей первой статье (и многое из него описано здесь).
  
  
• Усовершенствован контроль версий. (Но, может быть, я просто научился использовать его более эффективно). Например, теперь не нужно создавать множественные или резервные копии для префабов.
  
  
• Я стал более опытным. За последние 4 года я поработал над многими проектами в Unity, в том числе над кучей прототипов игр, завершёнными играми, такими как Father.IO, и над нашим основным ассетом Unity Grids.

Эта статья является версией первоначальной статьи, переработанной с учётом всего вышеперечисленного.

Всем привет! Мы два новоиспеченных разработчика мобильных игр, бывшие одноклассники, выпускники Казанского федерального университета, Айдар и Эд.

Айдар: «История нашей игры «Syncomania» началась с того, что мне приснился странный сон. Он представлял собой компьютерную игру, где на квадратном поле синхронно передвигались четыре белых шарика. Когда первый из них вырвался за пределы игрового поля, я проснулся. Наутро я позвонил Эду, а уже в обед мы встретились во дворе университета, где я работал».

Эд: «Какой программист не мечтал сделать свою игру? Летом 2014-го у меня было много свободного времени, и я с радостью ухватился за эту идею. Тогда мы и представить себе не могли, с какими трудностями мы столкнемся».

Впрочем, на первом этапе мы были полны энтузиазма, все было легко и интересно. Именно о нем мы и расскажем в первой части статьи.

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

При работе с естественным языком и лингвистическом анализе текстов нам часто приходится оперировать огромным количеством уникальных коротких строк. Счёт идёт на десятки и сотни миллионов — именно столько в языке существует, к примеру, осмысленных сочетаний из двух слов. Основной платформой для нас является Java и мы не понаслышке знаем о её прожорливости при работе с таким большим количеством мелких объектов.

Чтобы оценить масштаб бедствия, мы решили провести простой эксперимент — создать 100 миллионов пустых строк в Яве и посмотреть, сколько придётся заплатить за них оперативной памяти.

Всем привет!

Эта статья про реализацию одного конкретного DSL (domain specific language, предметно-ориентированный язык) для регулярных выражений средствами Kotlin, но при этом она вполне может дать общее представление, о том, как написать свой DSL на Kotlin и что обычно будет делать "под капотом" любой другой DSL, использующий те же возможности языка.

Многие уже используют Kotlin или хотя бы пробовали это делать, да и остальные вполне могли слышать о том, что Kotlin располагает к написанию изящных DSL, чему есть блестящие примеры — Anko и kotlinx.html.

Конечно же, для регулярных выражений подобное уже делали (и ещё: на Java, на Scala, на C# — реализаций много, похоже, это распространённое развлечение). Но если хочется попрактиковаться или попробовать DSL-ориентированные языковые возможности Kotlin, то добро пожаловать под кат.

В этой статье я хочу рассказать о новой возможности перетаскивать данные между различными Activity в режиме совместного отображения, которая появилась с выходом Android 7 Nougat. Ранее перетаскивать данные можно было только в рамках одной Activity.

Этот очень длинный пост посвящён разработке мобильной VR (untethered VR), а также некоторым вопросам дизайна и проблемам, которых нужно опасаться в процессе разработки, а также оптимизации производительности, тестированию и публикации в магазине Oculus. Но прежде чем начать, давайте подумаем, зачем вообще нужна такая разработка.

Дискуссия вокруг Scala не стихает уже много лет, разворачиваясь в основном на поле противостояния с Java. Действительно, несмотря на общую платформу, языки разные.

Аргументы за Scala известны:

1. Scala лаконичная;
2. Scala функциональная;
3. Scala крутая и современная;

В ответ на то, что Scala медленно загибается, Мартин Одерски заявил следующее: «В 2015-м было затишье, но вот в 2016-м развитие Scala должно ускориться».

В этом посте я не буду глубоко погружаться в техническую дискуссию, есть множество специалистов, которые сделают это лучше меня. Сегодня мы поговорим о том, нужна ли Scala разработчику для саморазвития, для этого хочу предложить вам перевод статьи Matthew Casperson.

Ну и в конце дам пару ссылок на популярные статьи по теме за последние несколько лет, если вдруг вы какие-то из них пропустили.

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

Демо приложение доступно на гитхабе по ссылке.

Собственно, под катом можно прочесть пару слов о RecyclerView, CardView и о подключении соответствующих библиотек в Gradle. Также, можно посмотреть коротенькое видео, демонстрирующее стандартную анимацию операций со списком в RecyclerView.

Когда-то, на заре моей карьеры Android-разработчиком, я просматривал примеры уже имеющихся приложений и в прекрасном, словно солнышко весной, U2020 я нашел пример очень удобного адаптера. Имя его BindableAdapter. Долгое время я использовал его как основу своих адаптеров для ListView и GridView, но их эра приходит к своему закату и наступает эра RecyclerView. Этой эре нужен новый удобный адаптер, и я попытался его сделать.

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

Внимание: Данный пост является очень вольным переводом этой статьи. Целью ставилось донести смысл текста, поэтому в некоторых местах текст может не совпадать с оригиналом.

Вчера ночью вышел стабильный релиз Android Studio 2.2. Разработчики говорят о 20+ изменениях: дизайн, разработка, сборка и тестирование. Из значимых изменений: