Проблема, друзья. Реактивщина везде, её слишком много и уже никому от неё не спрятаться. Мы с вами все умеем написать ASyncTask, Service или ContentProvider (я в это верю!). Все можем повернуть битмапу или сгонять на сервер за данными. Это все довольно очевидно. Но ещё МЫ ДУМАЕМ, что можем готовить реактивищну правильно. Это далеко не всегда так.

Что такое правильное реактивное программирование на Android?



– Добрый день. Расскажи в двух словах о себе. Где работаешь, чем занимаешься, когда начал продвигать реактивный подход?

— Привет. Меня зовут Матвей Мальков (на хабре lNevermore ). Я Android-разработчик уже, наверное, лет 5-6. Конкретно сейчас я занимаюсь Scala-разработкой в одном стартапе. Стартап находится в Москве и о нём я говорить особо много не могу. Но суть в том, что это будет такая комьюнити-платформа, наподобие Телеграма. И её я, собственно, пишу под Android на Scala.

Первый проект, который я полностью перевел на RxJava, у меня был в компании 2GIS. Архитектура, база, работа с сетью — всё. После этого начал активно продвигать фреймворк RxJava и реактивный подход в целом на конференциях. Сейчас пишу на Scala, где использую вовсю функциональный подход, а в свободное время интересуюсь новостями реактивного мира.

– Пользователи Хабрахабра наверняка в курсе концепции реактивного программирования. Расскажи про особенности этой парадигмы на Android и про реактивные потоки данных.

– В программировании под Андроид довольно много особенностей, связанных с реактивным программированием. Я как раз хотел бы сказать о том, что не все принципы реактивного программирования, о которых мы попозже подискутируем, хорошо ложатся на Андроид. Чтобы не быть голословным: есть такое понятие как масштабируемость, под которой обычно понимается масштабируемость на большое количество нод, то есть это какая-то серверная масштабируемость. В Андроиде же это всего лишь масштабируемость на треды, что не есть «настоящая маштабируемость». И она не даёт такого большого мощного импакта на систему в целом. Хотя, конечно, всё равно даёт, но по-другому.

Ещё одна особенность заключается в том, что очень много в Андроиде завязано на императивщину. То есть на мутабельность, на изменяемость данных, и конкретно из-за неё очень сложно всё это завернуть в реактивные потоки. Это приводит к тому, что приходится делать много хаков, что всё очень усложняет. Императивность Android заставляет большое количество разработчиков использовать такие вещи, как сабжекты, которые вообще-то были задуманы и сделаны для того, чтобы сращивать мир реактивный и мир императивный. Но по факту, на самом деле, все пользуются им для того, чтобы что-то легко завернуть в Observable, Это обычно происходит в ущерб архитектуре, особенно на длинной дистанции, на больших проектах. Получается мешанина из императивщины и абы как сделанной на ней реактивщины. А всё потому, что многим людям просто лень сделать правильно или они не знают, как именно правильно.

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

В этой статье мы рассмотрим как рендерить капли на OpenGL и расчитывать на лету нормаль для отражения и прозрачности. А так же, что такое Metaballs, баги графических чипсетов и какие трюки оптимизации можно применить для 60 FPS на мобильных девайсах.

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

Мы продолжаем публикацию материалов, от разработчиков библиотеки MSLibrary for iOS. Тема этой статьи не случайна, проблема выбора нескольких условий из заданного множества, не редко встречается в нашей работе. Простейший пример — выбор партнера для игры (свидания, путешествия и тд). Выбор надо осуществлять из нескольких групп, сформированных по уровню подготовленности (здесь могут быть и возрастные группы и все что угодно). Условие — дать пользователю возможность выбрать партнера из одной или нескольких групп одновременно. Другим примером могут служить константы NSRegularExpressionOptions проверки типа данных для класса NSRegularExpression. При подстановке этих констант в методы класса, мы можем записать:

	NSRegularExpressionCaseInsensitive | NSRegularExpressionDotMatchesLineSeparators 

Объединив константы знаком логического «ИЛИ» мы будем уверены, что проверим анализируемую строку на соответствие обоим из заданных условий.

Один из способов реализации подобной задачи — использование списка констант в виде перечисления enum, в котором элементы перечисления представляют собой двоичные числа с одним установленным битом. Сделать это не очень сложно, но сначала немного теории. Вспомним такие битовые операции, как «СДВИГ», «И», «ИЛИ».

Наше путешествие от стандартных Activity и AsyncTask'ов к современной MVP архитектуре с применением RxJava.

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

Экосистема средств разработки под Android развивается очень быстро. Каждую неделю кто-то создаёт новые инструменты, обновляет существующие библиотеки, пишет новые статьи, или выступает с докладами. Если вы уедете в отпуск на месяц, то к моменту вашего возвращения уже будет опубликована свежая версия Support Library и/или Google Play Services.

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

С незапамятных времен Split View Controller и Popover в iOS были доступны только на iPad.
Начиная с iOS 8, они теперь работают и на iPad, и на iPhone, благодаря концепции Size Classes и их адаптивному поведению. Однако автоматическая адаптация, предложенная Apple «из коробки», чаще всего нас не устраивает и приходится писать небольшой дополнительный код, используя методы делегатов UISplitViewControllerDelegate и UIPopoverPresentationControllerDelegate. В данной статье мы будем исследовать адаптивные способности Split View Controller и Popover на примере очень простых практических приложений, работающих с сервером Flickr.com, представляющим собой облачный сервис для хранения фотографий. Сама по себе эта задача имеет большой практический смысл, так как является часто встречающимся случаем, когда данные считываются с некоторого сервера и представляются затем ввиде связанных таблиц и изображений. Попутно мы будем демонстрировать “вживую” такие синтаксические конструкции Swift, как вычисляемые свойства c {get} и {set}, наблюдатели свойств didSet{}, функции высшего порядка map, flatMap, filter, вывод типа из контекста и перегрузку (overload) функций, совместное использование Swift и Objective-C кода, работу со структурами struct, использование хранилища NSUserDefaults и т.д. Но все же в этой статье акцент делается на более сложных конфигурациях адаптивных Split View Controller и Popover.
Впоследствие все приведенные в этой статье приложения вы сможете использовать в качестве шаблонов для разработки ваших приложений с похожими задачами.

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

В своём развитии мне пришлось пробежаться по нескольким этапам в нескольких направлениях: Java → Objective C → Swift, Web → Enterprise → Mobile, XML → JSON. Этим путём я шёл на протяжении более 15 лет, подолгу и внимательно задерживаясь на каждом этапе. Нужно идти дальше. За мобильными приложениями можно придумать что-то (наверное, пока не хочется), языков вообще пруд-пруди, ничего интереснее JSON'а не придумали. А зачем его менять?

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

Сразу должен отметить, что не рассматриваю KTV, как замену JSON. И ни в коем случае не рассматриваю его для использования в JavaScript'е. Это будет неудобно и неправильно. С другой стороны, ситуация, когда система описания объектов JavaScript'а используется в других языках для работы с типизированными данными — тоже странная, и её хочется поправить.

Если вам интересно, что послужило изначальной причиной создания такого формата — можно почитать про S2 и про причины создания формата KTV

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

В своем докладе, Филлип Коннатон, разработчик из Runkeeper (один из самых популярных GPS трекеров), расскажет о том, как наиболее эффективно использовать геолокацию внутри приложения и как менялись способы работы с ней в мобильной экосистеме Apple, начиная с самых ранних устройств на iOS и заканчивая watchOS 2. А в качестве бонуса вы узнаете, какими качествами нужно обладать QA специалисту для работы в Runkeeper и чьим голосом говорит приложение.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

К концу 2015 года в распоряжении JavaScript разработчиков образовалось огромное количество инструментов. В этой экосистеме легко потеряться, поэтому успешные команды следуют выработанным правилам, которые позволяют не терять время и сохранять здоровье проектов. Под катом перевод статьи 2016 года от команды Heroku, в которой они рассказывают о десяти привычках веб разработчиков, у которых все работает и ничего не болит. Скорее всего 80% написанного вы уже знаете – тем интереснее вам будет прочитать об оставшихся двух приемах!

Здравствуйте, меня зовут Дмитрий Карловский, и я… архитектор множества широко известных в узких кругах фреймворков. Меня никогда не устраивала необходимость из раза в раз решать одни и те же проблемы, поэтому я всегда стараюсь решать их в корне. Но прежде, чем их решить, нужно их обнаружить и осознать, что довольно сложно находясь в плену привычек, паттернов, стереотипов и "готовых" решений. Каждый раз сталкиваясь с проблемами в реализации задачи, я задумываюсь "что, блин, не так с этим инструментом?" и, конечно же, иду пилить свой инструмент: функцию, модуль, библиотеку, фреймворк, язык программирования, архитектуру ЭВМ… стоп, до последнего я ещё не докатился.

Речь сегодня пойдёт о JS-фреймворках. Нет, я не буду рассказывать про очередное готовое решение, не в том цель поста. Я лишь хочу посеять в ваших головах несколько простых идей, которые вы не встретите в документации ни к одному популярному фреймворку. А в конце мы постараемся сформировать видение идеальной архитектуры построения пользовательского интерфейса.

Сегодня мы решили взглянуть на ситуацию с Java- и Python-разработчиком, который задумался о «погружении» в тему DevOps в тот момент, когда он начал все больше отдаляться от привычных инструментов в пользу работы с Oracle Weblogic и shell-скриптами. Он решил совместить свой опыт в области разработки с новым опытом в работе с процессами.

Мы посмотрели на основные советы экспертов в области DevOps на Quora и дополнили рассказ примерами из опыта команды 1cloud.

Если верить последним тенденциям, то FRP набирает обороты и не собирается останавливаться. Не так давно я столкнулся с проектом, посвященным FRP — ReactiveX, и его реализацией для Swift — RxSwift. На Хабре уже была небольшая статья, которая будет полезна для начального понимания RxSwift. Я хотел бы развить эту тему, поэтому заинтересовавшимся — добро пожаловать под кат!

Лиха беда начало

И это действительно так. Самое сложное, с чем мне пришлось столкнуться — совершенно другое построение программного кода. С моим опытом императивного программирования было тяжело перестраиваться на новый лад. Но чутьё подсказывало мне, что в этом стоит разобраться; у меня ушло 2 недели паники на то, чтобы вникнуть в суть ReactiveX и я не жалею о потраченном времени. Поэтому сразу хотел бы предупредить — статья требует понимания терминов ReactiveX, таких как Observable, Subscriber и т.д.

Итак, начнем.

Android-проекты бывают большими. Иногда действительно большими. Один из наших проектов — новостное приложение, которое разрабатывается одновременно под две альтернативные платформы: Android и FireOS, что от Amazon. Это позволяет расширить круг читателей новостей, ведь пользователи читалок Kindle Fire любят почитать:). Однако, это же накладывает обязательство считаться с особенностями каждой из платформ. Например, если в Android вы используете GCM для push-сообщений, то в FireOS вы должны использовать для этого Amazon AWS. Аналогично и для систем покупок внутри приложения: Google in-app billing vs. In-App Purchasing. Но большой размер проекта != большой размер приложения!

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

Что готовим?

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

Что должен знать objc разработчик на уровень middle/senior?
К сожалению, четкой черты на вертикальное развитие нет. Парадокс, но чтобы знать что изучить, нужно знать что ты не знаешь.
Я постарался вспомнить самые интересные вопросы, которые мне задавали самому на различных собеседованиях, а так же расширил их множеством вопросов(тем же уровнем) от себя.
Здесь нет общих вопросов вроде: IoC, design patterns, S.O.L.I.D. и т.п.

ВНИМАНИЕ!!!
Помимо вертикального развития немаловажно и горизонтальное

ВНИМАНИЕ!!! (2)
Не пишите в комментарии ответы на вопросы, это дает возможность людям самостоятельно разобраться.
Однако, если у вас имеются интересные вопросы по теме, я с радостью добавлю их в список.

Конечно, это не заменит живого общения, однако позволит неплохо подготовиться к собеседованиям.

Начинаем

Interface Builder в Xcode с некоторого времени экономит мне много времени в работе по стандартному лайауту элементов интерфейса и иногда помогает в задаче прототипирования. С версии 6 в Xcode добавили возможность рендера кастомных вьюшек, помеченных атрибутом IBDesignable, а также отображение в билдере полей класса, помеченных атрибутом IBInspectable.

С версии Xcode 7 этой фичей стало более-менее возможно пользоваться, поэтому мне захотелось проверить её возможности.

Почитать про IBDesignable/IBInspectable можно тут и тут.

Когда собаке программисту нечего делать, он начинает все автоматизировать. Мне по роду своей деятельности приходится писать много кода и, конечно, хочется какие-то повторяющие вещи обобщить в виде библиотек, скриптов или шаблонов для Android Studio. О них и поговорим.

Это вторая часть моей статьи с левел-дизайнерскими Tips and Tricks, которые разработчик может использовать, чтобы повысить общее качество своей игры. Это ни в коем случае не пошаговое руководство, а только сборник идей и полезных советов, основанных на моём личном опыте. Первая часть статьи была больше ориентирована на визуальную составляющую дизайна уровней, в этот же раз мы поговорим о ещё более фундаментальных вещах, начиная с прототипирования и заканчивая плэйтестингом с аналитикой.