Хорошее решение, но у нас в команде экспертиза в Kotlin была не у всех. Не знаю как сейчас с поддержкой браузерами Wasm, но на тот момент были какие-то проблемы , уже не вспомню), да и в JS компиляция работала с некоторыми ограничениями. Но и порог входа в JS существенно ниже показался для всей команды, чем в Kotlin, а времени мало, поэтому вариант был отметен. Моя б воля, именно так бы и сделал, но приходится учитывать мнение всех членов команды, а, самое главное, требования бизнеса.
MUI компоненты кастомизируются. Но код этой кастомизации часто достигает таких размеров, что чаще реально проще с нуля написать. Ну каскадные таблицы стилей же не сложные :) тут и школоте под силу
Я вот и сам не рад, что приложение в которое я получаю зп окирпичивают :) Поэтому пользуюсь уже года 4 «устаревшим» приложением одного однобуквенного банка. Ну если вам норм десятками ставить новые приложения от банка, то не все этому рады, а PWA позволяет не бесить пользователей бесконечными нативными приложениями. Ну такова уж реальность сейчас в стране. Я уж лучше PWA попользую или вэб версию. У каждого свой путь.
Ну если чуток поправили верстку, то, возможно AI и справится. Но вот попробуйте сетку натравить на инсту и она налажает как только сможет. А там разрабы стараются структуру менять довольно сильно. Я не о том, что это невозможно. Я про то, что поддерживают такую прилу будет крайне сложно и муторно, будет сжирать уйму времени. Вот и спросил автора: ради чего такие приседания? Денег ради или по фану?
А чего ради все эти приседания? Через месяц верстку поменяют (а это часто случается) и все, приложуха мертва или работает коряво. Вы прям готовы каждый день проверять не «поломали» ли верстку на сайте? Раньше были сотни парсеров инсты и автопостинг и еще куча плюшек, так они жили неделю и потом разрабы неделю парсер правили под новую верстку. В итоге все это оказалось никому ненужным мусором. Парсинг на долгосроке - вещь не очень надежная.
Поэтому чел и написал, что его прибыльное приложение будет использовать правительство. Сразу же можно отмазываться, что все строго под секретом, иначе его арестуют. Хорошо придумал, молодец!
Девочка "маркетолог" не всегда принимает решения. Часто маркетологи лишь предлагают, некоторые настаивают. Но не всегда решение за ними. Но всегда балом правит выгода. Если владелец продукта уверится в правоте девочки, то беда.
Спасибо за статью эту и предыдущие! Мне очень нравится Ваш слог, пожалуйста, продолжайте :)Особенно нравится стиль перехода к выводам почти в каждом абзаце и, главное, их меткость.
Вот за это прям низкий поклон. А то меня тут уже нейросетью пару раз обозвали. Слог из "прошлой" жизни остался, как и структурирование текстов - юрист я по первому образованию. И опыт написания неимоверного объема документов из прошлого сказывается - пишу легко и быстро, мыли на бумагу удобно ложатся. Ну и выводы в каждом разделе оттуда же.
1) Оставить один стиль, не смешивая GCD и async-await: в дальнейшем в статье последний используется;
Согласен, кода надергал из разных проектов, потому и каша (не уследил). Стараюсь в статье подчеркивать, что это всего лишь примеры, но чаще забываю.
2) Не в init'е стартовать, а отдельными методами рулить старт/стоп
Ну а почему бы и да? Хороший пример, соглашусь.
3) Некритично: предлагаю упомянуть как SwiftData, так и NSPersistentContainer (если всё-таки Core), как сильно упрощающие жизнь в простых же сценариях.
чуть позже добавлю, спасибо
1) банковские приложения при протухании токена вовсе не дадут операцию "протыкать", ибо тебя уже выкинуло на экран авторизации;
2) я б UX-ово предпочёл явное а-ля "для операции (еёКороткоеОписание) необходимо авторизоваться" для первой попавшейся из очереди, а в последующих протухших также сразу обновить токен после успешной ре-авторизации
Тут можно подискутировать немного. Я сам разработчик банковского приложения (и сейчас, и ранее).
У нас сейчас два подхода к обновлению токенов:
протухший — сразу переводим пользователя на авторизацию. Тут нет вариантов что-то протыкать, юзер неизбежно должен авторизоваться снова. Ну и еще нужно не забывать, что у банковских приложение есть запросы на сервер вне авторизованного контекста - информация о продуктах (не персонифицированная), адреса, контакты и много другого. Я это к тому, что не всегда пользователя перекидывает на авторизую. Но это, опять же, редкие случаи (разработчикам проще написать общую логику "протухания" токенов, не учитывая контекст).
протухший — не трогаем юзера до момента отправки первого запроса на сервер. То есть у юзера есть возможность пройти заполнение анкеты до последнего шага и закэшировать результат его действий по вводу данных (разработчики чаще таким не заморачиваются).
В ответ на первое утверждение могу сказать, что банковские приложения разные: некоторые могут и дать юзеру возможность попользоваться функциональностью без перекидывания на экран авторизации. Ну а после авторизации можно же вернуть юзера обратно — на то место, где он остановился.
Ну а на второе утверждение — да, принято, хороший вариант. Спасибо за ваши предложения и комментарий. Думаю, многим будет полезно.
.font(.largeTitle) - это динамический шрифт. Его размер пользователь может увеличивать в настройках телефона ползунком. И, да, согласен, для динамического шрифта, хардить фрейм - плохое решение. При увеличении юзером, например до 150% от просто не влезет во фрейм. Но если шрифт задан строго 20 поинтов и его захардкоженный фрейм его вмещает, то проблем не будет.
И все мною приведенное не относится к локализованным приложениям. Этот контекст в статье не рассматривается. Но и lineLimit при локализации использовать ИМХО тоже не подходит. В одном переводе тайтл в три слова, а в другом языке - это уже может быть не одна, а две строки. Тут получим обрезание текста и троеточие.
Ну и если поделитесь инструментом, который позволяет автоматизировать локализацию на 20-30 языков, буду очень благодарен. Или все «руками» переводите?
Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Linelimit не во всех случаях поможет. И еще раз уточню, что мое предложение установить жесткий фрейм - это ситуация, где мы получаем скачки элементов из-за наличия анимаций - довольно не частая ситуация. Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Я для себя пока нашел такое решение. Предлагайте свое, я ж не претендую на единственно верное решение. И нейросети использую только для генерации картинок. Зря вы так. Даже грамматику им не даю проверять.
К сожалению функция по отслеживанию движения глаз у Apple работает еще не очень качественно, но это лишь вопрос времени. Да и разработчики не все готовы к подготовке приложений для людей с ограничениями. Это довольно много времени отнимает. Я когда впервые voice over попробовал с полностью отключенным экраном, понял насколько же несоизмеримы затраты времени разработчиков той сложности, с которой приходится сталкиваться незрячим людям. Из своих pet project приложений только два всего перевел на работу с voice over. Оно хоть и из коробки уже видит все (даже не подготовленное) приложение, но зачастую такими прилами просто невозможно пользоваться. Чего уж говорить про тех, кто не может клавой пользоваться :(
Тут работает иначе: надо сначала прочитать статью, которая написана для пользователей, которые не знают, что абсолютно слепые люди могут и должны пользоваться мобильными приложениями, а потом уже писать что-то «умное» в комментах. Но, спасибо, что обозначили свою позицию.
С какой-то из осей (не вспомню), ниже 60 программно запретили. На WWDC в одном из видео было. Не буду искать, извините, полдня займет поиск видео. Да и при современных процессорах 10 уже и добиться сложно будет.
Хорошее решение, но у нас в команде экспертиза в Kotlin была не у всех. Не знаю как сейчас с поддержкой браузерами Wasm, но на тот момент были какие-то проблемы , уже не вспомню), да и в JS компиляция работала с некоторыми ограничениями. Но и порог входа в JS существенно ниже показался для всей команды, чем в Kotlin, а времени мало, поэтому вариант был отметен. Моя б воля, именно так бы и сделал, но приходится учитывать мнение всех членов команды, а, самое главное, требования бизнеса.
Так и не бесим. В нашем приложении даже рекламы нет (пока).
MUI компоненты кастомизируются. Но код этой кастомизации часто достигает таких размеров, что чаще реально проще с нуля написать. Ну каскадные таблицы стилей же не сложные :) тут и школоте под силу
Так и наш банк тоже выпускает натив и уже не шестой, а счет уже на десятки пошел. Ну вот пример свежий https://habr.com/ru/companies/rshb/articles/1039012/
Я вот и сам не рад, что приложение в которое я получаю зп окирпичивают :) Поэтому пользуюсь уже года 4 «устаревшим» приложением одного однобуквенного банка. Ну если вам норм десятками ставить новые приложения от банка, то не все этому рады, а PWA позволяет не бесить пользователей бесконечными нативными приложениями. Ну такова уж реальность сейчас в стране. Я уж лучше PWA попользую или вэб версию. У каждого свой путь.
Ну если чуток поправили верстку, то, возможно AI и справится. Но вот попробуйте сетку натравить на инсту и она налажает как только сможет. А там разрабы стараются структуру менять довольно сильно. Я не о том, что это невозможно. Я про то, что поддерживают такую прилу будет крайне сложно и муторно, будет сжирать уйму времени. Вот и спросил автора: ради чего такие приседания? Денег ради или по фану?
А чего ради все эти приседания? Через месяц верстку поменяют (а это часто случается) и все, приложуха мертва или работает коряво. Вы прям готовы каждый день проверять не «поломали» ли верстку на сайте? Раньше были сотни парсеров инсты и автопостинг и еще куча плюшек, так они жили неделю и потом разрабы неделю парсер правили под новую верстку. В итоге все это оказалось никому ненужным мусором. Парсинг на долгосроке - вещь не очень надежная.
Поэтому чел и написал, что его прибыльное приложение будет использовать правительство. Сразу же можно отмазываться, что все строго под секретом, иначе его арестуют. Хорошо придумал, молодец!
А это точно профессиональный дизайн, как написано на 3 скрине? А то есть сомнения
Девочка "маркетолог" не всегда принимает решения. Часто маркетологи лишь предлагают, некоторые настаивают. Но не всегда решение за ними. Но всегда балом правит выгода. Если владелец продукта уверится в правоте девочки, то беда.
Опасно, до развода так не дойдет, если она пропустит скидку на ее любимые духи?
Ну в своих проектах я на это влияю (они ж мои), в рабочих отчасти. Иногда удается убедить владельца продукта не творить дичь, но не часто :)
Вот за это прям низкий поклон. А то меня тут уже нейросетью пару раз обозвали. Слог из "прошлой" жизни остался, как и структурирование текстов - юрист я по первому образованию. И опыт написания неимоверного объема документов из прошлого сказывается - пишу легко и быстро, мыли на бумагу удобно ложатся. Ну и выводы в каждом разделе оттуда же.
Согласен, кода надергал из разных проектов, потому и каша (не уследил). Стараюсь в статье подчеркивать, что это всего лишь примеры, но чаще забываю.
Ну а почему бы и да? Хороший пример, соглашусь.
чуть позже добавлю, спасибо
Тут можно подискутировать немного. Я сам разработчик банковского приложения (и сейчас, и ранее).
У нас сейчас два подхода к обновлению токенов:
протухший — сразу переводим пользователя на авторизацию. Тут нет вариантов что-то протыкать, юзер неизбежно должен авторизоваться снова. Ну и еще нужно не забывать, что у банковских приложение есть запросы на сервер вне авторизованного контекста - информация о продуктах (не персонифицированная), адреса, контакты и много другого. Я это к тому, что не всегда пользователя перекидывает на авторизую. Но это, опять же, редкие случаи (разработчикам проще написать общую логику "протухания" токенов, не учитывая контекст).
протухший — не трогаем юзера до момента отправки первого запроса на сервер. То есть у юзера есть возможность пройти заполнение анкеты до последнего шага и закэшировать результат его действий по вводу данных (разработчики чаще таким не заморачиваются).
В ответ на первое утверждение могу сказать, что банковские приложения разные: некоторые могут и дать юзеру возможность попользоваться функциональностью без перекидывания на экран авторизации. Ну а после авторизации можно же вернуть юзера обратно — на то место, где он остановился.
Ну а на второе утверждение — да, принято, хороший вариант.
Спасибо за ваши предложения и комментарий. Думаю, многим будет полезно.
.font(.largeTitle) - это динамический шрифт. Его размер пользователь может увеличивать в настройках телефона ползунком. И, да, согласен, для динамического шрифта, хардить фрейм - плохое решение. При увеличении юзером, например до 150% от просто не влезет во фрейм. Но если шрифт задан строго 20 поинтов и его захардкоженный фрейм его вмещает, то проблем не будет.
И все мною приведенное не относится к локализованным приложениям. Этот контекст в статье не рассматривается. Но и lineLimit при локализации использовать ИМХО тоже не подходит. В одном переводе тайтл в три слова, а в другом языке - это уже может быть не одна, а две строки. Тут получим обрезание текста и троеточие.
Ну и если поделитесь инструментом, который позволяет автоматизировать локализацию на 20-30 языков, буду очень благодарен. Или все «руками» переводите?
Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Linelimit не во всех случаях поможет. И еще раз уточню, что мое предложение установить жесткий фрейм - это ситуация, где мы получаем скачки элементов из-за наличия анимаций - довольно не частая ситуация. Если не использовать динамический шрифт, то работает безотказно и всегда. Linelimit затримит текст - это не всегда подходит. Если у вас текста на две строки и фрейм не задать то при изменении и пересчете фреймов других элементов на экране, получаем некрасивые скачки элемента с текстом на экране. А если у вас такой текст в ячейке списка, то получаем неимоверную красоту. Я для себя пока нашел такое решение. Предлагайте свое, я ж не претендую на единственно верное решение. И нейросети использую только для генерации картинок. Зря вы так. Даже грамматику им не даю проверять.
Виктория, спасибо за практические советы, буду брать на вооружение
К сожалению функция по отслеживанию движения глаз у Apple работает еще не очень качественно, но это лишь вопрос времени. Да и разработчики не все готовы к подготовке приложений для людей с ограничениями. Это довольно много времени отнимает. Я когда впервые voice over попробовал с полностью отключенным экраном, понял насколько же несоизмеримы затраты времени разработчиков той сложности, с которой приходится сталкиваться незрячим людям. Из своих pet project приложений только два всего перевел на работу с voice over. Оно хоть и из коробки уже видит все (даже не подготовленное) приложение, но зачастую такими прилами просто невозможно пользоваться. Чего уж говорить про тех, кто не может клавой пользоваться :(
Тут работает иначе: надо сначала прочитать статью, которая написана для пользователей, которые не знают, что абсолютно слепые люди могут и должны пользоваться мобильными приложениями, а потом уже писать что-то «умное» в комментах. Но, спасибо, что обозначили свою позицию.
С какой-то из осей (не вспомню), ниже 60 программно запретили. На WWDC в одном из видео было. Не буду искать, извините, полдня займет поиск видео. Да и при современных процессорах 10 уже и добиться сложно будет.
Да порой открываешь сайт, а там целые мультфильмы на экране из компонентов. На десктопе это бы еще и выглядело, но в мобиле оно просто не к месту.
Про slug надо было упомянуть, когда про регулярки в ендпоинтах писали