Ti.UI.iPad.SplitWindow обновлять макет или скрывать / показывать детали. - PullRequest
1 голос
/ 24 июня 2011

При использовании Ti.UI.iPad.SplitWindow , каков наилучший (наиболее чистый) способ обновления detailView?

Варианты, которые я могу придумать, - это изменение положения элементов в событии detailView или show()/hide() против open()/close() в событии orientationchange. Я знаю, что использование собственных компонентов пользовательского интерфейса на iPad должно динамически обновляться до ширины / высоты макета iPad, но в моем случае контент на каждом detailView будет иметь свои дочерние объекты, обновленные на orientationchange. Я просто пытаюсь получить максимальную отдачу от всего вашего опыта. Даже если мне придется создавать собственные анимации, я просто хочу начать это правильно с самого начала, чтобы пока не было никакого текущего кода. Таким образом, ни один не включен.

Я надеюсь, что это не дубликат, поскольку я искал до того, как спрашиваю, но по этой теме нет вопросов на основе Titanium, которые я могу найти. Возможно , но все равно отличается от того, что я спрашиваю.

1 Ответ

2 голосов
/ 10 августа 2011

Самый плавный опыт будет получен при изменении наименьшего. Я не знаю, какую анимацию вы представляете, но я бы подтолкнул вас к простоте.

Вот краткий пример изменения ориентации в приложении для iPad, которое я недавно создал. У меня было несколько изображений с макетом: «горизонтальный». Из-за приятной ошибки изображения автоматически переносятся. Когда пользователь переориентировал устройство, я анимировал ширину представления, и изображения автоматически и анимировались сами.

У меня также было несколько клиентов в крупной корпорации, которые настраивали свои сердца на действительно сложные изменения макета всякий раз, когда пользователь переориентировал устройство. Это привело к действительно неудовлетворительному приложению, которое переориентировалось за 10-20 секунд. Мы внесли много оптимизаций и много улучшений как в их код, так и в базовую инфраструктуру, но суть проблемы заключалась в сложном дизайне.

Потратьте время, чтобы подумать, действительно ли вам нужны сложные изменения каждый раз, когда пользователь переориентируется, и какую выгоду вы предлагаете своим пользователям. Также учитывайте стоимость предоставления пользователю (а не только устройству) нового пользовательского интерфейса.

В прошлом вы, вероятно, не получите слишком много ответов, пока не проведете некоторые эксперименты с этим. Если вы вернетесь с каким-то кодом и несколькими вопросами для его решения, я могу переформулировать свой ответ, чтобы лучше определить вашу ситуацию.

Надеюсь, это поможет! -Dawson

...