iOS Developer
В первой статье про скрининг-колл с рекрутером я рассказал о вопросах, которые скорее всего вам зададут на первичном коротком интервью в США. В этой статье я расскажу про вторую часть скрининг-колла, когда мячик находится на стороне того, кого собеседуют.
А именно — что действительно имеет смысл спрашивать у рекрутера, а какие вопросы не стоит задавать.
Продолжаю серию постов с разбором всех популярных архитектурных паттернов, использующихся в iOS разработке: устройство, плюсы и минусы, а также когда и где их лучше применять. Литературы по этому вопросу преступно мало, редкие обсуждения в интернете ограничиваются собственным опытом и какими-то поделками на гитхабе.
Все, кто хочет не просто знать что стоит за названием той или иной архитектуры, но ещё и в каком случае какую использовать — наливайте чай и устраивайтесь поудобнее, будет лампово. Разбираем паттерны, реализующие концепцию Чистой Архитектуры — самые масштабируемые и надёжные.
Opaque return types (непрозрачные типы) — это новая языковая конструкция, представленная Apple в Swift 5.1. Их можно использовать для возврата некоторого (some) значения функции (function)/метода (method) и свойства (property), не раскрывая конкретный тип значения клиенту, который вызывает API. Тип возврата будет некоторым типом, реализующим протокол (protocol). С помощью этого решения API-интерфейс модуля больше не должен публично раскрывать базовый внутренний возвращаемый тип метода, ему просто нужно вернуть opaque type протокола с помощью ключевого слова some. Компилятор Swift также сможет сохранить базовую идентичность (identity) возвращаемого типа, в отличии от варианта с использованием протокола в качестве возвращаемого типа. SwiftUI использует opaque return types внутри своего протокола View, который возвращает some View в свойстве body.
Я проанализировал все топовые предложения банков для обеспеченных людей — в этой статье я рассказываю о том, как правильно подходить к выбору премиальных пакетов обслуживания, и как получить безлимитные 5% кэшбэка на все покупки + 10% на расходы в любых ресторанах, кафе и заправках. Актуально для тех, кто получает высокую зарплату, но раньше не особо интересовался, что с учётом этого можно стрясти с банков (на самом деле, довольно много!).
В этой статье мы рассмотрим решение для мгновенного разрешения мерж-конфликтов в файле .xcodeproj, что является одной из самых трудоемких проблем, с которыми сегодня сталкиваются команды iOS и macOS разработчиков. К концу этой статьи у вас будет рабочая среда, обеспечивающая бесконфликтное слияние.
Всем привет, меня зовут Виталий, я iOS-разработчик в юните мессенджера в Тинькофф. Сегодня поговорим о том, что такое DI, зачем он нужен, рассмотрим известные библиотеки для DI и сравним их между собой. Поехали!
Первое, что видит пользователь - UI приложения. И в мобильной разработке больше всего вызовов связано именно с его построением, а большую часть времени разработчик тратит на чизкейк верстку и логику презентационного слоя. В мире существует множество подходов к решению этих задач. Часть того, что мы расскажем, скорее всего уже используется в индустрии. Но мы попытались собрать воедино некоторые из них, и уверены, что это станет вам полезно.
На старте проекта мы захотели прийти к такому процессу разработки фич, чтобы вносить как можно меньше изменений в код при максимальном соответствии с пожеланиями дизайнеров, а также иметь под рукой широкий спектр инструментов и абстракций для борьбы с бойлерплейтом.
Эта статья будет полезна тем, кто хочет тратить меньше времени на рутинные процессы верстки и повторяющуюся логику обработки состояний экранов.
defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES
-Xfrontend -warn-long-function-bodies=100
-Xfrontend -warn-long-expression-type-checking=100
Жил был скромный вью-контроллер VCYellow. И не было у него ни картинки, ни текста, ни даже малюсенькой бизнес логики. Жил он обычной вью-контроллерской жизнью.
