Kotlin *

На улице я часто слушаю аудиокниги и подкасты со смартфона. Когда прихожу домой, мне хочется продолжить слушать их на Android TV или Google Home. Но далеко не все приложения поддерживают Chromecast. А было бы удобно.

По статистике Google за последние 3 года, количество девайсов на Android TV увеличилось в 4 раза, а число партнеров-производителей уже превысило сотню: «умные» телевизоры, колонки, TV-приставки. Все они поддерживают Chromecast. Но в маркете ещё много приложений, которым явно не хватает интеграции с ним.

В этой статье я хочу поделиться своим опытом интеграции Chromecast в Android-приложение для воспроизведения медиа-контента.

Пора полюбить статические анализаторы! Встречайте Detekt на Kotlin

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

Что-же это такое?

Анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ. Википедия

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

Статические анализаторы облегчают работу ревьюера и в целом экономит время команды на разработку.

Примерно год назад я начал использовать Kotlin в своих Android проектах. Мне хотелось попробовать что-то новое, что было бы интересно изучать. Тогда я и наткнулся на Anko. К тому времени писать UI на xml порядком осточертело. Мне всегда нравилось писать интерфейс руками, не прибегая к WYSIWYG и xml-разметке, используемой в Android Studio. Единственный минус заключается в том, что для проверки любого изменения придется перезапускать приложение. Можно использовать плагин, который показывает как будет выглядеть ui не запуская приложения, но мне он показался довольно странным. Так же у него есть крутая возможность конвертирования xml в Anko Layouts DSL.

Самый большой недостаток библиотеки — практически полное отсутствие документации. Чтобы разобраться, как ее правильно использовать, приходилось часто заглядывать в исходники. В этой статье будет подробно разобрано создание приложения используя Anko Layouts и Anko Coroutines.

Довольно часто необходимо делать повторные запросы в сеть, например, когда у пользователя не было интернета и он захотел получить данные из интернета. Неплохо бы было заново кинуть запрос при его появлении. Хорошая практика — показать пользователю определенный UI, который объяснил бы ему что произошло и позволил бы заново кинуть запрос. Добавление такой логики может быть довольно болезненной, особенно, когда у нас огромное множество ViewModel классов. Конечно, можно реализовать логику резапросов в каждом ViewModel классе, но это не удобно и возникает огромная вероятность появления ошибок.

Начиная новый проект я решила попробовать полностью отказаться от XML-файлов, на основе которых формируются layouts, а экраны создавать с помощью библиотеки Anko. Имея небольшой опыт разработки под Android (порядка 2-х лет) и еще меньший опыт написания кода на Kotlin (чуть больше полугода) я сразу столкнулась с проблемой включения в приложение Navigation Architecture Component, а вернее отрисовкой Bottom Navigation Bar, создаваемом BottomNavigationView.

Первым делом я обратилась к просторам Инета, чтобы найти возможное решение. Но все статьи найденные мной с той или иной степенью доходчивости рассказывали о том как работать с компонентами навигации и никто (из тех чьи статьи я проштудировала) не делал это на Anko. Решив поставленную задачу, я предлагаю сообществу свой вариант создания Bottom Navigation Bar.

Полностью весь код можно посмотреть здесь
Я пропускаю этап создания нового проекта в Android Studio, отмечу только что для работы с Anko и Navigation Architecture Component в build.gradle на уровне модуля необходимо добавить следующие зависимости:

implementation "org.jetbrains.anko:anko:$anko_version"
implementation "org.jetbrains.anko:anko-constraint-layout:$anko_version"
implementation "com.android.support.constraint:constraint-layout:2.0.0-alpha3"

implementation 'android.arch.navigation:navigation-fragment:1.0.0-beta02'
implementation 'android.arch.navigation:navigation-fragment-ktx:1.0.0-beta02'
implementation 'android.arch.navigation:navigation-ui-ktx:1.0.0-beta02'

implementation 'com.google.android.material:material:1.0.0'

Можете предсказать, как поведёт себя такой Kotlin-код? Скомпилируется ли он, что выведет и почему?

Как бы хорош ни был язык программирования, он может подкинуть такое, что останется только в затылке чесать. Kotlin не исключение — в нём тоже встречаются «паззлеры», когда даже у совсем короткого фрагмента кода оказывается неожиданное поведение.

Ещё в 2017-м мы публиковали на Хабре подборку таких паззлеров от Антона Кекса antonkeks. А позже он выступил у нас на Mobius со второй подборкой, и её мы теперь тоже перевели для Хабра в текстовый вид, спрятав правильные ответы под спойлеры.

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

Раньше было Future, а теперь — Mobile. Тут всё более или менее традиционно: есть iOS, есть Android, и есть у них что-то общее. Обсудим тёмную тему, нюансы разработки под CarPlay, ARCore и Instant Apps и #КонечноЖеKotlin.

Привет, Хабр!

Мы приглашаем всех на JetBrains Night — большую встречу с друзьями, которая пройдет 13 апреля в Москве. Приходите узнать, что интересного происходит в мире Java, Kotlin и веб-технологий. Разработчики JetBrains расскажут, чем мы занимаемся и что нового сделали за последнее время, а самое главное — как все это правильно использовать.

После технических докладов мы проведем открытую дискуссию со спикерами и другими сотрудниками компании — ответим на вопросы о наших продуктах и работе в JetBrains.

Как оптимизировать обработку изображений в рантайме, когда необходимо создать 6 изображений, каждое из которых состоит из последовательно наложенных 15-16 PNG, не получив OutOfMemoryException по дороге?

Привет, любители Habr! По счастливой случайности в августе 2018 года мне посчастливилось вместе с моим товарищем(kirillskiy) начать работать над потрясающим по своей интересности проектом. И вот, днем мы были обычными программистами, а ночью с̶у̶п̶е̶р̶г̶е̶р̶о̶я̶м̶и̶ снова программистами, которые бьются над вопросами распознавания движений для людей имеющих ограничения функциональности своих конечностей, естественно этим могли бы пользоваться и здоровые люди, используя подобную технологию самыми разными способами.

После работы над мультиплатформенной библиотекой, которая собирала .framework и .aar артефакты, я пришел к выводу, что есть большое количество полезных вещей, уже есть в Kotlin, но многие из нас никогда о них не знали.

Вступление

Всем привет. Какое-то время назад, я решил делать свой проект для Android и iOS одновременно. Естественно, встал вопрос о выборе технологий. Пару недель присматривался к популярным стекам и выбрал Kotlin/Native. Поскольку я являюсь Android-разработчиком, то с Kotlin знаком давно, а со Swift особого опыта не было и хотелось получить большую часть кода общего для обеих платформ. Следовательно, сразу встал вопрос, а как писать UI для iOS. Быстрый взгляд на рынок подсказал, что есть Flutter, который позволяет писать UI для двух платформ одновременно. Собственно, так и началась эта история.

В статье описан опыт сборки Flutter в качестве UI и Kotlin для основной логики. Важно: под катом много картинок и инструкция, как собрать проект

Думаю, ни для кого не секрет, что "Дурак" (далее это слово будет написано с маленькой буквы и без кавычек) — это самая популярная карточная игра в России и странах бывшего СССР (хотя и почти неизвестная за его пределами). Несмотря на свое название и довольно несложные правила, выигрыш в ней все-таки зависит больше от мастерства игрока, чем от случайного расклада карт (в английской терминологии игры того и другого типов называются соответственно game of skill и game of chance. Так вот — дурак в большей степени game of skill).

Целью статьи является написание простого ИИ для игры. Под словом "простого" подразумевается следующее:

• интуитивно понятный алгоритм принятия решений (то есть, как следствие, никакого машинного обучения, в котором этот алгоритм скрыт глубоко "под капотом");
• отсутствие состояния (то есть, алгоритм руководствуется только данными на текущий момент времени, проще говоря, ничего не запоминает (например, не "считает" вышедшие из игры карты).

Аспе́ктно-ориенти́рованное программи́рование (AOP) довольно популярная парадигма программирования. В статье на Wikipedia хорошо объяснена мотивация этого подхода.

Введение

При Андроид разработке мы используем разные архитектурные решения(паттерны). Например Mvp, Mvvm, Mvi и т.д… Каждый из этих паттернов решает несколько важных задач и поскольку они не идеальны они нам оставляют кое-какие нерешенные задачи. К примеру этих задач относятся навигация внутри приложения(routing), передача информации с экрана на экран(говоря экран я имею ввиду Activity, Fragment или View), Сохранение состояний приложения при смене конфигурации(configuration change).

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

Существует множество способов обработки сообщений из Pub-Sub систем: использование отдельного сервиса, выделение изолированного процесса, оркестрация пулом процессов/потоков, сложные IPC, Poll-over-Http и многие другие. Сегодня я хочу рассказать о том, как использовать Pub-Sub по HTTP и про свой сервис, написанный специально для этого.

Использование готового HTTP -бэкенда сервисов в некоторых случаях является идеальным решением для обработки очереди сообщений:

1. Балансировка из коробки. Обычно, бэкенд и так стоит за балансировщиком и имеет готовую к нагрузкам инфраструктуру, что сильно упрощает работу с сообщениями.
2. Использование обычного REST-контроллера (любой HTTP-ресурс). Потребление сообщений по HTTP сводит к минимуму затраты на реализацию консюмеров под разные языки, если бэкенд разношерстный.
3. Упрощение использования Веб-хуков других сервисов. Сейчас почти каждый сервис (Jira, Gitlab, Mattermost, Slack…) так или иначе поддерживает Веб-хуки для взаимодействия с внешним миром. Можно облегчить жизнь, если научить очередь выполнять функции HTTP-диспатчера.

Этот подход имеет и минусы:

1. Можно забыть о легковесности решения. HTTP тяжёлый протокол, а использование фреймворков на стороне консюмера мгновенно приведёт к увеличению задержки (latency) и нагрузки.
2. Лишаемся сильных сторон Poll-подхода, получая слабые стороны Push.
3. Обработка сообщений теми же инстансами сервиса, которые обрабатывают клиентов, может сказаться на отзывчивости. Это несущественно, так как лечится балансировкой и изоляцией.

Я реализовал идею в виде сервиса Queue-Over-Http, о котором и пойдёт речь далее. Проект написан на Kotlin с использованием Spring Boot 2.1. В качестве брокера сейчас доступна только Apache Kafka.

Привет, Хабр!

Все любят runtime exceptions. Нет лучшего способа узнать о том, что что-то не было учтено при написании кода. Особенно — если исключения обваливают приложение у миллионов пользователей, и эта новость приходит паническим email'ом с портала аналитики. В субботу утром. Когда ты в загородной поездке.

После подобного всерьез задумываешься о обработке ошибок — и какие же возможности предоставляет нам Kotlin?

Первым на ум приходит try-catch. По мне — отличный вариант, но у него есть две проблемы:

1. Это как-никак лишний код (вынужденная обертка вокруг кода, не лучшим образом сказывается на читаемости).
2. Не всегда (особенно при использовании сторонних библиотек) из блока catch возможно получить информативное сообщение о том, что конкретно вызвало ошибку.

Давайте посмотрим во что try-catch превращает код при попытке решения вышеозвученных проблем.

Когда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python. Так же хотелось бы на выходе иметь один бинарный файл, который будет легко запустить. И не возиться слишком много с memory management'ом.

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

У Go относительно простой синтаксис, неплохая стандартная библиотека, есть garbage collection, и на выходе мы получаем один бинарник. Казалось бы, что еще нужно?

Не так давно Kotlin так же стал пробовать себя на схожем поприще в форме Kotlin Native. Предложение звучало многообещающе — GC, единый бинарник, знакомый и удобный синтаксис. Но все ли так хорошо, как хотелось бы?

В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.

Сообщество «Google Developers Group» в Петербурге основано в 2006 году. Однако подвести итоги года мы решили впервые. GDG проводит IT конференции и митапы для разработчиков Android, Kotlin, Scala, Firebase, Dart и Assistant. В 2018 году мы провели 17 конференций и митапов. Под катом вы найдете итоги и отзывы о мероприятиях, а ещё все материалы и записи классных докладов!