iOS *

Данная публикация является второй частью ранее опубликованного материала и рассчитана на ознакомление с ним. Ссылка на первую часть - Тыц

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

Всем доброго времени суток! С вами Анна Жаркова, ведущий разработчик компании Usetech. Продолжаем говорить про Kotlin Multiplatform и работу с асинхронными функциями. В этой статье мы будем рассматривать, как можно удобно подключать Kotlin общий код на стороне iOS, используя возможности Swift. А именно, как работать с Combine Publishers и новым async/await.

_{* Примеры кода доступны в полной версии статьи, и к сожалению, не доступны в предпросмотре}

Концепция Kotlin Multiplatform позволяет нам сделать код максимально общим, т.е вынести практически все в общую часть.

Если на стороне common, мы оперируем корутинами и suspend функциями, то на стороне iOS проекта нативного благодаря поддержке interop Kotlin/Obj-C с версии Kotlin 1.4 suspend функции преобразуются в функции с completion handler.

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

Однако, не все любят простой синтаксис completion handler. А еще мы прекрасно знаем, что если ими злоупотреблять, можно легко попасть в ситуацию callback hell и потерять читабельность и чистоту кода.

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

Попробуем сделать наш Kotlin код совместимым с Combine Publishers. Для этого превратим вызов нашей suspend функции в AnyPublisher с использованием Future Deferred и Promise.

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

Bottom Sheet представлялся мне сложным и недосягаемым. Это был вызов! Я не понимал, с чего начать. Возникало много вопросов: использовать view или view controller? Auto или manual layout? Как анимировать? Как скрывать Bottom Sheet интерактивно?

Но всё изменилось после работы над Bottom Sheet для приложения Joom, где он используется повсеместно. В том числе и в таких критических сценариях, как оплата. Так что могу точно сказать, что в этом компоненте мы уверены. Настолько уверены, что я даже рассказывал о нём на Podlodka iOS crew #7. В рамках воркшопа я показал, как сделать Bottom Sheet, который умеет подстраиваться под размер контента, интерактивно закрывается и поддерживает UINavigationController.

Стоп, но Apple же предоставила системный Bottom Sheet. Зачем писать свой? Действительно, это так, но компонент поддерживается только с iOS 15. А это значит, что полноценно его можно будет использовать только через 2-3 года. К тому же часто требования дизайнеров выходят за рамки стандартных iOS-элементов.

В рамках статьи хочу развеять туман над Bottom Sheet, ответить на вопросы, которыми задавался я сам и предложить один из вариантов реализации. Чтобы в конце вы могли добавить в резюме строчку «Профессионально делаю Bottom Sheet'ы»

Если заинтересовал, то начнём! Создадим простой Bottom Sheet и шаг за шагом его прокачаем.

1. Научимся подстраиваться под размер контента и закрывать Bottom Sheet.

2. Добавим интерактивное закрытие, учитывая контент, который скроллится.

3. Поддержим UINavigationController с навигацией внутри Bottom Sheet.

Эта таинственная история рассказывает о том, как два брата акробата программиста Чук и Гек начали делать свой проект на SwiftUI и столкнулись с неведомым! Как Optional притворялся View и к чему это привело.

Эту статью я решил написать под впечатлением от выступления Евгения Ртищева (@katleta) на конференции Mobius. Так же как и в его докладе, в этой статье я хочу показать, как можно, используя подзабытые нативные средства iOS, без труда выполнять простые и очень частые задачи.

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

Эта статья является логическим продолжением UIKit ты вообще про UI?
Если вы ее пропустили, рекомендую сначала ознакомиться с ней. На всякий случай напоминаю, что весь графический интерфейс – это ответственность слоев (не вью!).

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

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

Давайте разберемся, как работают трансформации, постараемся понять подходы к ним и найти закономерности. Для того, чтобы начать погружение в трансформации, стоит для начала разобраться с контекстом. Ведь мы не просто рисуем карандашом на листе бумаги, мы управляем объектами в виртуальном мире. Сделаю небольшую оговорку – на самом деле все это очень сложные технические процессы (шедевры инженерной мысли), разобраться в которых за 15 минут не получится. Поэтому я буду умышленно упрощать некоторые вещи для того, чтобы сформировать общее понимание.

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

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

Привет, Хабр! Меня зовут Никитин Алексей, я iOS разработчик в компании 65apps. Хорошо было бы порассуждать о Dragon and Dangerous, но нет. Речь пойдет о перемещении объектов. Перетаскивание как внутри одного приложения, так и между разными — с точки зрения пользователя вещь обыденная. Но под капотом механизма D'n'D в современных приложениях могут скрываться разные варианты решения. О них и поговорим.

Привет! На связи iOS-разработчик KODE — Семён Медведев. Наша команда разрабатывает крутые цифровые продукты для государства и бизнеса, в том числе мобильные приложения.

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

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

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

История разработки приложения Quickin

В мобильных приложениях табличные экраны занимают значительное место в общем объёме интерфейса. Это происходит благодаря их возможности отображать большое количество контента. Но есть и обратный эффект — программирование таких экранов порождает много однотипного кода.

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

Вне зависимости от того, какую архитектуру (MVC, MVVM, VIPER и др.) вы используете, компоненты из этой статьи помогут сократить время разработки, поиска и исправления ошибок и добавления нового функционала.

Всем привет! 

Вышел AppCode 2021.3, а значит, пора о нем рассказать.