Pull to refresh

Comments 12

Полноценная работа у двух приложениях будет доступна только на iPad Air 2, но наложение одного поверх другого и режим видео «картинка-в-картинке» можно будет увидеть и в более слабеньких моделях (mini, mini 2 и Air).

А допустим на The New iPad это не будет доступно, когда я обновлюсь до iOS 9?
Уверен, что после выхода джейлбрейка, один из первых твиков для 9 оси будет включение данного режима на всех планшетах. И что-то мне подсказывает, что все будет работать без каких-либо проблем, по крайней мере на mini retina и air и дело тут не в нехватке оперативной памяти, как где-то писали, а в банальном маркетинге новой модели планшета.
Это было так с iPhone 4S где все вычисления происходили не на устройстве но у iPad Air 2 в два раза больше памяти и дополнительное третье ядро.

Такие приложения как Xcom занимают почти всю память, это можно легко проверить если закрыть игру, открыть Safari и потом открыть игру заново — iOS начнет загружать игру заново. У меня у самого такое было каждый раз на iPad mini. И это совсем не экстремальный пример, очень часто нужно подсмотреть в интернет информацию про прохождению в процессе игры.

Теперь представим себе как Safari и Xcom будут работать одновременно — ответ, никак. Я уверен что игра будет перезагружаться все время или приложения постоянно будут вылетать одновременно.

Вы можете ответить — так нечего запускать такое огромное приложение в окне и это уже будет идеалистический спор. Может и на Android это прокатило где нет почти контроля над user experience, но на iOS все должно быть максимально просто и быстро.
Lightweight interaction

А есть какие-то новые API чтобы понять, что пользователь «только взглянул» и «пользователь не только взглянул, но и стал всматриваться»?
Есть отдельно выделенные куски приложения на часах — Glances, Notifications, Complications. Как правило, именно их просматривают быстро и на ходу.
А основное приложение WatchApp уже предполагает чуть более продолжительное взаимодействие.
> Для умелой работы с данными рекомендуют всегда держать в «активной» памяти только то, что приложению действительно необходимо

Мне одному кажется, что за обратное руки надо отрывать всегда, не важно, на iPad ли запущен софт, или на супер-мега-компьютере? ) Может, хоть этот подход научит иных девелоперов писать чуть аккуратнее, а то прямо обидно бывает, когда после 15 минт игры во что-то такое, простенькие по графике, корпус девайс стал заметно теплый, а батарея — не менее заметно «уменьшилась».
На сессии как раз рассказывали про системное приложение, которое отображает главное меню с иконками в iOS. Они где-то 20 минут показывали, что правильное решение для всех крайних ситуаций совсем даже не тривиальное.

Поэтому отрывать руки сразу не надо — ведь разработчиков много, а опытных и толковых мало. А надо прививать культуру и сессии такие рассказывать.)
Если не трудно, поинтересуйтесь пожалуйста у разработчиков Apple (если предоставится возможность), почему Springboard так сильно зависит от числа установленных приложений? Дольше выполняются операции по удалению приложений (переход в режим удаления), больше занято оперативной памяти — кажется что возможности для оптимизации должны быть, тем более у них. Ещё интересно как построена система QA у них, используют какие-то общедоступные сервисы/технологии или есть своё специализированное ПО? Пробовали ли они поставить на устройство 300-500 приложений и поработать с ним?
А видео с этой сессии общедоступно?
Lightweight interactions — session 805 (Apple Watch Design Tips and Tricks)

Designing for Future Hardware — session 801

Доступно в приложении WWDC.
Некоторые разработчики гонятся за кросс платформенностью в ущерб производительности. Есть и технологии и фреймворка от Apple которые позволяют писать эффективный нативный код. Мы должны донести это сообщения до разработчиков. Я стараюсь отдавать приоритет эксклюзивным приложениям.
Sign up to leave a comment.