Вот вот. Это какой то идеальный случай. Так же еще и координаторы продвигают. Для примеры: А вот еще продукт можно добавит в фейворитс, но только если вы залогинены, а если нет предложить пользователю или залогиниться или зарегистрироваться в форме из 7 экранов и потом в случае успеха, загнать на сервер и в случае успеха и обновить список продуктов с закрашенным сердечком. И все это красивое начинает потихоньку расползаться. И стоит задуматься а стоит ли вью модели знать о продукте например и/или сколько вью моделей вам нужно на представление. Почему например не по вью модели на продукт или на кнопку фейворитс отдельно, тоже представление ведь, только маленькое? По NSAttributedString тоже не ясно. Вы предлагаете сложные строки где форматировать? В мейн потоке во время отрисовки ячейки? Что б все дергалось при скроллинге? А если опять вернуть к скроллингу то часто на сложных коллекциях надо еще что то прирендерить, а может еще и UIImage через NSAttachment в NSAttributedString вставить потому что дизайнер хочет красивые кавычки или буллеты. В общем, если бы автор мне так на собеседовании рассказал что и как нужно делать в контроллере представления, я б наверное его не нанял.
Я в целом считаю что все эти координаторы хороши для пары-тройки экранов. А потом это становится недодерживаемое и тяжело модифицируемое дерево. И в конечном итоге от них больше головной боли. Все кому требуется сложная навигация и дипликнинг так или иначе в UIKit приходят к библиотекам которые основаны на проходе дерева вью контроллеров. А так как на SwiftUI навигация чаще сломана чем нет - ее тоже часто реализуют через UIKit а значит см выше. Вот такое вот наблюдение. Я сам лично считаю его анти-паттерном. Но никому не навязываю это мнение.
Даже не совсем так. WWDC сессия по управлению памятью рекомендует НЕ освобождать данные в массивах и тд потому что система использует сжатие памяти и если начать трогать объекты в массивах(и тд) даже для того что бы удалить это может привести к увеличению потребления памяти так как системе придется разжать эту область памяти. Поэтому рекомендуется на время например перестать что то кэшировать и тд и обнулить ссылки на объекты которые больше не нужны и могут быть легко восстановлены (Это относится и к структурам данных, обнулить их можно. Итерироваться что б найти например не нужные данные не стоит).
Интересная статья. Спасибо Вопрос, если под спойлером в тексте есть URL - пользователь может с ней взаимодействовать долгим нажатием или нажатем правой кнопки на тачпаде на айпаде. ПРи этом урл которая уже не под спойлером - с ней можно взаимодейстововать? Как это побороли?
Я с вами согласен. Но попробуйте написать статью на хабр и удивитесь сколько найдется граммарнаци которые выдадут вам набор запятых и расскажут вам как ужасна ваша статья из-за плохо согласованных деепричастных оборотов. Что касается нейтивспикеров - а я с ними живу каждый день - вопрос ударения для них очень важнее чем нам кажется, некорректно поставленное ударение куда важнее общей грамматики. "I'm agree" - они поймут. А вот что то вроде "pOlice" вместо "polIce" - и они вас дослушают, а потом будут друг друга переспрашивать о чем была речь.
Как я читаю это статью, я понимаю ее так, что речь идет о продолжительном процессе, не связанным на прямую с обвалом рынком и/или новичками/старичками.
Верный аргумент. Но жалобы и на существующий софт который покрывает 99% рынка, а не о мифическом еще не созданном который никто не будет покупать. А потому дискуссия имеет место
Я лично согласен с автором статьи в большинстве описанных случаев. Особенно хорошо это проиллюстрировано со стороны мобильных приложений. Рынок решает медленно и плохо. Бизнес решает быстро и просто перестал вкладываться в пользовательские (user facing) приложения/сайты (не только мобильные). Да, я знаю об исключениях, но они в только подтверждают правило. И "волочение жалкого существования" и рекламный хаос - хорошее описание происходящего. Я слышал это от программистов, я слышал это от инвесторов. "B2B проект? Вот деньги. User facing? Без физической услуги? Нет, вы провалитесь, никто не будет за это платить".
Не понимаю почему минусуют. Все верно сказано. Это какая то диагностика здоровья по фотографии. Да есть вопросы, но пока в руках не подержишь и реальный опыт не получишь все это какое то гадание.
ЗЫ: Я сам довольно скептичен относительно показанного девайса.
Вот вот. Это какой то идеальный случай. Так же еще и координаторы продвигают.
Для примеры:
А вот еще продукт можно добавит в фейворитс, но только если вы залогинены, а если нет предложить пользователю или залогиниться или зарегистрироваться в форме из 7 экранов и потом в случае успеха, загнать на сервер и в случае успеха и обновить список продуктов с закрашенным сердечком. И все это красивое начинает потихоньку расползаться. И стоит задуматься а стоит ли вью модели знать о продукте например и/или сколько вью моделей вам нужно на представление. Почему например не по вью модели на продукт или на кнопку фейворитс отдельно, тоже представление ведь, только маленькое?
По NSAttributedString тоже не ясно. Вы предлагаете сложные строки где форматировать? В мейн потоке во время отрисовки ячейки? Что б все дергалось при скроллинге?
А если опять вернуть к скроллингу то часто на сложных коллекциях надо еще что то прирендерить, а может еще и UIImage через NSAttachment в NSAttributedString вставить потому что дизайнер хочет красивые кавычки или буллеты.
В общем, если бы автор мне так на собеседовании рассказал что и как нужно делать в контроллере представления, я б наверное его не нанял.
Такое ощущение что статья написана для холивара.
Я остановился после:
Android:
рационализм
функциональность
свобода
iPhone:
мода
роскошь
качество
Я в целом считаю что все эти координаторы хороши для пары-тройки экранов. А потом это становится недодерживаемое и тяжело модифицируемое дерево. И в конечном итоге от них больше головной боли. Все кому требуется сложная навигация и дипликнинг так или иначе в UIKit приходят к библиотекам которые основаны на проходе дерева вью контроллеров. А так как на SwiftUI навигация чаще сломана чем нет - ее тоже часто реализуют через UIKit а значит см выше.
Вот такое вот наблюдение. Я сам лично считаю его анти-паттерном. Но никому не навязываю это мнение.
Слона в комнате, видимо, принято не замечать :)
Даже не совсем так. WWDC сессия по управлению памятью рекомендует НЕ освобождать данные в массивах и тд потому что система использует сжатие памяти и если начать трогать объекты в массивах(и тд) даже для того что бы удалить это может привести к увеличению потребления памяти так как системе придется разжать эту область памяти. Поэтому рекомендуется на время например перестать что то кэшировать и тд и обнулить ссылки на объекты которые больше не нужны и могут быть легко восстановлены (Это относится и к структурам данных, обнулить их можно. Итерироваться что б найти например не нужные данные не стоит).
Из-за таких вот статей ли?
На Айпаде 4го поколения вообще создается ощущение плохого слайдшоу. При этом батарею он не просто жрет - а пьет. Про эмулятор просто с языка сняли.
Интересная статья. Спасибо
Вопрос, если под спойлером в тексте есть URL - пользователь может с ней взаимодействовать долгим нажатием или нажатем правой кнопки на тачпаде на айпаде. ПРи этом урл которая уже не под спойлером - с ней можно взаимодейстововать? Как это побороли?
А вы читаете нормальным что у вам модальное окно празднуется вместе с затемненным слоем? См последний гиф.
Главное не плодить глупости и не повторять этот опыт самим когда собеседцем кого то
Что, на мой личный взгляд, показывает насколько бессмысленно задавать подобные каверзные синтаксические вопросы на собеседованиях.
При работе с keypath всегда нужно помнить об их ужасной производительности и убирать это все из накгруженного кода пока компилятор не будет поправлен. https://forums.swift.org/t/runtime-performance-cost-of-key-paths/36095/10
Я с вами согласен. Но попробуйте написать статью на хабр и удивитесь сколько найдется граммарнаци которые выдадут вам набор запятых и расскажут вам как ужасна ваша статья из-за плохо согласованных деепричастных оборотов. Что касается нейтивспикеров - а я с ними живу каждый день - вопрос ударения для них очень важнее чем нам кажется, некорректно поставленное ударение куда важнее общей грамматики. "I'm agree" - они поймут. А вот что то вроде "pOlice" вместо "polIce" - и они вас дослушают, а потом будут друг друга переспрашивать о чем была речь.
Где тут. Заголовок статьи «становится ли ПО хуже» а не «готовы ли юзеры платить за по»
Как я читаю это статью, я понимаю ее так, что речь идет о продолжительном процессе, не связанным на прямую с обвалом рынком и/или новичками/старичками.
Верный аргумент. Но жалобы и на существующий софт который покрывает 99% рынка, а не о мифическом еще не созданном который никто не будет покупать. А потому дискуссия имеет место
Я лично согласен с автором статьи в большинстве описанных случаев. Особенно хорошо это проиллюстрировано со стороны мобильных приложений. Рынок решает медленно и плохо. Бизнес решает быстро и просто перестал вкладываться в пользовательские (user facing) приложения/сайты (не только мобильные). Да, я знаю об исключениях, но они в только подтверждают правило.
И "волочение жалкого существования" и рекламный хаос - хорошее описание происходящего.
Я слышал это от программистов, я слышал это от инвесторов. "B2B проект? Вот деньги. User facing? Без физической услуги? Нет, вы провалитесь, никто не будет за это платить".
Просто поныть раз нет комментариев. Про переписанные на SwiftUI стандартные приложения. В OsX там так еще хуже.
https://twitter.com/EKazaev/status/1704532389609796081 https://twitter.com/justinxinliu/status/1715437703989191138
Не понимаю почему минусуют. Все верно сказано. Это какая то диагностика здоровья по фотографии. Да есть вопросы, но пока в руках не подержишь и реальный опыт не получишь все это какое то гадание.
ЗЫ: Я сам довольно скептичен относительно показанного девайса.
93%