Objective C *

В StackOverflow по-прежнему появляется много вопросов о валидации App Store чеков, поэтому мы решили написать статью на эту тему в формате вопросов и ответов.

(Прим.перев.: автор оригинального материала — пользователь github и twitter Thomas @tclementdev. Ниже в переводе сохранено повествование от первого лица, которое использует автор.)

Думаю, что большинство разработчиков использует libdispatch неэффективно из-за того как её представили сообществу, а также из-за запутанной документации и API. Я пришел к этой мысли после чтения обсуждения «concurrency» в рассылке посвященной развитию Swift (swift-evolution). Особенно просвещают сообщения от Пьера Хабузит (Pierre Habouzit — занимается поддержкой libdispatch в Apple):

MVC был давним стандартом в паттернах проектирования, используемых для написания iOS приложений. Структура iOS приложений, которые создавались ранее, была основана на одном базовом компоненте, который присутствует везде, и называется он — Controller. На WWDC19 был представлен SwiftUI, который не имеет такого компонента.

Проблема с так называемыми massive view-controllers должна быть решена в SwiftUI. Так, необходимо найти новый способ правильной декомпозиции кода. Давайте посмотрим на текущее состояние платформы и подумаем, какие парадигмы мы можем использовать при разработке для iOS13 и более поздних версий.

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

Но теперь все это имеет смысл, после использования из в разработки на React в течение нескольких недель, я теперь не могу вернуться к своим старым способам разработки под iOS. Я не буду переходить на javascript (AKA React Native) для разработки мобильных приложений, но вот кое-что, чему я научился.


Вернувшись к разработке под iOS, я создал новый проект и начал исследовать ReSwift, это реализация паттерна Flux и Redux в Swift. И это довольно просто работает, я несколько раз клонировал архитектуру JavaScript приложении, теперь у меня есть глобальное состояние, и мои контроллеры просто слушают это состояние. Сами контроллеры состоят из различных компонентов представления, которые инкапсулируют очень специфическое поведение.

Во время проведения WWDC 2019, одним из самым больших и захватывающих моментом был анонс релиза SwiftUI. SwiftUI — это совершенно новый фреймворк, который позволяет проектировать и разрабатывать пользовательские интерфейсы с написанием меньшего количества кода, декларативным способом.

В отличие от UIKit, который обычно использовался в сочетании с storyboards, SwiftUI полностью основан на программном коде. Тем не менее, синтаксис очень прост для понимания и проект можно быстро просмотреть с помощью Automatic Preview.

Поскольку SwiftUI использует язык Swift, он позволяет создавать приложения той же сложности с гораздо меньшим количеством кода. Более того, использование SwiftUI автоматически позволяет приложению использовать такие функции, как Dynamic Type, Dark Mode, Localization и Accessibility. Кроме того, он доступен на всех платформах, включая macOS, iOS, iPadOS, watchOS и tvOS. Итак, теперь ваш код пользовательского интерфейса может быть синхронизирован на всех платформах, что дает больше времени для того, чтобы сосредоточиться на второстепенном платформо-зависимом коде.

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

Мы пишем множество юнит тестов, разрабатывая приложение SoundCloud под iOS. Юнит тесты выглядят вполне великолепно. Они короткие, (надеюсь) читабельны, и они дают нам уверенность в том, что код, который мы пишем, работает так, как и ожидается. Но юнит тесты, как следует из их названия, охватывают только один блок кода, чаще всего функцию или класс. Итак, как отловить ошибки, которые существуют во взаимодействиях между классами — ошибки, такие как утечки памяти?

Протокол UIAppearance появился в iOS 5 в 2011 году, в те далёкие времена, когда у Instagram не было приложения под Android, а сериальному Неду Старку ещё не отрубили голову.

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

Новогодние праздники прошли, а мое стремление писать полезные и не очень статьи — нет! Сегодня поговорим о UITableView, работе с UITableViewDataSource и переиспользовании ячеек. Затронем как установить рут контроллер без сториборда, ошибки при работе с таблицей, лейаут и большой заголовок для UINavigationBar.

Для тех, кому нравятся несмешные шутки, я записал ролик на YouTube. Ну а здесь всё будет серьезно. Давайте начнём.

Пока в соседней комнате готовят оливье, я пишу небольшой туториал как рисовать кодом. Сразу представляются строчки кода с дробными числами, где ведём линию по точкам. А для вычисления радиуса окружности берём яд змеи, надежность хранения фото в iCloud и шепчем заклинание. Пугает, понимаю. Даже в ролике на YouTube вставил шутку:

— “Ааастановите, пожалуйста, вот у магазина” — прокричал герой российского сериала.

В целом, дорогой друг, ты прав. Будут и дробные числа, и куча строчек кода. Но будет намного проще. Интересно? Давай к делу.

Большинство iOS-проектов частично или полностью переходят на Swift. Swift — замечательный язык, и за ним будущее разработки под iOS. Но язык нераздельно связан с инструментарием, а в инструментарии Swift есть недостатки.

В компиляторе Swift по-прежнему находятся баги, которые приводят к его падению или генерации неправильного кода. У Swift нет стабильного ABI. И, что очень важно, проекты на Swift собираются слишком долго.

В связи с этим существующим проектам может быть выгоднее продолжать разработку на Objective-C. А Objective-C уже не тот, что был раньше!

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

— “Какая-то библиотека, кто-то обновил… Хейтер тут причем? Почему мне, отличному разработчику, нужно тратить время на эту статью?”

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

Принято считать, что Wallet – не самый популярный сервис в СНГ. Но уже во втором проекте подряд заказчик ставит задачу «Сделать интеграцию с Wallet». Поэтому я решил написать эту статью, чтобы рассказать о сервисе в целом и показать, как интегрировать в него свой продукт.

Что такое Wallet? Он позволяет держать в телефоне различного вида карты (билеты, скидочные карты и т.п.), облегчая жизнь пользователям продукта. Более того, есть возможность актуализировать информацию о карте посредством push-уведомлений, но это тема для отдельной статьи. Но если у вас есть карта/билет/абонемент, которые можно интегрировать в телефон, то для этого есть решение! Как это сделать – читайте ниже.

Сегодня мы открываем цикл статей о том, о чём обычно не говорят на технических конференциях и митапах. Этот и последующие посты расскажут, как устроен механизм монетизации в популярном в США развлекательном iOS-приложении iFunny, разработкой которого мы занимаемся.

В этом выпуске: больше новых рефакторингов, лучше автодополнение, поддержка баз данных из DataGrip и даже поддержка Touch Bar. Более подробно — под катом.

Быстрая и качественная доставка контента пользователям — важнейшая задача, которой мы постоянно занимаемся, работая над приложением iFunny. Отсутствие элементов ожидания даже при плохом соединении — к этому стремится любой сервис для просмотра медиа-контента.

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

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

Вы когда-нибудь писали адаптеры для Keychain или NSUserDefaults? Они полностью состоят из однотипных сеттеров и геттеров. Предлагаю написать логику один раз, предоставив остальное рантайму. За реализацией прошу под кат.

Привет!

Этот пост, конечно же, про AppCode 2018.1. Впрочем нет, в этот раз он еще и про первый апдейт. У нас много нового и полезного, все в картинках под катом.

Со временем языки программирования постоянно изменяются и развиваются из-за появления новых технологий, современных требований или простого желания освежить стиль написания кода. Реактивное программирование можно реализовать с помощью различных фреймворков, таких как Reactive Cocoa. Он изменяет рамки императивного стиля языка Objective-C и у такого подхода к программированию есть что предложить стандартной парадигме. Это, безусловно, и привлекает внимание iOS разработчиков.

ReactiveCocoa привносит декларативный стиль в Objective-C. Что мы подразумеваем под этим? Традиционный императивный стиль, который используют такие языки как: C, С++, Objective-C, и Java и т. д. можно описать так: Вы пишете директивы для компьютерной программы, которые должны быть выполнены определенным способом. Другими словами, вы говорите «как сделать» что-то. В то время как декларативное программирование позволяет описать поток управления как последовательность действий, «что сделать», не определяя, «как делать».

Мы вновь ждем у себя гостей митапа CocoaHeads! Встречаемся уже в эту пятницу, 13 апреля. Традиционно будет пицца, круглый стол, викторина и, конечно же, интересные доклады. Зарегистрироваться на мероприятие можно через приложение CocoHeads для iOS.