Есть необходимость использовать в одном вью сингле и дабл тэп (+ еще и пэн в нем есть). Это требование сразу меня насторожило и мне такая идея казалась кривой, но ... надо так надо.
Так вот получается нехилая задержка после первого тэпа (понятное дело, я бы мог в это время сделать второй тэп и ЮИКиту это надо проверить). Из-за этого впечатление такое, что
программа — тормоз (там визуализируются действия тэпов). Можно как-то это время подкрутить?
Of course, the code must be complete enough to compile and link.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Есть необходимость использовать в одном вью сингле и дабл тэп (+ еще и пэн в нем есть). Это требование сразу меня насторожило и мне такая идея казалась кривой, но ... надо так надо. L_L>Так вот получается нехилая задержка после первого тэпа (понятное дело, я бы мог в это время сделать второй тэп и ЮИКиту это надо проверить). Из-за этого впечатление такое, что L_L>программа — тормоз (там визуализируются действия тэпов). Можно как-то это время подкрутить?
В сафари на iOS тоже обрабатываются сингл и дабл тапы. При этом при тапе на линку особой задержки не заметно (хотя она конечно есть). С другой стороны если требуется плавность работы интерфейса, стоит подумать над другими вариантами контроллера. Например разделить тапы облаcтями применения или просто заменить дабл тап на лонг тап.
Здравствуйте, Greg Zubankov, Вы писали:
GZ>Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>>Есть необходимость использовать в одном вью сингле и дабл тэп (+ еще и пэн в нем есть). Это требование сразу меня насторожило и мне такая идея казалась кривой, но ... надо так надо. L_L>>Так вот получается нехилая задержка после первого тэпа (понятное дело, я бы мог в это время сделать второй тэп и ЮИКиту это надо проверить). Из-за этого впечатление такое, что L_L>>программа — тормоз (там визуализируются действия тэпов). Можно как-то это время подкрутить?
GZ>В сафари на iOS тоже обрабатываются сингл и дабл тапы. При этом при тапе на линку особой задержки не заметно (хотя она конечно есть). С другой стороны если требуется плавность работы интерфейса, стоит подумать над другими вариантами контроллера. Например разделить тапы облаcтями применения или просто заменить дабл тап на лонг тап.
на самом деле все, увы, еще хуже: все это в скролл-вью, в котором еще надо и дать возможность выбирать и перемещать находящиеся там объекты, но в тоже время и позволять скроллить вью. маразм какой-то.
Of course, the code must be complete enough to compile and link.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Есть необходимость использовать в одном вью сингле и дабл тэп (+ еще и пэн в нем есть). Это требование сразу меня насторожило и мне такая идея казалась кривой, но ... надо так надо. L_L>Так вот получается нехилая задержка после первого тэпа (понятное дело, я бы мог в это время сделать второй тэп и ЮИКиту это надо проверить). Из-за этого впечатление такое, что L_L>программа — тормоз (там визуализируются действия тэпов). Можно как-то это время подкрутить?
Я в своём приложении после нескольких разных попыток сделал с помощью таймера.
В методе onTouchBegan моего UIView-сабкласса я запускаю таймер (ЕСЛИ ОН НЕ ЗАПУЩЕН, если же запущен, то становится ясно, что это был второй тэп в дабл-тэпе) на достаточно короткий период (чтобы хватило отличить дабл-тэп от двух отдельных тэпа). Потом при срабатывании таймера выясняю было ли второй тэп после старта запуска таймера. Если не было, значит уже обрабатываю как одиночный тэп. Если был, то обрабатываю как дабл-тэп. И тут же останавливаю таймер, и обнуляю мембер-счётчик, который считает клики (или булеву переменную, не помню точно уже).
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Здравствуйте, Greg Zubankov, Вы писали:
GZ>>Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>>>Есть необходимость использовать в одном вью сингле и дабл тэп (+ еще и пэн в нем есть). Это требование сразу меня насторожило и мне такая идея казалась кривой, но ... надо так надо. L_L>>>Так вот получается нехилая задержка после первого тэпа (понятное дело, я бы мог в это время сделать второй тэп и ЮИКиту это надо проверить). Из-за этого впечатление такое, что L_L>>>программа — тормоз (там визуализируются действия тэпов). Можно как-то это время подкрутить?
GZ>>В сафари на iOS тоже обрабатываются сингл и дабл тапы. При этом при тапе на линку особой задержки не заметно (хотя она конечно есть). С другой стороны если требуется плавность работы интерфейса, стоит подумать над другими вариантами контроллера. Например разделить тапы облаcтями применения или просто заменить дабл тап на лонг тап.
L_L>на самом деле все, увы, еще хуже: все это в скролл-вью, в котором еще надо и дать возможность выбирать и перемещать находящиеся там объекты, но в тоже время и позволять скроллить вью. маразм какой-то.
L_L>>на самом деле все, увы, еще хуже: все это в скролл-вью, в котором еще надо и дать возможность выбирать и перемещать находящиеся там объекты, но в тоже время и позволять скроллить вью. маразм какой-то.
MM>Очень похоже на картографическое приложение...
похоже, но не оно. как быть с таким (это предложено "заказчиком"):
по сути, все что в скролл-вью нарисовано (точнее в дочернем вью, вложенном в скролл-вью) является тем или иным объектом, который можно выбрать и переместить (пэн-подобный жест).
в то же время, нужно чтобы оставалась возможность скроллить, зумить (пинч). на мой вопрос, как это пользователь будет делать и как программа должна понять, хочет ли он скроллить или
перемещать то, что внутри — предложили сделать так: "быстрый pan" — скроллим, если с задержкой выбираем объект под жестом и что-то делаем еще.
Ну и до кучи нужны сингл-дабл тэпы. Геморою, как я понимаю, будет достаточно, а вот с точки зрения юзабилити будет УНЫЛОЕ ГОВ. но что хотят, то и получат, пусть потом жрут кактусы.
Of course, the code must be complete enough to compile and link.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>по сути, все что в скролл-вью нарисовано (точнее в дочернем вью, вложенном в скролл-вью) является тем или иным объектом, который можно выбрать и переместить (пэн-подобный жест). L_L>в то же время, нужно чтобы оставалась возможность скроллить, зумить (пинч). на мой вопрос, как это пользователь будет делать и как программа должна понять, хочет ли он скроллить или L_L>перемещать то, что внутри — предложили сделать так: "быстрый pan" — скроллим, если с задержкой выбираем объект под жестом и что-то делаем еще. L_L>Ну и до кучи нужны сингл-дабл тэпы. Геморою, как я понимаю, будет достаточно, а вот с точки зрения юзабилити будет УНЫЛОЕ ГОВ. но что хотят, то и получат, пусть потом жрут кактусы.
Я бы точно остановился на своём (работающем в моём картографическом проекте) решении с таймерами (тем более речь у Вас идёт о задержке, по которой определяется выбираем ли объект или скроллим).
Думаю, что если в течении таймерного периода движение (onTouchMoved) было не далее какого-нибудь небольшого лимита, то считать, что это и есть задержка, после которой программно запретить скроллирование и переводить приложение в режим перетаскивания графического объекта.
Помню, что со скролл-вью (вернее, с его контент-окном) у меня был какой-то геммор насчёт обработки тач-событий (если их вообще возможно обрабатывать традиционным способом). Я выводил в консоль с помощью NSLog срабатывание методов onTouchBegin, onTouchMoved, onTouchEnded — и они очень часто не срабатывали в отличие от обычного UIView (который не выступает в роли контент-окна внутри UIScrollView, т.е. работает само по себе).
Вероятно, если этот геммор не удастся победить, то при переходе из режима скроллирования в режим перетаскивания будет проще поверх скролл-окна выставлять другое окно (в которое можно скопировать нужную часть картинки из скроллируемого контент-окна), в котором обрабатывать перетаскивание объектов.
MM>Помню, что со скролл-вью (вернее, с его контент-окном) у меня был какой-то геммор насчёт обработки тач-событий (если их вообще возможно обрабатывать традиционным способом). Я выводил в консоль с помощью NSLog срабатывание методов onTouchBegin, onTouchMoved, onTouchEnded — и они очень часто не срабатывали в отличие от обычного UIView (который не выступает в роли контент-окна внутри UIScrollView, т.е. работает само по себе).
MM>Вероятно, если этот геммор не удастся победить, то при переходе из режима скроллирования в режим перетаскивания будет проще поверх скролл-окна выставлять другое окно (в которое можно скопировать нужную часть картинки из скроллируемого контент-окна), в котором обрабатывать перетаскивание объектов.
а вообще обошлось малой кровью без особого траха с таймерами, низкоуровневыми эвентами и переключениями между вью. за образец берется некоторое приложение, там чтобы выбрать и перемещать объект — надо сделать тэп на нем сначала. если ничего
не выбрано или пэн начался в точке, не принадлежащей выбранному объекту — то вью скроллится, в противном случае можно перемещать объект. подобное я могу обеспечить с хит-тестом и добавлением/убиранием пэна на нужном вью.
Of course, the code must be complete enough to compile and link.
MM>Я в своём приложении после нескольких разных попыток сделал с помощью таймера. MM>В методе onTouchBegan моего UIView-сабкласса я запускаю таймер (ЕСЛИ ОН НЕ ЗАПУЩЕН, если же запущен, то становится ясно, что это был второй тэп в дабл-тэпе) на достаточно короткий период (чтобы хватило отличить дабл-тэп от двух отдельных тэпа). Потом при срабатывании таймера выясняю было ли второй тэп после старта запуска таймера. Если не было, значит уже обрабатываю как одиночный тэп. Если был, то обрабатываю как дабл-тэп. И тут же останавливаю таймер, и обнуляю мембер-счётчик, который считает клики (или булеву переменную, не помню точно уже).
как всегда (это я только недавно начал замечать, к сожалению), хороший пример нашелся в документации эппла — они там не используют таймер явно, и никакие счетчики им не нужны — они используют методы НСОбжект, которые выполняют селектор с временным интервалом.
но проблема в другом — сама идея вешать на один вью сингл и дабл тэп — УГ в моем случае. по сингл тэпу мы выбираем объекты, по дабл — масштабируем изображение. что в итоге? пользователь сделал тэп, пытаясь выбрать объект. программа С ВИДИМОЙ задержкой сделала это.
пробовал менять интервал — 0.1 секунды СИЛЬНО заметно, при этом сделать дабл тэп за 0.1 секунды — очень трудно. в итоге — какое-то унылое ГО
Of course, the code must be complete enough to compile and link.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
MM>>Помню, что со скролл-вью (вернее, с его контент-окном) у меня был какой-то геммор насчёт обработки тач-событий (если их вообще возможно обрабатывать традиционным способом). Я выводил в консоль с помощью NSLog срабатывание методов onTouchBegin, onTouchMoved, onTouchEnded — и они очень часто не срабатывали в отличие от обычного UIView (который не выступает в роли контент-окна внутри UIScrollView, т.е. работает само по себе).
MM>>Вероятно, если этот геммор не удастся победить, то при переходе из режима скроллирования в режим перетаскивания будет проще поверх скролл-окна выставлять другое окно (в которое можно скопировать нужную часть картинки из скроллируемого контент-окна), в котором обрабатывать перетаскивание объектов.
L_L>а вообще обошлось малой кровью без особого траха с таймерами, низкоуровневыми эвентами и переключениями между вью. за образец берется некоторое приложение, там чтобы выбрать и перемещать объект — надо сделать тэп на нем сначала. если ничего L_L>не выбрано или пэн начался в точке, не принадлежащей выбранному объекту — то вью скроллится, в противном случае можно перемещать объект. подобное я могу обеспечить с хит-тестом и добавлением/убиранием пэна на нужном вью.
Мне тоже такой сценарий использования больше нравится (как потенциальному потребителю)
L_L>>а вообще обошлось малой кровью без особого траха с таймерами, низкоуровневыми эвентами и переключениями между вью. за образец берется некоторое приложение, там чтобы выбрать и перемещать объект — надо сделать тэп на нем сначала. если ничего L_L>>не выбрано или пэн начался в точке, не принадлежащей выбранному объекту — то вью скроллится, в противном случае можно перемещать объект. подобное я могу обеспечить с хит-тестом и добавлением/убиранием пэна на нужном вью.
MM>Мне тоже такой сценарий использования больше нравится (как потенциальному потребителю)
пришлось таки переопределять тачесБегин и т.п. — потому как иначе ОЧЕНЬ неинтерактивно выглядит: тэп! программа подумала (или что она там делала с точки зрения пользователя ?). объект выбрался (на самом деле закончился допустимый интервал для второго тэпа).
вообще, вью перегружено получилось (( один дурацкий пэн (свайп) имеет в итоге 3 значения и неочевидно (без инструкций) когда и что произойдет (( (он может скроллить, он может перемещать выбранный ранее объект, он может (лонг пресс) и выбрать и начать перемещать объект).
Of course, the code must be complete enough to compile and link.
— они там не используют таймер явно, и никакие счетчики им не нужны — они используют методы НСОбжект, которые выполняют селектор с временным интервалом.
