3 Июня 2014
McLaughlin, Michael P.
Кто-нибудь знает, действительно ли Apple собирается прекратить поддержку С и С++? Fortran уже не поддерживается, хотя осталось еще много кода на Fortran, и сравнительно нового, как в MultiNest.
Пожалуйста, скажите, что это не так. Не все считают, что «опытные пользователи» — это те, кто просто создает полнометражные мультики. Многие из них ученые и инженеры.

Здравствуйте, Michael,
Мы не строили планы на что-либо подобное. Swift — это просто новый вариант разработки под платформу. Мы не собираемся прекращать поддержку ни C, ни C++, ни Objective-C. Если вы разрабатываете на одном из этих языков, можете свободно продолжать его использовать.

— Крис.

Swift

Можно долго смотреть на три вещи: как течет вода, как имплементируется CoreFoundation в Linux Swift, и как не обновляется документация Perfect

Сначала кратко для тех, кто не в курсе: Perfect — это один из самых стабильных серверных фреймворков на Swift. (benchmark)

Задача:

Сервер Perfect на Linux c MySQL и Protocol Buffers для общения с приложением-клиентом

Важное требование:

Мы прогрессивные хипстеры со свифтом (sarcasm), поэтому дайте самую последнюю версию Swift 4.0.2

Еще одна архитектура?

В последние годы заметно набрала обороты тема альтернативных архитектур для создания приложений под платформу iOS. На доске особого почета уже закрепились некоторые силачи, известные как MVP, MVVM, VIPER. А кроме них есть еще множество других, не столь распространенных.

Среди силачей, на мой взгляд, ни одна не является универсальной таблеткой для всех случаев:

• если нужно сделать пару маленьких экранов со статическим набором данных, то вводить полноценный VIPER довольно затратно;
• если не нравится реактивный подход, то MVVM с большой долей вероятности пройдет мимо;
• если столкнулся с проблемой Massive в большом проекте, то MVC наверняка уже не подходит.

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

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

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

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

Старая реализация

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

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

Напомню, что основным элементом представленного способа задания стилей является обобщенное замыкание:

typealias Decoration<T> = (T) -> Void

Использовать данное замыкание для придания свойств UIView можно следующим образом:

Несмотря на некоторый опыт в мобильной разработке (в том числе с применением Swift), регулярно на почве свифтовых опционалов возникали ситуации, когда я знал что нужно делать, но не совсем внятно представлял, почему именно так. Приходилось отвлекаться и углубляться в документацию — количество "заметок на полях" пополнялось с удручающей периодичностью. В определенный момент они достигли критической массы, и я решил упорядочить их в едином исчерпывающем руководстве. Материал получился довольно объемным, поскольку предпринята попытка раскрыть тему максимально подробно. Статья будет полезна как начинающим Swift-разработчикам, так и матерым профессионалам из мира Objective-C — есть ненулевая вероятность, что и последние найдут для себя что-то новое. А если не найдут, то добавят свое новое в комментарии, и всем будет польза.

Привет Хабр!
Хочу представить мою последнюю open-source разработку — CGLayout — вторая система разметки в iOS после Autolayout, основанная на ограничениях.

"Очередная система автолайаута… Зачем? Для чего?" — наверняка подумали вы.
Действительно iOS сообществом создано уже немало layout-библиотек, но ни одна так и не стала по-настоящему массовой альтернативой ручному layout`у, не говоря уже про Autolayout.

CGLayout работает с абстрактными сущностями, что позволяет одновременно использовать UIView, CALayer и not rendered объекты для построения разметки. Также имеет единое координатное пространство, что позволяет строить зависимости между элементами, находящимися на разных уровнях иерархии. Умеет работать в background потоке, легко кешируется, легко расширяется и многое-многое другое.

CGLayout функциональный продукт, у которого есть хорошие перспективы развиться в большой проект.

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

Часть 1. Взгляд на существующие подходы

Для начала из публикации 21 Amazing Open Source iOS Apps Written in Swift взято приложение Artsy. В нем используется популярный фреймворк Moya, на базе которого и построен весь сетевой слой. Отмечу ряд основных недостатков, которые встретил в данном проекте и часто встречаю в других приложениях и публикациях.

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

let results = query.rx.text
    .flatMapLatest { query in
        networkRequestAPI(query)
    }
results.subscribe(...)   // один запрос в сеть
results.subscribe(...)   // другой запрос

• publish().connect()
• и publish().refcount() (или просто share())

Активные и пассивные Observables

• Active Sequence эмитит элементы постоянно, независимо от того, подписан на нее кто-нибудь или нет
• Passive Sequence начинает эмитить элементы по запросу

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

В этой статье описаны несколько вариантов поиска пустых зависимостей. А в нашем репозитории есть небольшая библиотека, которая поможет в этом: TinkoffCreditSystems/InjectionsCheck