Завершающая статья на тему протокольно ориентированного программирования.

В этой части мы рассмотрим как переменные обобщенного типа хранятся и копируются и как с ними работает метод dispatch.

Давайте подробнее изучим тему протокольно ориентированного программирования. Для удобства разделили материал на три части.

Данный материал является комментированным переводом презентации WWDC 2016. Вопреки частому мнению о том, что вещи "под капотом" должны там и оставаться, иногда крайне полезно разобраться, что же там происходит. Это поможет использовать предмет правильно и по назначению.

В продолжение темы разберемся в протокольных типах и обобщенном (generic) коде.

По ходу будут рассмотрены следующие вопросы:

• реализация полиморфизма без наследования и ссылочных типов
• как объекты протокольных типов хранятся и используются
• как с ними работает отправка метода

Мы в hh постоянно находимся в активном поиске истинных талантов и проводим массу собеседований. Как правило, они состоят из двух этапов — технического и продуктового. На каждом из них у кандидатов возникает множество вопросов, и чтобы облегчить всем жизнь, мы отобрали самые популярные и отвечаем на них в этой статье.

Данная статья поможет начинающим iOS разработчикам разобраться в производительности алгоритмов в Swift.

Обозначение Big O нотация (или просто Big O) — это способ оценки относительной производительности структуры данных или алгоритма, обычно по двум осям: времени и пространству.

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

Мы в Surf постоянно сталкиваемся с необходимостью решать эти проблемы при разработке мобильных приложений, в том числе и на Flutter. Опыт, который мы получили за долгое время, отразился на наших подходах и лёг в основу библиотеки Elementary, автором которой я являюсь.

В статье расскажу, как устроен Elementary, какие принципы в нём заложены и чем вообще он может быть полезен.

Думаю, многие разрабочики хотя бы раз в жизни хотели поделиться своими наработками с сообществом. Уж точно все - пользовались тем, чем делятся другие. Мое мнение на этот счет примерно такое - если ты делаешь что-то для себя и можешь это сделать таким, чтобы этим могли пользоваться другие с, относительно, небольшим количеством трудозатрат - то делай это. К тому же, выставляя "напоказ" свои велосипеды - так или иначе, придется их хотя бы покрасить. Смазать цепь. А значит и в твоем проекте данное решение будет уже более качественным. Не буду углубляться в философию опен-сорса (простите меня, нелюбители английских слов, написанных по русски), поэтому перейдем сразу к делу.

Привет! Это вторая статья из цикла о разработке приложения на Flutter. В этом "номере" я опишу создание сетевого слоя, работу с локализацией, удобный способ работы с ассетами, локальный поиск и создание UI для одного из двух экранов приложения. Также я выведу интересные метрики, например - сколько данных сможет распарсить ваше приложение за одну милисекунду и начиная с какого размера JSON’а, прилетевшего с бэка UI начнет тормозить. Как говорится - с места...

Привет! В данном цикле статей я хотел бы показать, как может происходить создание приложений с использованием Flutter. У меня есть несколько Open Source решений, которые будут использованы в данном приложении. Что из этого получится - увидим в скором будущем.

Про нас

Привет! Мы Даниил Левицкий и Дмитрий Дронов, мобильные разработчики компании ATI.SU — крупнейшей в России и СНГ Бирже грузоперевозок. Хотим поделиться с вами своим видением разработки приложений на Flutter.

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

Ссылка на шаблон и детали реализации под катом.

В свободное время (а иногда и в рабочее) я изучаю микроконтроллеры и собираю умный дом у себя в квартире, а так как по профессии я iOS-разработчик, то на умный дом я смотрю через призму iPhone и HomeKit. После сборки более-менее рабочего умного дома и, столкнувшись с кучей проблем, решил рассказать про свой опыт и устройства в цикле из 2 статей. Первая статья будет небольшим ликбезом в теорию микроконтроллеров и протоколов, а во второй уже поделюсь конкретным применением этих протоколов и фреймворков в моем умном доме.

Примечание

Слова layout, autolayout и constraints я перевёл, соответственно, как вёрстка, автовёрстка и ограничения.

Работа с автовёрсткой

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

Interface Builder неплох как визуальный редактор вёрстки. В нём есть индикация некорректных граничных параметров. Однако ваша вёрстка может отличаться от видимой в IB. На экран приложения могут влиять различные параметры — например, ответы на сетевые запросы или локально сохранённые данные. Более того, могут быть экраны, частично или полностью построенные на информации, заданной сервером. От сервера может поступать вообще всё что угодно, в том числе шрифты, цвета и формы.

Кажется, остаётся только вручную разбирать гигантский лог ошибок автовёрстки. Но есть и другие варианты.

­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

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

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

struct OrderButtonExperimentDTO: Decodable {
   let buttonTitle: String
   let estimationMinute: Int
}

Build Flavors — технология, позволяющая собирать несколько вариантов приложения с общей кодовой базой и общими ресурсами.

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