Разработка под iOS

При работе с UITableView хотелось избежать написания шаблонного кода, который еще больше усложняется, если нужно обновлять состояние таблицы анимировано. Apple представила свое решение этой проблемы на WWDC 2019, но оно работает только с iOS 13. А у нас, как у студии разработки мобильных приложений, нет такой роскоши в выборе минимальной версии iOS.

Поэтому мы реализовали наше видение data-driven подхода для работы с таблицами, попутно упростив настройку ячеек. И добавили анимированное обновление таблицы, которое основано на автоматическом подсчете различий между старыми и новыми данными за линейное время O(n). Все это мы оформили в небольшую библиотеку, которую назвали TableAdapter.

О том, что у нас получилось и как мы к этому пришли, и пойдет речь в статье.

Привет! Меня зовут Александр Никишин, я занимаюсь разработкой iOS-приложений в компании Badoo. В статье я расскажу о том, как мы исследовали баг в UIKit, который Apple не хотела исправлять на протяжении полугода.



Всё началось в августе 2019 года с первых бета-версий iOS 13. Тогда мы впервые столкнулись с проблемой. В приложениях Badoo и Bumble мы постоянно работаем над улучшением интерфейсов и, например, стараемся максимально оптимизировать нудный и не любимый пользователями процесс регистрации. Системные предиктивные подсказки над клавиатурой — отличный способ сокращения количества кликов пользователя при вводе данных. Однако в новой версии iOS мы с удивлением обнаружили, что подсказки при вводе номера телефона пропали.

В этой статье мы не будем разбирать MVP, MVVM, MVI или что-то подобное. Сегодня мы поговорим о более глобальной вещи, чем просто архитектура уровня представления. Как спроектировать действительно большое приложение, в котором смогут комфортно работать десятки или сотни разработчиков? То приложение, которое легко расширять независимо от того, как много кода мы уже написали.

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



Я с интересом изучил их код, но испытал некоторое разочарование. Нет, не в том смысле, что они что-то сделали неправильно, вовсе нет. Просто я не узнал из их кода практически ничего нового. Их реализация, это скорее про Combine, нежели про анимацию. И я решил построить свой лунопарк написать свою статью об анимации в SwiftUI, реализовав примерно тот же концепт, но используя на 100% возможности встроенной анимации, даже если это не совсем эффективно. Изучать — так до конца. Экспериментировать — так с огоньком:)

Вот что получилось у меня:


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

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

warning: под катом много картинок и gif-анимаций.

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


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

Привет Хабр! Язык программирования Swift обладает большой популярностью ввиду его использования в написании приложений под iOS, поэтому его развитие представляет интерес для всех занятых в этой области.

Давайте посмотрим что нового приготовил разработчикам Swift версии 5.3.

Multiple trailing closures

Новая версия (SE-0279) предлагает новый синтаксис для конечных замыканий, который позволяет вызывать несколько замыканий в качестве параметров функции более читаемым способом. Это сводит к минимуму использование слишком большого количества скобок в сигнатуре функции.

import Foundation

func load(url: String, success: (Data) -> Void, failure: (Error) -> Void) {
    
}

// old  version

load(url: "someURL", success: { data in }, failure: { error in })

// new multiple trailing closures

load(url: "someURL") { (data) in
    // do smth
} failure: { (error) in
    // do smth
}

На примере 2 вариантов вызова видно, что визуально второй смотрится несколько приятнее.

Multi-Pattern Catch Clauses

В настоящее время каждый пункт catch в операторе do-catch может содержать только один шаблон. Чтобы обойти эту проблему, разработчики будут использовать возможности вариантов коммутаторов для включения сопоставления шаблонов в тело операторов catch, тем самым увеличивая вложенный и дублированный код (SE-0276).

В этой подборке рендеринг экранов ВКонтакте, победы и поражения Flutter, архитектуры и скриншоты, продуктовая аналитика и архетипы игроков, виртуальные свидания в умных домах и много других интересных материалов!

Всем привет! В преддверии старта продвинутого курса «Разработчик IOS» мы публикуем перевод второй части статьи про неоморфизм с помощью SwiftUI (читать первую часть).

---

Темная тема

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

Сначала добавьте еще два цвета в расширение Color, чтобы у нас под рукой было несколько константных значений:

static let darkStart = Color(red: 50 / 255, green: 60 / 255, blue: 65 / 255)
static let darkEnd = Color(red: 25 / 255, green: 25 / 255, blue: 30 / 255)

Мы можем использовать их в качестве фона для ContentView, заменив существующий Color.white, как показано здесь:

var body: some View {
    ZStack {
        LinearGradient(Color.darkStart, Color.darkEnd)

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

Новый view фона, который мы собираемся добавить, позволит нам указать любую форму для нашего визуального эффекта, поэтому мы больше не привязаны к окружностям. Он также будет отслеживать, следует ли отрисовывать вогнутым наш выпуклый эффект (внутрь или наружу) в зависимости от свойства isHighlighted, которое мы можем менять извне.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Testing Your RxSwift Code" автора Shai Mishali с сайта raywenderlich.com.

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

Observable — мощный механизм, который позволяет вам, как разработчику, реагировать на изменения и быть уверенным что состояние вашего приложения всегда актуально. Вместе со всеми преимуществами которые это дает, тестирование Observable — не такая тривиальная задача, как простое использование XCTAssert для обычных значений. Но не переживайте — эта статья наставит вас на путь становления экспертом в тестировании RxSwift!

Эта статья научит вас создавать unit тесты для Observable потоков. Вы научитесь некоторым доступным техникам для тестирования RxSwift кода, а также некоторым советам. Давайте начнем.

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


foto source: unsplash.com

Если ваше приложение мультиязычное, универсальное и рассчитано на разные девайсы, то на создание скриншотов для каждой конфигурации можно потратить много времени. Представьте, у вас четыре языка, поддержка iPad и iPhone и вам нужно сохранить по 4 экрана, — это 32 скриншота. Процесс необходимо автоматизировать, чтобы не тратить время каждый раз, когда обновляются интерфейсы.

Инструмент XCTestPlan, который появился в XCode 11, позволяет нам создавать несколько конфигураций для тестов. Сейчас конфигурации чаще всего применяются, чтобы определить, как тесты будут запускаться, включая выбор языка для приложения. В этой статье вы узнаете, как можно использовать XCTestPlan, чтобы автоматизировать получение скриншотов.

Салют, хабровчане! В преддверии старта продвинутого курса «Разработчик IOS» мы подготовили еще один интересный перевод.

---

Неоморфный дизайн — это, пожалуй, самый интересный тренд последних месяцев, хотя, по правде говоря, Apple использовала его в качестве своего дизайнерского мотива еще на WWDC18. В этой статье мы рассмотрим, как вы можете реализовать неоморфный дизайн с помощью SwiftUI, почему вы могли бы захотеть это сделать, и — что наиболее важно — как мы можем доработать этот дизайн, чтобы повысить его доступность.

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

Последний год я так или иначе пишу приложения на Flutter для iOS и Android. До этого у меня был и есть 5 летний опыт работы с Xamarin. Это были замечательные 5 лет. Благодаря Xamarin и моей любви к этому фреймворку я, в принципе, перешел в стан разработчиков, этот инструмент помог заработать мне немалых денег, знаний и найти замечательных коллег. Так почему же сейчас я пишу на Flutter? Короткий ответ, потому что Flutter покрывает все потребности кросс-платформенной разработки.

Немного истории

Поправьте меня если я не прав, но 2009 год был во многом ключевым для мобильной разработки в целом и кроссплатформенной разработки в частности. В 2009 вышел iPhone 3gs, который позволял запускать сторонние приложения из AppStore. Впервые эта возможность появилась в годом ранее в iPhone 3g, но по настоящему массовым, «народным» айфоном стал 3gs. Опять же, годом ранее, в сентябре 2008 Android был представлен публике и в 2009 многие производители телефонов стали пробовать Android для своих новый моделей телефонов. Весной 2009 компания Nitobi представила PhoneGap — новый фреймворк для создания кроссплатформенных приложений на основе HTML5, CSS и JS. В том же году, в сентябре компания Ximian выпустила MonoTouch, который позволял писать iOS приложения с использованием Mono и C#. В том же 2009, в декабре, компания Rovio Entertainment выпустила игру для iOS и, на минуточку, Maemo, которая во многом положила начало индустрии мобильных игр — Angry Birds. Последний пример здесь не случайно.

Приветствую, уважаемые любители и знатоки Python!

В этой статье я покажу вам, как применять эффекты OpenGL к своим кастомным карточкам, если вы используете в своих приложениях такие кроссплатформенные инструменты как фреймворк Kivy и библиотеку материального дизайна для этого фреймворка — KivyMD. Погнали!

В нашем новом дайджесте новое приложение “Медузы” на Flutter, нетривиальные анимации, переписывание приложения Snapchat, новый Unreal Engine, доходы приложений и много других интересных материалов.

Когда вы приходите к решению о создании мобильного приложения, не имея в разработке опыта, неизбежно возникает вопрос найма разработчиков. Сам по себе вопрос не дает ответа, поэтому приходится анализировать плюсы и минусы услуг аутстаффинга или аутсорсинга различных исполнителей. Первый показатель, который приходится учитывать при анализе – цена. Хочется дешевле, но обойдется ли в итоге дешево? Этой статьей мы в Omega-R хотим показать подводные камни, которые могут скрываться за часто встречающимися низкими ценами.

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

Модернизация

Библиотека Keras предоставляется широкий набор инструментов для препроцессинга данных, особенно для изображений. Метод ImageDataGenerator (Рис.7) позволяет расширять набор данных искусственными преобразованиями.


Рис.7. – Генератор данных.

Первое число rotation_range – случайное число, для ротации изображений внутри генератора. Width_shift_range — показывает насколько можно уменьшить значения пикселей по ширине. Height_shift_range – коэффициент на который будет умножаться каждый пиксель для сжатия по высоте. Shear_range – интенсивность сдвига, угол сдвига в направлении против часовой стрелки в градусах. Zoom_range – диапазон для случайного масштабирования. Horizontal_flip – случайное отображение картинки по горизонтали. Vertical_flip – случайное отображение изображения по вертикали. Fill_mode – точки за пределами входных данных заполняются в соответствии с заданным режимом. Data_format – формат данных изображения. Таким образом, нейросеть будет обладать лучшим обобщением, ведь исходный датасет в основном обладает чистыми пикселями, цифры находятся по центру. На реальных фотографиях возможны другие ситуации, когда жест находится в углу или смазан. Процесс обучения переписывается с учетом новых данных.

На Рис.8 график Test, начал убывать, поэтому обучение было остановлено. Если бы для остановки не использовалась метрика val_acc, алгоритм бы продолжил свою работу, в результате получив переобученную нейронную сеть.

Около года назад я заинтересовался новой технологией Kotlin Multiplatform. Она позволяет писать общий код и компилировать его под разные платформы, имея при этом доступ к их API. С тех пор я активно экспериментирую в этой области и продвигаю этот инструмент в нашей компании. Одним из результатов, например, является наша библиотека Reaktive — Reactive Extensions для Kotlin Multiplatform.

В приложениях Badoo и Bumble для разработки под Android мы используем архитектурный шаблон MVI (подробнее о нашей архитектуре читайте в статье Zsolt Kocsi: «Современная MVI-архитектура на базе Kotlin»). Работая над различными проектами, я стал большим поклонником этого подхода. Конечно, я не мог упустить возможность попробовать MVI и в Kotlin Multiplatform. Тем более случай был подходящий: нам нужно было написать примеры для библиотеки Reaktive. После этих моих экспериментов я был вдохновлён MVI ещё больше.

Я всегда обращаю внимание на то, как разработчики используют Kotlin Multiplatform и как они выстраивают архитектуру подобных проектов. По моим наблюдениям, среднестатистический разработчик Kotlin Multiplatform — это на самом деле Android-разработчик, который в своей работе использует шаблон MVVM просто потому, что так привык. Некоторые дополнительно применяют «чистую архитектуру». Однако, на мой взгляд, для Kotlin Multiplatform лучше всего подходит именно MVI, а «чистая архитектура» является ненужным усложнением.

Поэтому я решил написать эту серию из трёх статей на следующие темы:

1. Краткое описание шаблона MVI, постановка задачи и создание общего модуля с использованием Kotlin Multiplatform.
2. Интеграция общего модуля в iOS- и Android-приложения.
3. Модульное и интеграционное тестирование.

Ниже — первая статья серии. Она будет интересна всем, кто уже использует или только планирует использовать Kotlin Multiplatform.

Идея

На WWDC 2019 была представлена SwiftUI — технология коренным образом влияющая на создание UI в приложениях для экосистемы Apple. Нам в Distillery стало интересно в ней разобраться чуть глубже, чем это подано в примерах от Apple. В идеале нужно было запилить какой-нибудь полезный для iOS команды и сообщества UI компонент. С идеями по этому поводу оказалось туго, поэтому решили пилить что-то просто забавное. Вдохновил вот этот концепт:

Особенно интересным показалось обилие нетривиальной анимации. Таким образом, по ходу реализации хотелось проверить, насколько SwiftUI удобен и приспособлен для чего-то более сложного, чем почти статический UI из примеров WWDC 2019.

Технический директор Борис Горячев рассказывает, как «Медуза» работала над ним целый год и почему оно написано на Flutter

12 мая состоялся релиз новых мобильных приложений «Медузы» (iOS, Android) — почти через два года после того, как мы решили их переписать. Почему так долго? Почему не нативные приложения? Почему именно Flutter? Обо всем этом рассказывает технический директор «Медузы» Борис Горячев.