«Самый простой способ достичь надежности – это, как сказали Галпин и Льюис, тестирование приложений на максимально возможном количестве устройств Android», — а-ха-ха :D Простите.
Активно продвигают Google Glass и AR, а в планшет который выпускают под своим брэндом даже камеру сзади не добавили. Такая непоследовательность удивляет, по меньшей мере.
Зашел сюда, чтобы написать то же самое. Текущая технология AR основанная на компасе/гироскопе и GPS ужасно неточна и из-за этого не пользуется большой популярностью. Уверен, что Google и Apple понимают что за AR будущее и думают над тем как улучшить технологию. Один из сейчас уже очевидных способов — комбинировать данные GPS/компаса и данные полученные за счет алгоритмов распознавания образов (зданий/улиц). А для этого нужны реалистичные 3d модели этих зданий. Зачем это встроили сейчас тоже ясно:
1. выглядит круто, пользователям нравится, соотв-но продастся больше девайсов 2. технологией будут пользоваться, следовательно будет поступать фидбек и база будет актуализироваться 3. технология уже сейчас будет приносить деньги, соотв-но инвестиции начнут окупаться раньше (перекликается с 1).
Мне кажется важны И слова (читайте отношение), И результаты. Если что-то из этого не устраивает — ищем другой банк, где устраивает. А терпеть хамское отношение за хорошие проценты — это, простите, позиция лакея.
И они себя позицонируют как один из самых новаторских и удобных банков. Фактически целятся на самую прогрессивную аудиторию. Такой банк не может возглавлять хамло. Как в принципе и любой другой, но такой — особенно.
Да вы не переживайте так :)) Это я просто к вопросу о тормозах, которых вы не заметили. Не заметили ибо не сравнивали с тем, как должно быть. И стоковые ромы тут ни при чем. Проблема в архитектуре Андроид.
На счет многопоточности: то есть на многоядерном процессоре потоки, созданные в Ruby, автоматически распараллеливаются только если версия Ruby — 1.9.х? То есть до этого все выполнялись бы на одном ядре поочередно? =/ Как-то даже странно, учитывая что язык используется для high load проектов достаточно активно.
Чуваку наверно скриншоты показали. Или на эмуляторе версию запустили. Представляю, как UI «лучше чем на iOS» будет тормозить на Андроиде… Пусть на Андроид сначала сделают скролинг обычного списка без тормозов, а потом уже думают как сделать «лучше чем на iOS» :)
«8. Постарайтесь при разработке изначально ограничить основные функции вашего приложения, и по возможности не отклоняйтесь от первоначальной идеи. Таким образом, вы сможете развить и улучшить концепцию приложения, а также его внешний вид и интерфейс, не создавая путаницы добавлением новых переменных.»
Это очень спорно, имхо. Любой, кто когда-то разрабатывал _продукт_, а не кодил по ТЗ, знает, что некоторые вещи понимаешь только в процессе раотбы и тестирования прототипа. Порой нужно несколько итераций, чтобы прийти к правильному решению. А порой эрешение вообще становится понятно только после фидбека от пользователей — это худший вариант, но тоже не смертельный. Тут правильнее сказать: «старайтесь изначально выработать правильную спецификацию/требования». Если это удастся — отлично. Если нет — _меняйте_ ТЗ в процессе работы. Кстати, примерно это указано в пункте 48, что противоречит пункту 8, имхо.
«10. Главная задача разработчиков создать потрясающий визуальный эффект»
Тоже спорно. Главная задача — сделать удобно. Визульный эффект — это хорошо, но не в ущерб юзабилити.
1. выглядит круто, пользователям нравится, соотв-но продастся больше девайсов 2. технологией будут пользоваться, следовательно будет поступать фидбек и база будет актуализироваться 3. технология уже сейчас будет приносить деньги, соотв-но инвестиции начнут окупаться раньше (перекликается с 1).
Ну то есть вы согласны, чтобы к вам обращались «лошара», если вам за это нормально заплатят? =))
thenextweb.com/apps/2012/04/03/a-detailed-side-by-side-comparison-of-instagram-for-android-and-iphone/
Это очень спорно, имхо. Любой, кто когда-то разрабатывал _продукт_, а не кодил по ТЗ, знает, что некоторые вещи понимаешь только в процессе раотбы и тестирования прототипа. Порой нужно несколько итераций, чтобы прийти к правильному решению. А порой эрешение вообще становится понятно только после фидбека от пользователей — это худший вариант, но тоже не смертельный. Тут правильнее сказать: «старайтесь изначально выработать правильную спецификацию/требования». Если это удастся — отлично. Если нет — _меняйте_ ТЗ в процессе работы. Кстати, примерно это указано в пункте 48, что противоречит пункту 8, имхо.
«10. Главная задача разработчиков создать потрясающий визуальный эффект»
Тоже спорно. Главная задача — сделать удобно. Визульный эффект — это хорошо, но не в ущерб юзабилити.