Appsconf

Что делать, когда вы получили претензию, требование или иск по вашему проекту от работодателя или партнера с требованием передать все материалы? Как вы можете защитить свои проекты в этом случае или сильно заранее, для профилактики? Много ли разработчиков разбираются в этом? Количество разработок и результатов творческой деятельности неуклонно растет и возникает все больше спорных ситуаций по правам на эти проекты (произведения). Поэтому вопрос защиты прав на Pet-project (пет-проекты) становится практикой. К тому же она может быть не такой уж сложной.

Вадим Кирюхин, управляющий партнер, адвокат юридической фирмы Кирюхин и Партнеры, член международной ассоциации адвокатов (International Bar Association) сегодня расскажет, что такое пет-проект с точки зрения российского законодательства и что вы можете сделать, если получили претензию от вашего работодателя с требованием передать все материалы по пет-проекту. Вы узнаете также, какие в настоящее время есть способы защиты ваших прав на пет-проекты, а в конце рассмотрим кейсы из судебной практики.



Пет-проект это результат любой вашей творческой деятельности: дома на диване, за рабочим столом или в отпуске. Базово, к пет-проектам можно отнести следующие произведения:

• логотипы, эмблемы, эскизы, картинки, дизайн;
• программы, мобильные приложения;
• базы данных;
• сценарии;
• товарные знаки (на этапе их разработки и создания);
• иные результаты творческой деятельности.

Полный список можно посмотреть ниже:



Основные споры, с которыми мы встречаемся на практике, это случаи, когда работодатель (компания, заказчик) пытается забрать себе пет-проект, требуя от автора передачу всех материалов и даже выплату компенсации. Поэтому важно понимать, где проходит грань между служебным произведением (то, что вы делаете на работе) и вашим домашним пет-проектом.

Сейчас в российском законодательстве по умолчанию все исключительные права на произведения, которые работник создает на рабочем месте, принадлежат работодателю и являются служебными произведениями. Он может использовать и распоряжаться произведением по своему усмотрению. В то же время, авторские права на данные произведения по умолчанию принадлежат автору (право упоминания в качестве автора), причем на весь период вашей жизни.

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

Чтобы пет-проект не был приравнен к служебному произведению, судебная практика выделяет следующие основные моменты:

• Если созданное произведение не входило в круг служебных обязанностей работника, то работодатель может использовать его только при условии заключения дополнительного соглашения с работником и выплаты ему соответствующего вознаграждения;
• Если автор использовал для создания своего произведения материалы и оборудование работодателя (например ПК), то только на одном этом основании служебным его суд не признает;
• Если работодатель не начал использовать созданное работником служебное произведение в течение 3 лет с момента его создания, то права возвращаются к работнику;
• Для приравнивания пет-проекта к служебному произведению важно определить трудовые функции и обязанности работника и сопоставить их с созданным пет-проектом.

Базово у вас появляются права на pet-проект без каких-либо формальностей и регистрации по умолчанию, это уже ваш проект, ваше произведение. Это прописано как в российском законодательстве (п. 4 ст. 1259 ГК РФ), так и в международном (Презумпция авторства статья 15 Бернской конвенции об охране литературных и художественных произведений).

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

Варианты защиты

Почта России

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

Нотариальное заверение

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

Публикации

Третий вариант публичное использование созданного произведения. Это включает в себя публикации в различных СМИ, как печатных, так и электронных, а также публичные выступления с видео-фиксацией. Здесь ключевым моментом является наличие даты и времени, а также указание вас как автора (спикера) в материалах.

Депонирование

Четвертый вариант защиты прав регистрация авторских прав в формате депонирования. В России существует большое количество организаций, которые оказывают услуги депонирования, также услуги по управлению авторскими правами. По сути депонирование это когда вы описываете и передаете на материальном носителе (бумаге или компакт-диске) ваш проект для регистрации и в результате получаете свидетельство о депонировании. Можно провести аналогию с регистрацией товарного знака, только процесс депонирования намного быстрее и дешевле:



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

Задепонировать вы можете следующие виды интеллектуальной собственности:

• Программы;
• Сценарии;
• Авторские описания игр;
• Интернет-сайты;
• Логотипы, эмблемы, эскизы, картинки, дизайн;
• Музыкальные произведения;
• Тексты;
• Графические рассказы, комиксы.

Список не исчерпывающий и все зависит от организаций, оказывающих услуги по депонированию. У каждой компании свой перечень, что они депонируют (у одной больше, у другой меньше), но найти нужную нетрудно. Сами документы можно подготовить за пару часов, и вам останется только подать их на регистрацию.

Конфликт

Так что же делать, если вы получили претензию от вашего работодателя с требованием передать все материалы по пет-проекту?

Ответственность

Ответственность за нарушение прав наступает, когда появляются как ваши требования к работодателю, так и его требования к вам. В российском судопроизводстве активно применяются два типа ответственности гражданская и уголовная ответственность за нарушение прав на интеллектуальную собственность:

• Гражданская ответственность это выплата компенсации до 5 000 000 рублей либо штраф в 2-х кратном размере стоимости контрафактных экземпляров произведений;
• Уголовная ответственность лишение свободы на срок до 6-ти лет.

Идем к юристу

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

• Суть претензии;
• Оформление трудовых отношений;
• Сравнительный анализ Pet-проекта и рабочих произведений;
• Мотивированное возражение.

Сейчас в России количество судебных разбирательства по спорам о защите прав на пет-проекты неуклонно растет. Я покажу вам несколько судебных дел из практики.

Кейсы

Иванов vs Горводоканал

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

Суд определил, что в должностные обязанности входила фотосъемка, кадровые документы были оформлены, в положениях и инструкциях отражены служебные произведения.

Решение суда: отказать Иванову в удовлетворении иска.

ООО Амедико vs ООО ТелеПат

Суть дела: группа сотрудников, работая в компании Амедико, в нерабочее время разработали мессенджер (Medsenger) и зарегистрировали одноименный домен. После увольнения открыли свою компанию ТелеПат и зарегистрировали программное обеспечение и товарный знак (ПО/ТЗ).

ООО Амедико обратилось в суд на бывших сотрудников и компанию с требованиями о передачи прав на ПО/ТЗ и выплату компенсации 5 000 000 рублей.
Суд установил отсутствие должного трудового оформления в период работы сотрудников в ООО Амедико, должностные инструкции и кадровые документы не содержали подобного блока работ.

Решение суда: в иске было отказано.

Veeam Software vs eLearning Metadata Manager

Суть дела: Петров А. в рабочее время создал программу для дистанционного обучения. Документами было предусмотрено, что исключительные права остаются за сотрудником. Компания Veeam Software стала использовать программу без указания автора и выплаты вознаграждения.

Решение суда: взыскать с компании компенсацию в размере 2,2 млн. руб. и запретить компании дальнейшее использование программы.

Рекомендации

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

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

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

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

Когда оформлять соглашение в команде?

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

Если вы разрабатываете, например, мобильную игру с другом, оформляйте соавторство. Такие соглашения используются очень часто. Вы также можете разделить ваши права в соглашении (кому-то логотип, кому-то программный код). Доходы в соавторстве по умолчанию делятся между всеми авторами поровну, если вы не пропишете иные условия.

Как передавать, продавать права?

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

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

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

Билеты уже в продаже. Можно участвовать как онлайн, так и по старинке, общаясь вживую. Присоединяйтесь!

Технология Auto Layout появилась в 2012 году, но споры и дебаты о том, как правильно верстать интерфейс, не утихают до сих пор. Использовать ли Auto Layout интерфейс в билдере или в коде? Верстать без него на фреймах или вообще использовать что-то стороннее? Тема такая горячая, что обсуждение докладов в кулуарах на эту тему часто проходит на повышенных тонах у каждого есть свое мнение на этот счет. Сейчас, 8 лет спустя, вопрос всё ещё актуален, к тому же появились новые технологии и библиотеки для верстки.

На профессиональной конференции разработчиков мобильных приложений Apps Live 2020 был круглый стол с представителями Юлы, проектов VPROK и DeliveryClub. Мы обсудили все эти вопросы, а также быстрее и удобнее ли с AL или все-таки можно решать вопрос скорости другим способом.




Начал дискуссию Семен Мацепура из VPROK.

Семен Мацепура (vprok.ru): Сначала расскажу про наше приложение. Полгода назад мы приняли решение написать с нуля приложение конкретно под интернет-магазин. У нас был довольно сжатый срок написать MVP примерно за 2 месяца, и мы решили сделать упор на архитектуру. Выбор пал на архитектуру RIBs, чтобы в дальнейшем мы могли поддерживать проекты, масштабироваться и расти.

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

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

Передаю слово своему коллеге Александру.

Александр Канчурин (vprok.ru): Дополню Семена по архитектуре. Команда у нас была разнородная. И было важно, чтобы каждый мог понимать, что происходит в любом месте кода. А с Auto Layout все были знакомы, было интуитивно понятно, как на нем верстать будь то просто констрейнты в коде или же XIP файлы. К тому же с помощью Auto Layout можно лаконично верстать и сложные интерфейсы.

Да, проблемы с ним конечно же есть. Но не на всех экранах есть, например, проблемы с FPS. Когда мы получили на 2% экранов просадку по FPS, мы провели исследование внутри команды и выяснили, что Auto Layout не на первом месте среди этих проблем. Среди проблем были: подготовка данных для отображения и King-Phisher (на удивление), вместо которого мы собираемся использовать механизмы URLSession.

Да, может быть, там, где у нас действительно есть проблемы из-за Auto Layout, мы будем использовать фреймы, но это меньше 2% наших экранов. Поэтому пока мы не видим смысла переходить на фреймы с Auto Layout все легко решается и всем все понятно.

Хорошо, это мы услышали одну позицию. А пока перейдем к Юле, у которой чуть более радикальный подход к разработке. Павел?

Павел Тихонов (Юла): Да, у нас более радикальный подход в том смысле, что мы вообще не используем Auto Layout. Он еще есть в проекте, потому что это куски legacy, но когда мы туда доберемся, мы его выпилим полностью.

Объясню, почему. Мы используем не голые frame, а сторонние библиотеки для удобной работы с ними. Две из них это PinLayout и FlexLayout обертки как раз над фреймами, которые позволяют декларативно объявлять весь интерфейс. Из-за этого, на начальном этапе у нас чуть-чуть выше порог вхождения, потому что человеку, как минимум надо разобраться с самой библиотекой. Но в будущем мы имеем код-ревью проще. Я смотрю код на Swift, а не открываю какой-нибудь XIB/Storyboard и не просматриваю xml.

Да, не спорю, можно использовать констрейнты в коде. Но нам без них проще жить я не пытаюсь представить в голове, как эти констрейнты просчитаются, как разойдутся, разъедутся и т.д. Я просто читаю Swift и вижу, как объявлены view относительно друг друга, как они позиционируются внутри за меня pin или flex посчитают фреймы, константы и т.д.

Тут еще вопрос в чем у нас минимальное iOS, которое поддерживается это 10.3, а это iPhone 5. А у нас, во-первых, много вариантов Layout, во-вторых, они все комплексные, сложные одновременно списки товаров отображаются не только на первой вкладке, но имеется, как минимум, три вида отображения этих списков. И с этой точки зрения уход от системы именно этого движка дает нам прирост даже на Айфон 5.

Понятное дело, это не дает какого-то супер-плавного layout, который мы видим на iPhone 11 Pro (сейчас уже 12). Но сильно помогает сделать так, чтобы все-таки FPS не проседал, не фризился интерфейс и так далее.

Передаю слово моему коллеге Андрею Опарину.

Андрей Опарин (Юла): Я дополню про Auto Layout. Когда у нас действительно очень сложные вьюшки и нужно, например, что-то скрыть/что-то показать, то довольно сложно обновлять эти констрейнты. Это либо сразу несколько констрейнтов надо обновлять, либо высоту в 0 ставить, отступы убирать и все такое. И без Auto Layout мы по одной модели можем отрендерить, пролейаутить Layout в одном месте: что нужно скрыли, что нужно показали. Например, FlexLayout это очень хорошо позволяет делать.

Второй момент, что очень часто независимо от того, на чем мы верстаем, нам нужно в какой-то момент рассчитывать размеры. Наиболее часто мы хотим рассчитать высоту. Кто-то считает это относительно контента например, высоту строки через bound rect. Я опишу наш подход на примере UI-label. Мы ставим какую-нибудь ширину и вызываем sizeToFit и относительно этой ширины рассчитывается высота. Точно также мы можем сделать наоборот установив высоту, вызвать sizeToFit, и у нас рассчитается ширина.

Такой же подход у нас к дереву вьюх. Мы можем взять опорную ширину, и в sizeToFit уже есть опорная ширина и начальная точка origin 0,0. Мы можем в одном методе Layout расставить все наши элементы относительно точки 0,0, относительно опорной ширины, залейаутить все наши элементы, взять max Y последнего, и получить высоту нашей вьюхи.

ОК. Перейдем к третьей команде. Это DeliveryClub. Ее представляет Кирилл. Кирилл, какие у вас подходы?

Кирилл Шаханский (DeliveryClub): У нас подход дефолтный, потому что, мне кажется, использование Auto Layout это то, что приходит в голову в первую очередь. То, что мы пользуемся преимущественно нативными инструментами, нам помогает еще при найме новых сотрудников, иначе бы это было некой проблемой. То есть в целом я на стороне добра Auto Layout, мы его используем по максимуму, кроме очень сложных кейсов, как, например, transitions и, возможно, анимация.

Тогда следующий вопрос ко всем. Мы говорим, что да, Auto Layout срабатывает, но есть какие-то сложные экраны, где что-то идет не так. Вопрос: что является сложным экраном, как вы это замечаете, используете ли какие-то метрики? Или это просто визуально определяется? Опишите, что происходит в таком сложном случае и как вы действуете при этом.

Андрей Опарин (Юла): Для меня сложный экран, когда есть вьюха, у которой очень много состояний. И в зависимости от состояния что-то может скрываться, а что-то показываться. В этом случае обновлять констрейнты может быть неудобно или сложно, к тому же можно словить баги.

Александр Канчурин (vprok.ru): У нас классический пример сложного экрана это коллекции внутри коллекций. Это горизонтальные списки, например, карточек продуктов в каком-нибудь каталоге. Но мы проводили измерения с помощью инструментов в Xcode и убеждались в том, что Auto Layout на последнем месте.

Кирилл Шаханский (DeliveryClub): Здесь опять же вопрос да, AutoLayout на последнем месте, но насколько это отставание видно для пользователя? У нас iOS 12 (мы совсем слабые устройства не поддерживаем), но коллекции в коллекциях активно используются, и каких-то особых просадок не наблюдаем.

Александр Канчурин (vprok.ru): По нашему опыту, для пользователя очень сильно заметно было, когда мы неправильно данные подготавливали. После того, как подготовку данных изменили, стало намного лучше и лишь где-то иногда местами пролаги случаются. То есть, да, Auto Layout вместе со скрин-рендерингом на это сильно влияют. Поэтому мы хоть и топим за Auto Layout, но признаем, что у него есть проблемные места, и там, возможно, мы будем использовать и считать голые фреймы. К тому же это довольно просто получается.

А коллекции в коллекциях у вас прямо реюзаются? Например, есть ячейка с коллекцией она прямо при реюзе проседает или как?

Кирилл Шаханский (DeliveryClub): У меня есть опыт в двух проектах с разными подходами. В текущем проекте при расчете таких вещей у нас каждая вьюха сама считает размер внутренней коллекции, а внешняя коллекция запрашивает у ячейки ее размер для конкретной модели. View может рассчитать свой размер на основании состояния, которое зашито во view-модель, и она его считает, условно говоря, ручками. Так как расстояние между своими элементами вьюха знает тот же лейбл она считает через bound rect или через sizeToFit то размер коллекции она тоже может знать.

Более интересно у нас было в предыдущем проекте, где мы использовали тоже нативный API systemLayoutSizeFitting. Там мы создавали вьюшку, конфигурировали ее с помощью view модели и накладывали констрейнты. И, в зависимости от направления скролла коллекции, если мы знаем фиксированные ширину (чаще всего) или высоту, systemLayoutSizeFitting достаточно быстро все считает и лагов не вызывает. Например, в случае коллекция в ячейке мы загружали данные, вызывали layoutIfNeeded, коллекция выставлялась и считался contentSize. И это было достаточно быстро.

Ещё вопрос к Юле. Павел говорил, что все еще есть legacy с Auto Layout. То есть в какой-то момент произошел переход от Auto Layout к новому подходу. Расскажи поподробнее, как это случилось и почему? Это произошло из каких-то лагов, проблем в приложении? Или вы просто решили, что так удобнее?

Павел Тихонов (Юла): Когда у нас был Auto Layout, у нас было много подходов. Мы использовали XIBы и сториборды, могли констрейнты расставлять руками (тогда еще не было якорей). Еще был Visual Format Language, когда описываешь строкой констрейнты, и потом они создаются. И, несмотря на мощные на тот момент девайсы, мы начали наблюдать появление лагов, подергиваний на нашей выдаче, а именно на список товаров интерфейс становился комплексным, сложным. Помимо правильной верстки мы меняли и подготовку данных часть в фон переводили, часть считали по-другому, что-то заранее просчитывали. После этого стало получше, но те же подёргивания как были, так и остались. Все это вместе подтолкнуло нас к тому, чтобы отказаться от Auto Layout и сказать: Нет, спасибо, с нас хватит, мы перейдем на фреймы.

Кстати, известный iOS-разработчик Питер Штейнбергер писал в Твиттере, что если вы Bank of Amerika, то вы получите от UIKit, в том числе от Apple, дополнительные выставления setNeedsLayout/layoutIfNeeded в каких-то случаях. Это немного смущает, потому что движок Auto Layout снова начнет все эти расчеты, пересчеты и т.д., что может повлиять на перфоманс.

Хорошо. Давайте закончим с библиотеками Flex и Pin. Расскажите про порог входа? Насколько сложно адаптировать новых ребят, сколько уходит на это времени?

Андрей Опарин (Юла): PinLayout это библиотека, чтобы руками фреймы не высчитывать, в ней легкие конструкции. Таких библиотек на GitHub, наверное, тысячи и в ней ничего особенного нет.

FlexLayout да, тут порог входа повыше, потому что FlexLayout основан на кроссплатформенном фреймворке Yoga. FlexLayout напоминает верстку Swift UI тоже на стеках, примерно также позиции рассчитываются. Есть, конечно, нюансы например, нужно ставить приоритеты как в Auto Layout (сжатие-расширение). Это может по началу путать, сам иногда забываешь про это.

Внутри FlexLayout работает от листьев по сути. Он рассчитывает размеры всех вьюх тоже через sizeToFit (у которых есть внутренний размер). Потом идет наверх, все это собирает и расставляет все отступы. В результате мы там одним методом Layout получаем все рассчитанные фреймы.

Павел Тихонов (Юла): Но мы не наблюдали сложностей с порогом вхождения у ребят в команде никому не приходилось разбираться днями, ночами и неделями. К тому же, если ты застреваешь на FlexLayout, то можно использовать его с PinLayout или даже вообще перейти только на него, он очень простой. У нас был случай, когда новый человек в команде за день собрал ячейку для коллекции, задав всего пару вопросов.

Андрей Опарин (Юла): Но проблемы есть и во Flex. У него есть некое неявное поведение. Например, когда у нас горизонтальный стек в вертикальном стеке, и мы в горизонтальный стек положили какой-нибудь лейбл и картинку, то в некоторых ситуациях он почему-то не ограничивает этот горизонтальный стек внешним. Это тоже может иногда путать. Но это, скорее, баги в самом Flex. Например, у каждой ноды есть свойство display. И если мы отключаем display, не отображая элемент, то FlexLayout не скрывает его, а просто фрейм в 0 ставит. Но если мы поставим фрейм в 0 у какой-нибудь кнопки, у нее внутри будет лейбл, и без script to bounce у нас будет этот лейбл отображаться. Проблем в FlexLayout не так много, но это тоже может запутывать.

Вы упомянули про Swift UI. Как вы считаете, решит ли это наши проблемы с Layout или только еще запутает сильнее?

Семен Мацепура (vprok.ru): Думаю, Swift UI в массы, скорее всего, придет только через пару лет, так как большинство проектов там поддерживает две версии ниже, чем актуальные iOS. Соответственно, до этого момента всё еще поменяется десять раз, и, возможно, довольно кардинально. Поэтому мы пока к нему присматриваемся и делаем это очень аккуратно.

Александр Канчурин (vprok.ru): Я бы еще добавил, что для нас переход к Swift UI будет равносилен переделыванию некоторых слоев архитектуры, а это повлечет за собой немалые последствия, поэтому нужно будет больше времени для разработки.

Кирилл Шаханский (DeliveryClub): У нас, наверное, аналогичная ситуация. Даже если мы поднимем версию, вряд ли мы будем активно на него переходить. Но кажется, SwiftUI может решить проблему и быстрой верстки, и быстрого обсчета. В стадии production Swift UI может стать стандартом де-факто.

Андрей Опарин (Юла): Я тоже пробовал Swift UI. Там классная, всегда валидная верстка. Единственное, что после последнего TTDC, когда обновили SDK, они добавили пару компонентов и поставили им iOS 14. Это обычная практика у них, но мы могли бы собрать новые элементы и для iOS 13. Вторая проблема у них с навигацией, то есть в случае present нескольких экранов, вызывая dismiss для закрытия двух или трех. То же самое с navigation-стеком. Как это нормально делает Swift UI, я пока не понял но можно, например, пробрасывать какие нибудь флаги, для того, чтобы понять до какого экрана закрывать стэк.

Последний вопрос: Есть ли жизнь без Auto Layout?

Павел Тихонов (Юла): Конечно, она есть. И в Юле можно наблюдать это каждый день. И, да, жизнь без AutoLayout не становится сложнее, больнее, хуже или еще как-то. Местами, она становится даже проще. А если говорить про поддержку прошивок и девайсов пятилетней давности, то и плавнее.

Работа над программой докладов весенних конференций уже идёт: 22 декабря Программный комитет FrontendConf встречался онлайн со спикерами, а в пятницу, 25 декабря, в 19:00 состоится встреча докладчиков и ПК DevOpsConf.
Подключайтесь сами или перешлите своим докладчикам!

Для 2021 года мы подготовили 14 конференций, в том числе и перенесенных с этого года. Смотрите план наших конференций на весь 2021 год с датами закрытия Call for Papers.
Изучайте, подбирайте конференцию для себя!