самый главный тормоз в прокрутке в Android — метод viewForItem, который возвращает следующую ячейку. Т.е. все упирается в его быстродействие — количество оберток вокруг него.
Согласен с вашим комментарием. Самое важное для разработчиков — будут ли Xamarin-приложения столь же отзывчивыми, как нативные. Флопсы здесь ни при чем.
продолжайте, пожалуйста, очень полезная статья! Я уже много лет интуитивно понимаю вещи, связанные со сложностью алгоритмов, но прочитать теорию, настолько доступно написанну — всегда только на пользу.
Ну как недавно, у меня 12 лет назад появился монитор, который держал 100 герц. Учитывая мой возраст, это почти полжизни назад :) Для вас, наверное, не так много времени прошло. По крайней мере, после института годы стали лететь намного быстрее по субъективным ощущениям.
По поводу мерцания — да, был такой эффект на всех мониторах с частотой развертки меньше 80 герц. Помню, много лет провел в синих с жетлым цветах Norton Commander, а потом поставил Win 3.11 — глаза сразу же стали уставать в 5 раз больше, даже на минимальной яркости.
Не, никак не 50-70%%. Кроме чего-то универсального, есть 80% кода, который завязан на конкретное приложение и имеет смысл только в контексте его. Возможно, сказывается долгая продуктовая разработка — когда работал на аутсорсинге, процентов соответственно было больше.
Ну и тут есть обратная сторона медали. Знал одного программиста, который долго работал замкнутый сам в себе, уж очень интровертный человек. Добавили его к нам на проект, к тому моменту уже шедший 1.5 года и в различное время писанный 3-4 девелоперами. Вместе с ним прилетело штук 50 файлов с префиксом от его имени-фамилии, большинство функциональности в которых дублировало уже имеющуюся. В общем, в команде стараюсь пользоваться вмес стандартным, и как можно меньше самописности — особенно в iOS, где стандартные библиотеки вполне неплохи.
ПО и есть на сегодняшний момент главный камень преткновения робототехники. Как сказал кто-то из великих, не могу нагуглить цитату, «первый год работы над роботом процесс идет чудесно — ты рассчитываешь передачи, сервомоторы и цепь питания. Но потом наступает провал».
Так что желаю им допилить SDK. И придумать некий самообучающийся алгоритм, чтоб Romo становился умнее, поиграв с каким-нибудь ребенком.
Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы.
В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.
В общем, в любом случае размер кода растет пропорционально количеству связанных между собой элементов, видимых единовременно на экране. Конечно, если нужно показывать, скажем, прогноз погоды и новости — можно смело делить их в совершенно разные контроллеры.
Сториборды можно использовать, не надо только там создавать ячейки и лепить много контролов прямо на вьюху контроллера — замучаешься переносить на айпад и обратно.
И все же, повторюсь, основной посыл статьи таков: Apple может потратить часть ресурсов и допилить IB до более законченного состояния. В 2009 я программил под мак и под iPhone OS — под мак создавать интерфейс в IB было раем, он был очень похож на рантаймовые вьюшки. Под iOS — как было занятие ниже среднего, таким оно и осталось.
Все правильно автор говорит. Великий опыт хорошего разработчика и состоит с том, чтобы не лепить горы абстракций там, где не надо, и четко знать, где можно «сговнокодить».
Например, обучая джуниора основам С, нельзя ему даже рассказывать про оператор goto. Опытный же программист знает, как его правильно применить при, скажем, выходе из циклов большой вложенности. Точно также, иногда можно и сговнокодить, если ты хорошо понимаешь что ты делаешь, и если это не скажется на архитектуре всей системы в целом.
Просмотрел API, либа вроде неплохая. Но не убирает один косяк — если приходится периодически копаться в чужом коде, поддерживать что-то, все равно придется иметь дело со стандартными средствами. Так что стандартные пути все же предпочтительнее.
Имхо, после Порше NFS-ы что-то безвозвратно потеряли. Было прикольно погонять и в HP2, и в Underground… но все равно не то, нет той атмосферы. И, на мой взгляд, трассы намного лучше были, чем один и тот же город, перекрытый в разных местах.
Один хитрый трюк, скорее похожий на хак, вы выучили и обвиняете меня в кривости рук — да, вы большой молодец. Это, безусловно, позволяет вам утверждать что я верстаю 800-строчную простыню.
Ну и тут есть обратная сторона медали. Знал одного программиста, который долго работал замкнутый сам в себе, уж очень интровертный человек. Добавили его к нам на проект, к тому моменту уже шедший 1.5 года и в различное время писанный 3-4 девелоперами. Вместе с ним прилетело штук 50 файлов с префиксом от его имени-фамилии, большинство функциональности в которых дублировало уже имеющуюся. В общем, в команде стараюсь пользоваться вмес стандартным, и как можно меньше самописности — особенно в iOS, где стандартные библиотеки вполне неплохи.
Так что желаю им допилить SDK. И придумать некий самообучающийся алгоритм, чтоб Romo становился умнее, поиграв с каким-нибудь ребенком.
В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.
В общем, в любом случае размер кода растет пропорционально количеству связанных между собой элементов, видимых единовременно на экране. Конечно, если нужно показывать, скажем, прогноз погоды и новости — можно смело делить их в совершенно разные контроллеры.
Сториборды можно использовать, не надо только там создавать ячейки и лепить много контролов прямо на вьюху контроллера — замучаешься переносить на айпад и обратно.
И все же, повторюсь, основной посыл статьи таков: Apple может потратить часть ресурсов и допилить IB до более законченного состояния. В 2009 я программил под мак и под iPhone OS — под мак создавать интерфейс в IB было раем, он был очень похож на рантаймовые вьюшки. Под iOS — как было занятие ниже среднего, таким оно и осталось.
Например, обучая джуниора основам С, нельзя ему даже рассказывать про оператор goto. Опытный же программист знает, как его правильно применить при, скажем, выходе из циклов большой вложенности. Точно также, иногда можно и сговнокодить, если ты хорошо понимаешь что ты делаешь, и если это не скажется на архитектуре всей системы в целом.