Имеет ли смысл возвращать 200-й с поясняющим сообщением, если этот трафик мы считаем некашерным? Тогда браузеры не будут переспрашивать.
Мне видится проблема в том, что 4XX-й код — это ошибка клиента, а повторно задать запрос в таком случае — это адекватное поведение (в большинстве вариантов). По ходу, надо вводить код 'Отстань' с принципиально отличающимся номером.
А я точно хабр все еще читаю? Почему пост на 5 строк без какой-либо интересной или полезной информации не утонул сразу же? Как давно технологический новостной портал превратился в личный форум телеграмщиков? Модераторы, что происходит?
У меня один единственный счет. Каждый раз при попытке вывести на него деньги я вынужден совершать по куче кликов, чтобы его выбрать. Зачем? Он у меня один. И таких моментов, которые надо бы делать выбранными по умолчанию, довольно много.
Да просто стандартное действие с манипуляциями между своими счетами требуют какого-то дикого погружения.
(Единственное место, где сделано адекватно — пополнение телефона)
Поехавшая верстка на маленьких экранах ну просто везде, где только можно. Просто авторизовываешься и даже акция про Кемерово уже едет так, что в кнопку не попасть.
При переходе в приложения в диспетчер задач оно не блюрится. Секьюрити, вы вообще о чем. Но ладно, это мелочи. Тем не менее, у всех ваших конкурентов это есть и штука нужная.
На экране просмотра счета пытаешься скроллить, а тебя настойчиво пихает на открытие нового вклада. Как это вообще связано — конкретный счет и новый вклад? И почему это настолько ломает взаимодействие, если скроллишь ну хоть чуточку выше середины экрана?
А даже если не скроллишь, пол экрана занято бесполезной фигней.
Жест назад не работаешь практически везде. Захожу на инфу о счете — назад не вернуться. Бомбануло в просмотре конкретного перевода: скроллишь вниз, пропадает кнопка назад. Жест не работает при этом. Юзабилити — топ.
Блокирующие загрузчики просто везде. 21-й век на дворе, а решения как в iOS 4. Особенно приятно, когда сидишь с медленным интернетом и тебя вынуждают смотреть на крутилочку, когда ты уже передумал десять раз.
Про то, что половина приложения лагает, интерфейс скачет (диалоги, выписки) и сосет батарейку — даже говорить не буду.
… а еще иметь возможность указать основную карту, чтобы без 'к этому пользователю привязано несколько карт, поэтому идите нафиг со своим переводом'.
На правах токсичного комментария — каждый раз так раздражает, когда компания с наглухо убитым юзабилити пишет вот такие статьи.
Порог допустимой производительности везде разный. Где-то даже один потерянный кадр бросится в глаза, а бывает, что и 30 фпс всех устраивает. Это нормальный сценарий, целиком зависящий от ключевой аудитории и бизнес модели.
Но если мы обсуждаем идеальную производительность без швов, когда приложение в любой момент времени выдает 60 фпс, то нужно проводить более объективный и структурированный анализ.
Что это значит? Когда речь заходит о лагах, каждый полагается на свое субъективное восприятие производительности. Если мы хотим убедиться, что приложение действительно способно выдерживать нагрузку, то следует подойти более научно к процессу:
Ввести критерий 'лага'. Им является потеря кадра. Если нет возможности замерить объективно фпс, то альтернативной шкалой может являться нагрузка на главный поток: когда в некий момент времени она приближается к 100% (от 90% и выше). Это альтернативный критерий. Замечу, что нагрузка может вызвана не только вычислениями и графикой, а так же блокировкой и ожиданием.
Определить пользовательские сценарии. Как правило, принятой формой проверки служит скроллинг в динамических коллекциях, имеющих постраничную загрузку (которая на швах не должна вызывать пробуксовывания) и динамический контент в ячейках (изображения или что-то требующее дополнительной подгрузки после появления).
Темп скроллинга должен быть замерен в нескольких ритмах:
Плавный. Когда за один жест контент смещается не более, чем на экран. Естественно, при проведении жеста нужно отпускать экран для инерционного перемещения.
Резкий. Например, несколько жестов подряд, когда данные смещаются на несколько экранов.
Ищущий. Максимальная возможная скорость перемещения, можно без остановки. Такой сценарий случается, когда пользователь что-то пытается найти в контенте.
Каждый сценарий должен быть проведен на разных устройствах: нельзя замерять производительность только на десятом айфоне, например. Если во всех случаях приложение уверенно показывает 60 фпс и/или отсутствие предельной нагрузки на главный поток, а так же визуально движение ощущается плавным, то можно считать стресс-тест пройденным.
Последовательный анализ исключает все заявления типа: 'У меня аутолейат никогда не лагает, что я делаю не так'
Раз уж тред медленно превратился в кулинарный форум, то может кто-нибудь подскажет: готовил пахлаву, но тесто получилось такое, как будто стекло жуешь.
Где я накосячил? Как сделать так, чтобы есть сладкое без крови? А то не кошерно, все таки.
Autolayout не всегда достаточно производителен, особенно на сложных коллекциях и слабых устройствах. Поэтому приходится все делать ручками. Иногда достаточно снять с него ответственность за высоту, а иногда и целиком возвращаться к истокам с версткой на фреймах.
На правах борца за истину — автоматический подсчет высот не всегда плох. Зависит от сложности ячейки и ее статичности.
Стоит всегда начинать с самого простого варианта, а усложнять по мере нарастания необходимости в оптимизации. Проще говоря, преждевременная оптимизация — это такое же зло, как и отсутствие оптимизации вовсе.
Материала такого не видел. Возможно, позже напишу.
Самый простой вариант — считаете высоту в момент получения данных о модели и сохраняете вместе с ней.
Если что-то изменилось, то перерасчет в любом случае понадобится. В случае с Accessibility надо на уведомление всего лишь подписать, где и дергать нужный рычажок.
Говоря о сложном интерфейсе, то чем интереснее правила для лайаута, тем сильнее виден импакт на производительности. Это первый кандидат на автоматизацию.
У меня как-то был случай, когда ячейка и размер зависел от соседних ячеек. Сценарий распространялся на ситуацию, когда при удалении ячейки мог изменяться размер соседних. Уверен, вы представляете себе глубину норы. Все решилось тем же вызовом одной функции для перерасчета в нужный момент.
Хочу добавить, что у меня нет цели форсировать такое решение. Если вы считаете, что к вам это неприменимо — пожалуйста. Но я должен сказать, что оно имеет положительное влияние на скорость работы, а подавляющее большинство трудностей с ним несложно решаются.
Имеет ли смысл возвращать 200-й с поясняющим сообщением, если этот трафик мы считаем некашерным? Тогда браузеры не будут переспрашивать.
Мне видится проблема в том, что 4XX-й код — это ошибка клиента, а повторно задать запрос в таком случае — это адекватное поведение (в большинстве вариантов). По ходу, надо вводить код 'Отстань' с принципиально отличающимся номером.
Ох уж эти теории заговора!
Можно написать, провести исследование, показать эффективность. А не 'Может поможет', это что за подход такой. Формат бложика какой-то.
А я точно хабр все еще читаю? Почему пост на 5 строк без какой-либо интересной или полезной информации не утонул сразу же? Как давно технологический новостной портал превратился в личный форум телеграмщиков? Модераторы, что происходит?
Когда твой прокси до сих пор не заблокировали:
18.197.0.0 — запишите к павшим
Если этого мало, тогда поехали:
Да просто стандартное действие с манипуляциями между своими счетами требуют какого-то дикого погружения.
(Единственное место, где сделано адекватно — пополнение телефона)
А даже если не скроллишь, пол экрана занято бесполезной фигней.
Про то, что половина приложения лагает, интерфейс скачет (диалоги, выписки) и сосет батарейку — даже говорить не буду.
Достаточно конструктивно?
… а еще иметь возможность указать основную карту, чтобы без 'к этому пользователю привязано несколько карт, поэтому идите нафиг со своим переводом'.
На правах токсичного комментария — каждый раз так раздражает, когда компания с наглухо убитым юзабилити пишет вот такие статьи.
Порог допустимой производительности везде разный. Где-то даже один потерянный кадр бросится в глаза, а бывает, что и 30 фпс всех устраивает. Это нормальный сценарий, целиком зависящий от ключевой аудитории и бизнес модели.
Но если мы обсуждаем идеальную производительность без швов, когда приложение в любой момент времени выдает 60 фпс, то нужно проводить более объективный и структурированный анализ.
Что это значит? Когда речь заходит о лагах, каждый полагается на свое субъективное восприятие производительности. Если мы хотим убедиться, что приложение действительно способно выдерживать нагрузку, то следует подойти более научно к процессу:
Темп скроллинга должен быть замерен в нескольких ритмах:
Каждый сценарий должен быть проведен на разных устройствах: нельзя замерять производительность только на десятом айфоне, например. Если во всех случаях приложение уверенно показывает 60 фпс и/или отсутствие предельной нагрузки на главный поток, а так же визуально движение ощущается плавным, то можно считать стресс-тест пройденным.
Последовательный анализ исключает все заявления типа: 'У меня аутолейат никогда не лагает, что я делаю не так'
По ходу, пора вторую статью писать, а то эта уже лагает.
Раз уж тред медленно превратился в кулинарный форум, то может кто-нибудь подскажет: готовил пахлаву, но тесто получилось такое, как будто стекло жуешь.
Где я накосячил? Как сделать так, чтобы есть сладкое без крови? А то не кошерно, все таки.
Autolayout не всегда достаточно производителен, особенно на сложных коллекциях и слабых устройствах. Поэтому приходится все делать ручками. Иногда достаточно снять с него ответственность за высоту, а иногда и целиком возвращаться к истокам с версткой на фреймах.
На правах борца за истину — автоматический подсчет высот не всегда плох. Зависит от сложности ячейки и ее статичности.
Стоит всегда начинать с самого простого варианта, а усложнять по мере нарастания необходимости в оптимизации. Проще говоря, преждевременная оптимизация — это такое же зло, как и отсутствие оптимизации вовсе.
Материала такого не видел. Возможно, позже напишу.
Самый простой вариант — считаете высоту в момент получения данных о модели и сохраняете вместе с ней.
Если что-то изменилось, то перерасчет в любом случае понадобится. В случае с Accessibility надо на уведомление всего лишь подписать, где и дергать нужный рычажок.
Говоря о сложном интерфейсе, то чем интереснее правила для лайаута, тем сильнее виден импакт на производительности. Это первый кандидат на автоматизацию.
У меня как-то был случай, когда ячейка и размер зависел от соседних ячеек. Сценарий распространялся на ситуацию, когда при удалении ячейки мог изменяться размер соседних. Уверен, вы представляете себе глубину норы. Все решилось тем же вызовом одной функции для перерасчета в нужный момент.
Хочу добавить, что у меня нет цели форсировать такое решение. Если вы считаете, что к вам это неприменимо — пожалуйста. Но я должен сказать, что оно имеет положительное влияние на скорость работы, а подавляющее большинство трудностей с ним несложно решаются.
Это мой практический опыт.
Технари, а не разработчики. Тогда они могли вообще его без AI запустить кататься по вашей логике, тоже успех ведь. Лишь бы продали проект, кому нужно.
Сейчас наброшу на вентилятор: AI автомобиль Uber сбил человека, зато прибыли много. Технари тоже все правильно там сделали?)
Вот я помню школьный паскаль. И зачем это мне?)
Намеренно исследовать что-то ради статьи — это уже маньячество какое-то. А публикация ради публикации смысла особо не несет.
Давайте меняться :D