Интересная статья, не так давно решал с коллегой достаточной редкий кейс разбора json. На входе массив объектов, структуру которых мы заранее не знаем. Но знаем какие поля и каких типов в них могут быть. Таким образом можно декларативно описать платежную форму, а вот статически описать модель данных уже не получится. Мы не нашли в Decodable способа получить условно JsonRecord, по элементам которого можно было бы вручную итерироваться. Может это реализовано в какой-нибудь сторонней библиотеке?
В Android R наконец-то завезли то, о чем я говорил в своем комментарии выше. А именно вменяемую возможность узнать высоту клавиатуры. Клавиатура вмешивается в работу приложения, сдвигает интерфейс. Теперь я с большей силой настаиваю на том, что вариант из статьи (которым я, однако, пользуюсь) является костылем.
Разделяю скептицизм автора по отношению к BottomSheetBehavior, он применим только в простых сценариях. Под капотом он использует простой компонент ViewDragHelper, но во вложенной прокрутке мне не удалось разобраться. BottomSheetBehavior задизайнен таким образом, что перехватывает все жесты внутри корневой вью. Поэтому нельзя ограничить drag-and-drop только TextView, он будет срабатывать на всем списке.
Вы выбрали неудачный пример для демонстрации реактивного программирования. Оно хорошо подходит для асинхронных long-running операций, числа Фибоначчи проще рассчитывать по-требованию. Писать собственный Publisher для вычисления простой последовательности выглядит оверинжинирингом. Для существующих источников (Future, Just, Record) представлено много операторов, с их помощью можно построить самые разные цепочки. Например такую
import Combine
let _ = (0...9)
.publisher
.scan ((1, 0), { source, _ -> (Int, Int) in
let (first, second) = source
return (second, first + second)
})
.sink { (first, _) in
print(first)
}
Что будете делать, когда у разных событий возникнут одинаковые аргументы? Расширять иерархию MyFragmentNavigation абстрактным классом? Кажется тут самое место sealed class. Вы пишите, что получился аналог Rx-BehaviorSubject-a, но RxJava хороша своей расширяемостью. Для ее существует куча операторов, можно и свой какой-нибудь написать. Если речь про взаимодействие Presenter и View не проще использовать Moxy? Там организованы похожие стратегии, которые можно расширять.
Отличная статья, давно хочу подтянуть питон. Жаль, что в статью не включены такие разделы как generic (дженерики) и FP (элементы функционального программирования).
От таких примеров больше вреда, чем пользы. Он не идут дальше наброска приложения из пары кнопок и кучи неучтенных кейсов. Вызывать методы какого-то класса из фреймворка это лишь маленькая часть работы при разработке приложения. Даже для разработки диктофона нужно знать как обрабатывать разрешения. Код из репозитория автора отличается от приведенного в статье, но там этот кейс тоже не учтен. В статье профильного блога на хабре стоит рассматривать более комплексные задачи, а не лажать в очевидных местах.
Вы правы. Я забыл про настройку android.builder.sdkDownload. Главное, что бы скачивание компонент не происходило при каждой сборке. Может образоваться очередь из сборок. Я сторонник разделять зависимости самого приложения (classpath) и sdk. В build.gradle зависимости изменяются чаще, чем версия платформы.
Интересная статья, буду ждать продолжения. Коллега сейчас занимается настройкой CI/CD. Выбрали для себя Circle CI, ресурсы наши ограничены. Если посмотреть на образ, который предлагает Circle, то видны отличия от вашего.
Вы распаковываете sdk, подтверждаете работу с лицензиями. Потом запускаете в контейнере war с дженкинсом. В такой конфигурации нельзя собрать apk. Еще нужно установить tools, platform-tools, саму платформу, опционально ndk. С учетом используемых версии, конечно же. Логично было бы изолировать окружение собственно сборки apk от дженкинса. Но когда я игрался с TeamCity, мне не удалось запустить контейнер в контейнер. С нетерпением жду продолжения.
По итогам статьи не очень понятно, есть ли в алгоритме обфусцирования рандомизация. Иными словами, запустив сборку два раза подряд получу ли я тот же самый результат.
Интересная статья, спасибо. Я правильно понимаю, что вы копирования исходники в другой проект. Как в таком случае обеспечивается синхронизация двух проектов? Не совсем понимаю логику гула, когда для распространения IP пришлось подключить библиотеку play-services-maps. Размер сборки жестко ограничен, остается надеятся что ProGuard/R8 все вырежет. Наверняка есть декларации зависимости от OpenGL без самой библиотеки карт.
Редкий пример на Dribble ограничивается статическим макетом. В придачу идет куча анимаций. Например при смене набор данных, при смене периода просмотра. Ни слова про масштабирование данных. Как быть, когда в наборе присутствие и большие и малые величины.
Подход с тестовым заданием оправдан, если одно и то же задание (а зачастую они похожи) принимают несколько потенциальных работодателей. Домашний проект может стать хорошей отрывной точкой, при необходимости его можно дорабатывать под требования разных команд. История в Git покажет как у разработчика менялись подходы к решению проблем.
Интересная статья, не так давно решал с коллегой достаточной редкий кейс разбора json. На входе массив объектов, структуру которых мы заранее не знаем. Но знаем какие поля и каких типов в них могут быть. Таким образом можно декларативно описать платежную форму, а вот статически описать модель данных уже не получится. Мы не нашли в Decodable способа получить условно JsonRecord, по элементам которого можно было бы вручную итерироваться. Может это реализовано в какой-нибудь сторонней библиотеке?
В Android R наконец-то завезли то, о чем я говорил в своем комментарии выше. А именно вменяемую возможность узнать высоту клавиатуры. Клавиатура вмешивается в работу приложения, сдвигает интерфейс. Теперь я с большей силой настаиваю на том, что вариант из статьи (которым я, однако, пользуюсь) является костылем.
Открыл статью чтобы узнать наконец какая связь между клавиатурой и inset, а увидел только старый костыль с расчетом высоты.
Разделяю скептицизм автора по отношению к BottomSheetBehavior, он применим только в простых сценариях. Под капотом он использует простой компонент ViewDragHelper, но во вложенной прокрутке мне не удалось разобраться. BottomSheetBehavior задизайнен таким образом, что перехватывает все жесты внутри корневой вью. Поэтому нельзя ограничить drag-and-drop только TextView, он будет срабатывать на всем списке.
Вы выбрали неудачный пример для демонстрации реактивного программирования. Оно хорошо подходит для асинхронных long-running операций, числа Фибоначчи проще рассчитывать по-требованию. Писать собственный Publisher для вычисления простой последовательности выглядит оверинжинирингом. Для существующих источников (Future, Just, Record) представлено много операторов, с их помощью можно построить самые разные цепочки. Например такую
Что будете делать, когда у разных событий возникнут одинаковые аргументы? Расширять иерархию
MyFragmentNavigationабстрактным классом? Кажется тут самое место sealed class. Вы пишите, что получился аналог Rx-BehaviorSubject-a, но RxJava хороша своей расширяемостью. Для ее существует куча операторов, можно и свой какой-нибудь написать. Если речь про взаимодействие Presenter и View не проще использовать Moxy? Там организованы похожие стратегии, которые можно расширять.Отличная статья, давно хочу подтянуть питон. Жаль, что в статью не включены такие разделы как generic (дженерики) и FP (элементы функционального программирования).
От таких примеров больше вреда, чем пользы. Он не идут дальше наброска приложения из пары кнопок и кучи неучтенных кейсов. Вызывать методы какого-то класса из фреймворка это лишь маленькая часть работы при разработке приложения. Даже для разработки диктофона нужно знать как обрабатывать разрешения. Код из репозитория автора отличается от приведенного в статье, но там этот кейс тоже не учтен. В статье профильного блога на хабре стоит рассматривать более комплексные задачи, а не лажать в очевидных местах.
Вы правы. Я забыл про настройку
android.builder.sdkDownload. Главное, что бы скачивание компонент не происходило при каждой сборке. Может образоваться очередь из сборок. Я сторонник разделять зависимости самого приложения (classpath) и sdk. Вbuild.gradleзависимости изменяются чаще, чем версия платформы.Интересная статья, буду ждать продолжения. Коллега сейчас занимается настройкой CI/CD. Выбрали для себя Circle CI, ресурсы наши ограничены. Если посмотреть на образ, который предлагает Circle, то видны отличия от вашего.
Вы распаковываете sdk, подтверждаете работу с лицензиями. Потом запускаете в контейнере war с дженкинсом. В такой конфигурации нельзя собрать apk. Еще нужно установить tools, platform-tools, саму платформу, опционально ndk. С учетом используемых версии, конечно же. Логично было бы изолировать окружение собственно сборки apk от дженкинса. Но когда я игрался с TeamCity, мне не удалось запустить контейнер в контейнер. С нетерпением жду продолжения.
По итогам статьи не очень понятно, есть ли в алгоритме обфусцирования рандомизация. Иными словами, запустив сборку два раза подряд получу ли я тот же самый результат.
Интересная статья, спасибо. Я правильно понимаю, что вы копирования исходники в другой проект. Как в таком случае обеспечивается синхронизация двух проектов? Не совсем понимаю логику гула, когда для распространения IP пришлось подключить библиотеку play-services-maps. Размер сборки жестко ограничен, остается надеятся что ProGuard/R8 все вырежет. Наверняка есть декларации зависимости от OpenGL без самой библиотеки карт.
Подскажите что за тип BIT у поля blocked в таблице Client.Я не нашел такого в документации sqlite.
Редкий пример на Dribble ограничивается статическим макетом. В придачу идет куча анимаций. Например при смене набор данных, при смене периода просмотра. Ни слова про масштабирование данных. Как быть, когда в наборе присутствие и большие и малые величины.
Стоило упомянуть, что в Kotlin нет свойств, а только поля. Это имеет прямое отношение к
valиvarпараметрам первичного конструктора.Подход с тестовым заданием оправдан, если одно и то же задание (а зачастую они похожи) принимают несколько потенциальных работодателей. Домашний проект может стать хорошей отрывной точкой, при необходимости его можно дорабатывать под требования разных команд. История в Git покажет как у разработчика менялись подходы к решению проблем.
ООП-подход представлен в статье Writing Better Adapters