The dream

UICollectionView — класс UIKit, появившийся в iOS 6. Строго говоря, это класс, позволяющий показывать на экране коллекцию айтемов. Структура коллекции — абсолютно произвольная, но обычно UICollectionView используется для всяких сетко-подобных контролов с ячейками, хедерами и футерами. Понимая, насколько абстрактен данный класс, разработчики Apple создали мощный механизм для создания любых лейаутов. По большому счету, даже UITableView это конкретная реализация UICollectionView. Возможности данного класса, в каком-то смысле, фантастические. Но в данной статье речь пойдет не об этом.

Ахиллесова пята разработчиков Apple — постоянное стремление делать СДК, которое будет работать «автомагически». Просто сделайте то-то и то-то, и класс «will do the right thing». К сожалению это работает далеко не всегда. И UICollectionView — яркий пример. Начиная с релиза в iOS 6 и по сегодняшний день (iOS 7.0.4) класс содержит довольно большое количество багов, с которыми очень трудно и неприятно иметь дело. Приходится угадывать, что же происходит «под капотом», и методом тыка заставлять UICollectionView работать как надо. Количество приобретенных костылей уже достигло таких размеров, что я решил поделиться известными багами и найденными решениями.

Кому интересно — милости просим под кат.

Наш чат устарел: за несколько лет эволюции он превратился в громоздкий View Controller со странными исправлениями, в которых никто не мог разобраться. Стало трудно добавлять новые типы сообщений, зато с легкостью появлялись новые баги. Поэтому мы решили переписать чат на Swift с чистого листа и выложить его в open source.
Мы начали работу над проектом, поставив перед собой две цели:

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

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

​

Думаю, все знают, как бывает непросто поддерживать соблюдение code style и соглашений в iOS-проекте. Сегодня поговорим о том, как автоматизировать этот процесс с помощью утилиты SwiftLint.

Привет, Хабр! Меня зовут Алексей Рыбак, я – глава разработки в Badoo. В феврале в нашем московском офисе Badoo проходил Techleads-митап, где я рассказывал про наш процесс Performance Review. Эта статья написана по мотивам моего выступления.

Мы продолжаем выкладывать видео выступлений с нашей первой конференции мобильных разработчиков #MBLTDev. Следующий доклад — от iOS-разработчика компании «Одноклассники» Юрия Буянова «Опыт использования MVVM в реальных проектах».


Презентация.

Доклад был посвящён практическим аспектам разработки iOS-приложений с использованием архитектуры MVVM. В частности рассматривались способы осуществления навигации и реализации списков в рамках такой архитектуры. Для слушателей, незнакомых c предметом, в начале доклада было сделано небольшое введение в MVVM и ReactiveCocoa. Также были показаны слайды с белочкой, совушкой и единорогом.

Предисловие

Существует большое количество статей, посвященных статическим анализаторам для С/С++/С#, Java и т.д. Что касается исследований применения различных статических анализаторов для нативной разработки под MacOS/iOS, то им уделено гораздо меньше внимания.

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

Каждому iOS разработчику нужен свой уголок с печеньками, плюшевой уточкой и шайтан-машиной на OSX.

В свете перехода на Swift, мощность железа стала особенно востребована. Чтобы комфортно разрабатывать под айфоны, нужен как минимум процессор с частотой 3+ ghz, SSD на 120-250Gb и оперативы гигов 16. Все это как раз для того, чтобы не было желания посмотреть футбол, пока запускается проект или открывается interface builder.

А знаете, что еще было всегда актуально? Сумасшедшие цены на яблочные устройства:

PC с таким же, плюс-минус, железом можно запросто собрать всего за 30.000 рублей! (инфа на ноябрь 2016). Многие, конечно, думают, что раз компания покупает железо, то значит финансы бесконечные, можно не стесняться в средствах. Если вы работаете в Google, то вам повезло и жизнь хороша. Но в остальных случаях это не так.

Что же делать? Не разрабатывать же под Android в конце концов?

Под катом мы узнаем о современном Hackintosh, его роли в разработке, способам безболезненной установки и настройки, услышим мнение людей, работающих на нем не первый год, и проведем тест на iOS инструментах.

Заинтересовавшись темой функционального программирования я встал на распутье, — какой фреймворк выбрать для ознакомления. ReactiveCocoa — ветеран в iOS кругах, по нему вдоволь информации. Но он вырос с Objective-C, и хотя это не является проблемой, но все же в данный момент я в основном пишу именно на Swift, — хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка. RxSwift же порт Reactive Extensions, имеющего долгую историю, но сам порт свежий и написанный именно под Swift. На нем я и решил остановиться.
Но специфика документации по RxSwift в том, что описание всех команд ведет на reactivex.io, а там в основном дается общая информация, руки у разработчиков не дошли еще сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, есть те, о которых в общей документации нет ничего кроме упоминания.
Прочитав все главы вики с RxSwift гитхаба, я сразу решил поразбираться с официальными примерами, тут то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, потом те, что вроде понятны, но задав себе вопросы по ним я понял, что лишь догадываюсь на то как верно ответить, но не уверен.
В общем ничтоже сумняшеся я решил проработать все операторы RxSwift. Лучший способ что то понять в программировании — запустить код и посмотреть как он отработает. Затем учитывая специфику реактивного программирования — очень полезны схемы, ну и краткое описание на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.
Много картинок и текста под катом, очень много!

В прошлой статье я рассказал о том, как создать простое реактивное приложение для iOS с помощью фреймворка RxSwift. В одном из комментариев прозвучала просьба рассказать про написание unit-тестов для реактивного кода. Я обещал написать об этом после пары других статей про RxSwift. Но меня опередили — то, о чём я собирался писать, прекрасно раскрыто в этой и этой статьях. Я лично хочу его поблагодарить автора за его титанический труд — эти две статьи прочно обосновались в моём избранном и помогают мне в работе.

Ну а мы приступим к написанию тестов!

Моя первая статья по RxSwift покрывала практически все базовые операторы, без знаний которых соваться в разработку не имело особого смысла. Но это всего лишь алфавит функционального программирования. Для того чтобы писать полноценные программы необходимо понять основные принципы при работе с GUI.

В основном для проработки материала используются стандартные примеры из RxExample, но для прояснения отдельных моментов была создана песочница UIExplanation и дополнительный пример в RxExample
Весь код можно найти здесь github.com/sparklone/RxSwift

При работе с UI элементами в Rx есть основные потребности:
1) понять какие подводные камни нас ожидают в принципе и зачем нужен Driver
2) научиться делать привязку UI к Observable, чтобы элементы Observable меняли состояние свойства/свойств UI элемента. Это решается с помощью UIBindingObserver
3) научиться переводить паттерн target-action на рельсы Rx. Это делается с помощью ControlEvent
4) сделать двустороннюю привязку к свойствам UI элемента. Это делается с помощью ControlProperty
5) т.к. зачастую у UI элементов delegate/dataSource предполагаются в единственном числе, — ввели класс DelegateProxy, который позволяет одновременно использовать как обычный делегат, так и Rx последовательности.

Рассмотрим каждую потребность отдельно

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

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

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

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

Существует бесчисленное множество статей относительно шаблона MVVM в iOS, но немного о RxSwift, и мало кто акцентирует внимание на том, как выглядит паттерн MVVM на практике и как его реализовать.



ReactiveX — библиотека для создания асинхронных и основанных на событии программ при помощи наблюдаемой последовательности.  — reactivex.io

RxSwift — относительно молодой фреймворк, который позволяет "реактивно программировать". Если Вы ничего о нем не знаете, тогда наведите справки, потому что функциональное реактивное программирование (FRP) набирает обороты, и не собирается останавливаться.

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

Именно с этой проблемой мы столкнулись во время разработки iOS приложений. Чтобы упростить задачу, мы разработали графическую библиотеку Macaw, которая позволяет описывать сложные интерфейсы в виде понятных объектов сцены и даже напрямую отображать SVG графику с поддержкой событий и анимации.

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

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

Вопрос: Почему поиск в python dict на больших объемах данных быстрее чем итерация по индексированному массиву?

Ответ: В dict хранятся хэши от ключей. Каждый раз, когда мы ищем в dict значение по ключу, мы сначала вычисляем его хэш, а потом (внезапно), выполняем бинарный поиск. Таким образом, сложность составляет O(lg(N))!

На самом деле никакого бинарного поиска тут нет. И сложность алгоритма не O(lg(N)), а Amort. O(1) — так как в основе dict питона лежит структура под названием Hash Table.

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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

Часть 1: универсальные сервисы

Провайдеры, предоставляющие информацию в реальном времени, помечены (*).

AnyPresence MBaaS (Mobile backend as a service). Упрощает процесс создания мобильных приложений предприятия, работающих на разных устройствах, не ущемляя гибкость средств, доступных разработчику. Легок в использовании даже для неопытных пользователей. Опытные разработчики получают доступ к исходникам всех компонентов.

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

Appcelerator Arrow (*) Состоит из двух основных компонентов, Builder и Cloud. Arrow Builder позволяет быстро создавать API, модели данных и соединители данных как через мастер настройки, так и через написание кода. Arrow Cloud – это эластичный облачный сервис, где выполняются API и происходит анализ их использования, плюс обеспечивается работа двух десятков смежных сервисов (гео, хранение фотографий и т.п.) с использованием ArrowDB

Appery.io Интегрированные сервисы MBaaS – чтобы разработчики могли сконцентрироваться на приложениях, не отвлекаясь на инфраструктуру.

Перед загрузкой приложения на ревью в Apple App Store нам задают неожиданный вопрос, а не использует ли наше приложение криптографию?



И хотя соблазн ответить «нет» и загрузить наконец-то очень велик, и кто-то тихо шепчет, что ты мог и забыть про https или вообще не знать, как он работает, но совесть советует разобраться и в этом.
У меня много сил ушло, чтобы получить ERN(Encryption Registration approval from BIS), и я решил написать инструкцию.

Вступление

Представьте, что сейчас лето, солнце светит, у вас отпуск, и вы с друзьями — заядлые велосипедисты. Возникает мысль о велосипедном походе куда-нибудь далеко. В этой статье я расскажу о том, как OpenStreetMap-технологии и некоторые другие сервисы упрощают жизнь в такой ситуации, решают проблемы планирования и позволяют быстро и просто поделиться впечатлениями. Упор делается на online, я упоминаю ресурсы:

• OpenStreetMap
• OpenCycleMap
• OpenRouteService
• ShowYourJourney
• Проект Карты России
• MapOSMatic
• Веб интерфейс к GPSBabel
• CourseMapper
• GPS Visualizer

Рубль падает, нефть дешевеет. Стало уже входить в привычку заглядывать и любоваться графиками на Яндексе: RUR/USD и USD/BAR. Естественно, в какой-то момент стало интересно в какой пропорции это происходит — что быстрее дешевеет? Простая операция умножения, и вуаля — стоимость BAR/RUB. В целом, получается, что вроде как баррель в рублях стоит на месте.

И тут мне, конечно, захотелось посмотреть долгосрочную статистику. Яндекс в явном виде по api не предоставляет эти данные, но для своих графиков он отдает нехитрые xml. Поэтому — Sinatra, Bootstrap, Chart.js и Heroku.



Самое показательное — колебания около 3600 рублей за последние безумные 3 месяца. Резкие всплески — отставание курса рубля от изменений стоимости нефти.

С развитием смартфонов в последние годы было разработано много инструментов, чтобы упростить жизнь разработчикам, обеспечив их максимальной производительностью и качеством. Занимать лидирующие позиций в App Store сегодня не простое задание. А научить ваше приложение масштабироваться еще сложнее. Когда приложением пользуются миллионы пользователей, вы должны следить за приложением и при необходимости выполнять все операции моментально. Поэтому одной из проблем, с которой сталкиваются многие разработчики, является Database. Она действительно вызывает сильную головную боль для каждого из нас, и я думаю, что сегодня у вас есть только два варианта: SQLite и Core Data. Я был большим поклонником Core Data и его способностью работать с записями и сохраняющимися данными, но я понял, что впустую трачу много времени, работая с ним при разработке приложений. Недавно, я столкнулся с Realm, новой лучшей заменой SQLite и Core Data.