WWDC 2019: огляд і практичне застосування Custom Instruments і SF Symbols

Мабуть, WWDC 2019 стала найбільш значущою конференцією для iOS девелоперів за останні кілька років — так стверджували більшість учасників івенту. Я поїхав разом з колегою, таким чином серед 6 тисяч щасливих учасників цієї події виявилися ще й два розробника з NIX. Ми відвідали найважливіші закриті сесії та воркшопи конференції, на яких як раз і розбиралися особливості роботи з новими інструментами. У цій статті я розповім, що залишилося за кадром онлайн-трансляції і з чим треба працювати iOS девелоперам вже в найближчому майбутньому.

Так, я знаю, що після WWDC 2019 пройшло вже три місяці, і про події конференції встигли написати багато. І все ж для мене ця пауза була не марною з двох причин. По-перше, якби я сів за статтю раніше, ви побачили б приблизно такий початок: «А-а-а, я потиснув руку Крейгу Федериги!» :) По-друге, все літо ми з командою освоювали презентовані фічі, розбиралися в особливостях їх роботи і навіть встигли обговорити нюанси їх застосування на відкритій конференції iThink #3, завдяки чому я зміг чітко сформулювати для себе, що варто поділитися з вами в цій статті.

Custom Instruments

Це фіча від Apple, яка була презентована ще у минулому році. На WWDC 2019 їй було присвячено кілька сесій. На них доповідачі розповіли, як працюють кастомні інструменти, в яких випадках їх застосовувати і чим вони можуть бути корисні девелоперу. Основа — os_signpost. Це трасувальник, який Apple представила в минулому році. Оs_signpost може робити прості івенти та інтервали.

Apple надають os_signpost як низьковитратний трасувальник і запевняють, що його можна додавати в релізну версію. Однак тут же закликають звертатися з ним акуратніше і не зловживати аргументами при трасуванні.

Архітектура самого інструменту в самому початку зустрічає нас Data stream — потоком даних. І тепер їх ми отримуємо саме завдяки os_signpost. Ці дані записуються в input таблицю. Схема цієї і output таблиці описана з допомогою спеціальної XML структури. Кроки зчитування даних і запису в таблицю є трасуванням.

Далі слід modeller. Тут дані, які потрапили в input таблицю, починають оброблятися modeller'ом. Сам моделлер пишеться на спеціальному мовою CLIPS, який має декларативну і імперативну частина для обробки нових подій і перетворення даних. Тут може проводитися кастомный підрахунок або перетворення даних у потрібний нам формат.

Після перетворення даних відбувається їх запис у output таблицю в потрібному форматі. Це називається моделлинг. Після всього цього інформація зчитується Instruments і відображається на екрані. Відображення можна налаштувати за допомогою, знову ж таки, XML форми. Процес зчитування даних з output таблиці з їх подальшим відображенням називається візуалізацією. Здійснюється вона за допомогою StandartUI утиліти.

CloudKit + CoreData

Фіча від Apple, презентована цього року, дозволяє включити автоматичну синхронізацію Core Data з Cloud Kit. Для цього достатньо поставити дві галочки при старті проекту. Тим самим ми отримуємо:

Важливо не забути включити нотифікації і сам CLoudKit в Capabilities, так як автоматично це не відбудеться.

І все, основну роботу за вас зробив Xcode. Автоматично згенерований ось такий контейнер, який агрегує в собі роботу з базою даних і CloudKit. Якщо ж у вас вже є проект і ви хочете скористатися цією новою фичей від Apple, ви можете самі створити Container і застосувати його на місці вже існуючого. Таким чином навіть вже готових старих проектах можна домогтися простий синхронізації з CloudKit.

SF Symbols

У цьому році на сесіях Apple цій темі було приділено надто мало уваги. Сама сесія виявилася максимально насиченою, але подача інформації мала, швидше, поверхневий характер: описувалося всього кілька use cases, що тільки провокувала учасників на додаткові питання. Складалося відчуття, що на тебе висипали купу брендового одягу, а ось в шафу тобі доведеться складати її самостійно.

Я задався питанням, навіщо Apple створила нові символи, якщо девелопери вже багато років спокійно використовували .png/.jpg/.pdf картинки. Можливо, цей спосіб не завжди було вдалим, мав свої особливості та нюанси, але всі вже звикли багаторазово конфігурувати свою UI.

Як всі ми знаємо, розробники мобільних додатків завжди намагаються зробити user friendly ui для своїх користувачів. Інакше додатком ніхто не буде користуватися, так як воно виявиться незручним і незрозумілим. Одним з поширених способів створення нативно зрозумілого програми є використання іконок. Девелопери повинні розуміти їх значення і функції в залежності від місця розташування, коли будуть вставляти іконки в інтерфейс програми.

Іконки поділяють контексти:

Іконки об'єднують контексти:

Кахлі повинні візуально відповідати тексту:

Таким чином, Apple створили SF Symbols для легкого вирішення цих проблем. Так як Apple приділяє багато уваги своїм продуктам, вони створили окремий додаток , яке дозволяє ознайомитися з усіма символами (їх зараз понад 1500), скористатися пошуком, змінити деякі параметри і подивитися, що ж станеться з потрібним тобі символом.

Якщо тобі виявиться недостатньо 1500 символів, тоді читаємо інфу по посиланню вище. Там докладно розповідається, як можна зробити свої кастомні символи. Як стверджує творець — це векторна картинка з метаданими тексту. Тому однією з центральних ідей сесії було змусити розробників концептуально переосмислити підхід до роботи з символами: для них вже незастосовні рішення, які ми довгий час використовували в роботі з звичайними картинками. Простіше говорячи, при роботі з символами думайте про них як про UIFont.

На практиці це виглядає наступним чином. Для використання іконок у своїх проектах нічого не потрібно, тому що вони інтегровані в системний San Francisco шрифт. Для створення символу потрібні нові инициализаторы від UIImage.

 lazy var persistentContainer: NSPersistentCloudKitContainer = {
 let container = NSPersistentCloudKitContainer(name: "_2312")
guard
 let description = container.persistentStoreDescriptions.first
 else {
 fatalError("No description found in NSPersistentCloudKitContainer" )
}

 let id = "iCloud.testnixsolutions.dontBeBored"
 let options = NSPersistentCloudKitContainerOptions(containerIdentifier: id)
 description.cloudKitContainerOptions = options

 container.loadPersistentStores(completionHandler: { (storeDescription, error) in
 if let error = error as NSError? {
 fatalError("Unresolved error \(error), \(error.userInfo)")
}
})
 return container
}()

Як ми бачимо, в одному з инициализаторов з'явився новий параметр UIImage.Configuration. Сюди ми можемо передати UIImage.SymbolConfiguration, що є спадкоємцем UIImage.Configuration. Варто відзначити, що конфігурації є иммутабельными, і для застосування нових параметрів доведеться використовувати applying (_:) .

Конфігурація дозволяє змінити:

PointSize;
UIImage.SymbolScale;
UIFont.TextStyle;
UIImage.SymbolWeight;
UIFont.

А тепер про все по порядку

Point size — параметр, який дозволяє задавати розмір символу. Це та сама перша концепція, яка повинна дати зрозуміти, що символ не є тією самою png-картинкою. Важливо розуміти, що Point size (CGFloat) != CGSize. Таким чином, про розмірах SF Symbols думаємо point size, особливо коли працюємо у зв'язці символу і тексту.

// UIKit
let image = UIImage(systemName: "circle")
let image = UIImage(systemName: "circle", withConfiguration: UIImage.Configuration?)

// SwiftUI
let image = Image(systemName: "circle")
let topFont = topLabel.font
let topConfiguration = UIImage.SymbolConfiguration(pointSize: topFont!.pointSize)
 topImageView.image = UIImage(systemName: "bell", withConfiguration: topConfiguration)

Використовуючи UIImage.SymbolWeight, ми можемо надати товщину лінії (жирність) символу, як і у UIFont.

З наступним параметром SymbolConfiguration.init (font: UIFont) все досить просто. Досить закинути параметром потрібний UIFont, і система все робить за тебе.

Найбільш неоднозначним із усіх параметрів буде UIImage.SymbolScale . Його теж використовують для зміни розмірів символу. Тому в результаті ми отримуємо відразу два параметри, які змінюють розмір символу. Але не варто панікувати. Ці параметри, швидше, взаємодоповнюючі, ніж взаємовиключні.

Уявімо ситуацію: ви задали ідентичний point size вашому UIFont в лайбе, але при цьому ваш символ візуально більше/менше тексту. Щоб не створювати нову конфігурацію з новим значенням point size, нам і стане в нагоді SymbolScale. Він допоможе змінити розмір зображення, не змінюючи при цьому його point size.

Що ж стосується параметра UIFont.TextStyle , то тут також не передбачається нічого складного. Його нам рекомендують використовувати в разі імплементації dynamic font type.

У підсумку

Ми маємо новий підхід до роботи з символами (картинками) та текстом. Фактично Apple змусила iOS-девелоперів переглянути свої погляди на цей рахунок. Плюс до всього, ми отримали більш широкі можливості додавання своїх інструментів, що дозволяє нам знизити поріг входження в проект. Також ми тепер маємо можливість налаштувати CoreData з CloudKit всього в пару кліків. iOS-розробникам належить спробувати і дізнатися багато нового. Починайте працювати з цими інструментами вже сьогодні, рухайтеся вперед і діліться досвідом у статтях і на митапах і, звичайно, в коментарях до цього матеріалу.

Опубліковано: 27/09/19 @ 10:00
Розділ Різне

SEO Блог