Тут есть drawback в виде быстродействия. Я бы не стал так заморачиваться, потому как выигрыша это никакого не дает. Да, разделено, идеологически красиво. А смысл? Вход в код не облегчает, масштабирование только усложняет. Хоть на первый взгляд так и кашернее, но на деле — нет.
Разная ширина с разными шрифтами — это разные ячейки. Если это одна сущность, то делается массив UI компонентов модели, где у каждой есть критерий применения.
Как более простой для управления вариант — это на индивидуальные экраны создать отдельный инстанс базы.
Так как обычно обычно вычисляемые данные хранятся вместе с моделью, то фетчинг пары полей UI-ных вообще несущественен. Да даже если разделять, то все равно мелочь.
Представьте, что вам нужно посчитать высоту текста. Вы для этого создаете атрибутивную строку, что уже не мало так, считаете ее размер через CoreText/TextKit/UIKit, что вообще ахтунг, потому как работа с текстом на CPU в iOS — одна из тяжелейших операций. И делаете это на каждую ячейку, каждый раз, когда дергается heightForRow. Считайте сами.
Модель и хранилище — разные вещи, пусть и тесно связанные обычно. Мы не заморачиваемся разделением данных модели и данных UI, потому что они в любом случае будут вместе использоваться. Но если принципиально иметь разделенную модель и UI, то можно сделать отдельный инстанс базы для UI компонентов и оттуда уже запрашивать инфу.
Разницы нет. Станет уже — значит это будет учтено в расчетах. А если вы имеете в виду, что делать, если уже есть посчитанные размеры из прошлой версии, то варианта два:
Достаточно считать все пропорционально экрану. А так как ваш iPhone 5 внезапно не превратится в X, то вычисленные значения будут актуальны между использованиями.
Если ваше приложение поддерживает ротацию, то сохраняйте два комплекта значений.
С точки зрения БД это можно организовать как угодно: сразу записывать в модель или сделать массив вспомогательных сущностей, которые дополнительно хранят информацию о критерии их применения, определяя в рантайме задействованный объект.
Разумеется, если приложение крайне динамическое, туда-сюда растягивается, то пред-расчет сделать сложнее или вообще не нужно. Так или иначе, каждая задача уникальна, и перед использованием того или иного подхода стоит проанализировать ситуацию.
В базе хранятся height, тип ячейки, нужные поля пред-обработанные. В общем, все что требуется для корректного отображения. Ширину можно не сохранять, если она фиксированная (кэп).
Даже без обновления это полезно, потому что меньше нагружается главный поток при скроллинге. Кроме банального быстродействия и экономии энергии, у вас появляется возможность накосячить с главным потоком где-нибудь в другом месте без последствий. Звучит немного странно, но на деле это ощутимо экономит время разработчика и снижает порог скилла для плавного интерфейса.
Забыл упомянуть еще один плюс пред-расчета высоты: экономия батарейки. Чем меньше вычислений происходит в хаотичном порядке (а тем более с высочайшим приоритетом), тем лучше.
Да, Youtube еще обожает забывать, что есть экраны меньше, чем XXL. Попробуйте открыть его на iPhone 5/5S/SE. Половина кнопок выпадает за пределы экрана.
Может быть я один такой, но это все ошибки джуниора с опытом полгода. Как можно делать такое, когда ты топовый хостер видео на планете.
Яндекс-маркет
Часто зависают экраны, при этом имея блокирующие загрузчики. То есть, нельзя уйти, нет pull-to-refresh, экраны грузятся целиком или вообще никак. И сидишь такой и надеешься, что в этот раз ты увидишь страничку.
Много багов: выбираешь несколько фильтров, а у тебя экран вправо уезжает в бесконечность. Как так. И это еще не говорю про всякую неотзывчивость интерфейса, забытые human interface guidelines, когда все приложение — одна большая самодеятельность.
Фейсбук
300 мб приложение. Просто — выход там. Про лаги и говорить нечего. Ощущение, что у тебя не iPhone 7, а 4s. Кто смотрел разбор классов фейсбука, знает какая там помойка. Куча мертвого функционала, который даже вырезать поленились.
Youtube
Крайне толстый и неповоротливый. Главное правило Apple — это отзывчивость интерфейса. Когда ты в любой момент можешь переместиться назад или отменить свое действие. Но нет, ютуб крепко держит тебя за яйца, при этом отсасывая батарейку.
Рекомендую перед собеседованием сказать об этом и предложить альтернативу. Например, тестовое задание. Да, съест время, но зато исключает квесты на собеседованиях.
Есть теория, что особо крутые руководители и бизнесмены, уставшие от лобызания окружающими их пяточек и явного доминирования со своей стороны, стремятся быть сабмиссив в любви неосознанно (о боже, термин из 50 оттенок серого, извините).
По знакомству, как правило. Или обратиться к компаниям, которые профессионально занимаются разработкой, чтобы они ассистировали в найме. Но это дороже.
Ключевая мысль заключается в другом. Что такой подход дает к тому же ложно-положительные. И дает их слишком часто, судя по результатам работы таких компаний.
Хочу сказать, что ничего, кроме стандартной 'findSubstringInString', в голову не приходит и не должно.
Кстати, недавно с вами(яндексом) общался ради интереса. Был в таком шоке, что пошел писать эту статью.
Итак, собеседование в яндексе это:
Когда вас игнорирует HR по несколько дней.
Когда на собеседование с вами никто не приходит. А в качестве извинений дают промо код на лапшу.
Когда CTO проекта говорит, что тех. собеседования у вас бесполезные и он не видит в них смысла, но ничего не может с этим поделать.
Когда на добровольное предложение сделать реальное живое тестовое задание объемом в пару рабочих дней(!!!) HR кидает ссылку на сборник математических задач с просьбой подготовиться.
Пусть вывод за меня сделает утка:
P.S. До тех. собеседования дело не дошло после этого.
Мне на практике не попадалось, что специалист последовательно описывает шаги решения различных ситуаций, но не может их воплотить на деле.
Если все настолько сомнительно, то можно узнать о предыдущего работодателя впечатление, например. В конце концов, если он опытный и работал больше, чем по месяцу в каждом месте, то значит руки есть.
В совокупности внятное и уверенное решение задач, рекомендации с прошлого места работы и хороший послужной список дает высокую вероятность профессионализма. И испытательный срок никто не отменял, если все же будет осечка.
Как более простой для управления вариант — это на индивидуальные экраны создать отдельный инстанс базы.
Представьте, что вам нужно посчитать высоту текста. Вы для этого создаете атрибутивную строку, что уже не мало так, считаете ее размер через CoreText/TextKit/UIKit, что вообще ахтунг, потому как работа с текстом на CPU в iOS — одна из тяжелейших операций. И делаете это на каждую ячейку, каждый раз, когда дергается heightForRow. Считайте сами.
А дальше как сами сочтете нужным.
Достаточно считать все пропорционально экрану. А так как ваш iPhone 5 внезапно не превратится в X, то вычисленные значения будут актуальны между использованиями.
Если ваше приложение поддерживает ротацию, то сохраняйте два комплекта значений.
С точки зрения БД это можно организовать как угодно: сразу записывать в модель или сделать массив вспомогательных сущностей, которые дополнительно хранят информацию о критерии их применения, определяя в рантайме задействованный объект.
Разумеется, если приложение крайне динамическое, туда-сюда растягивается, то пред-расчет сделать сложнее или вообще не нужно. Так или иначе, каждая задача уникальна, и перед использованием того или иного подхода стоит проанализировать ситуацию.
В базе хранятся height, тип ячейки, нужные поля пред-обработанные. В общем, все что требуется для корректного отображения. Ширину можно не сохранять, если она фиксированная (кэп).
Даже без обновления это полезно, потому что меньше нагружается главный поток при скроллинге. Кроме банального быстродействия и экономии энергии, у вас появляется возможность накосячить с главным потоком где-нибудь в другом месте без последствий. Звучит немного странно, но на деле это ощутимо экономит время разработчика и снижает порог скилла для плавного интерфейса.
Забыл упомянуть еще один плюс пред-расчета высоты: экономия батарейки. Чем меньше вычислений происходит в хаотичном порядке (а тем более с высочайшим приоритетом), тем лучше.
Да, Youtube еще обожает забывать, что есть экраны меньше, чем XXL. Попробуйте открыть его на iPhone 5/5S/SE. Половина кнопок выпадает за пределы экрана.
Может быть я один такой, но это все ошибки джуниора с опытом полгода. Как можно делать такое, когда ты топовый хостер видео на планете.
Разберу только парочку.
Яндекс-маркет
Часто зависают экраны, при этом имея блокирующие загрузчики. То есть, нельзя уйти, нет pull-to-refresh, экраны грузятся целиком или вообще никак. И сидишь такой и надеешься, что в этот раз ты увидишь страничку.
Много багов: выбираешь несколько фильтров, а у тебя экран вправо уезжает в бесконечность. Как так. И это еще не говорю про всякую неотзывчивость интерфейса, забытые human interface guidelines, когда все приложение — одна большая самодеятельность.
Фейсбук
300 мб приложение. Просто — выход там. Про лаги и говорить нечего. Ощущение, что у тебя не iPhone 7, а 4s. Кто смотрел разбор классов фейсбука, знает какая там помойка. Куча мертвого функционала, который даже вырезать поленились.
Youtube
Крайне толстый и неповоротливый. Главное правило Apple — это отзывчивость интерфейса. Когда ты в любой момент можешь переместиться назад или отменить свое действие. Но нет, ютуб крепко держит тебя за яйца, при этом отсасывая батарейку.
Эти продукты упомянуты в статье.
Рекомендую перед собеседованием сказать об этом и предложить альтернативу. Например, тестовое задание. Да, съест время, но зато исключает квесты на собеседованиях.
Я вам даже немного завидую. Гораздо лучше иметь пару проектов приносящих деньги, чем много статей)
Есть теория, что особо крутые руководители и бизнесмены, уставшие от лобызания окружающими их пяточек и явного доминирования со своей стороны, стремятся быть сабмиссив в любви неосознанно (о боже, термин из 50 оттенок серого, извините).
Замкнутый круг нарисовался)
По знакомству, как правило. Или обратиться к компаниям, которые профессионально занимаются разработкой, чтобы они ассистировали в найме. Но это дороже.
Ключевая мысль заключается в другом. Что такой подход дает к тому же ложно-положительные. И дает их слишком часто, судя по результатам работы таких компаний.
Спасибо за последовательный ответ на мой токсичный комментарий)
Хочу сказать, что ничего, кроме стандартной 'findSubstringInString', в голову не приходит и не должно.
Кстати, недавно с вами(яндексом) общался ради интереса. Был в таком шоке, что пошел писать эту статью.
Итак, собеседование в яндексе это:
Пусть вывод за меня сделает утка:
P.S. До тех. собеседования дело не дошло после этого.
Под пытками и землю плоской называют.
Такой вопрос устно только плохие люди задают)
Зависит от платформы. Но я писал на эту тему статью, которая касается задач для iOS разработчика.
Конечно. Тогда они отсеются уже на устных задачах, если опыта не набрались.
Мне на практике не попадалось, что специалист последовательно описывает шаги решения различных ситуаций, но не может их воплотить на деле.
Если все настолько сомнительно, то можно узнать о предыдущего работодателя впечатление, например. В конце концов, если он опытный и работал больше, чем по месяцу в каждом месте, то значит руки есть.
В совокупности внятное и уверенное решение задач, рекомендации с прошлого места работы и хороший послужной список дает высокую вероятность профессионализма. И испытательный срок никто не отменял, если все же будет осечка.