Честно — тяжело себе представить. На PS3 в магазине реализован поиск по буквам, очень похоже на то, что вы описали. Но мне кажется это все равно неудобно. В любом случае я сомневаюсь что этой крутилкой можно пользоваться во время вождения.
Да на моей Toyot'e тоже невозможно пролистать карту, раза с пятого, все остальные попытки он ставит маркер в произвольной точке пути перетаскивания. Я даже в Toyota написал, на что они ответили, что постоянно модернизируют технологии и все такое, покупайте новые машины.
Странно, у меня уже два года встроен первый айпэд в машине, выдержал две зимы, прошлая была более жесткая. Но особых проблем не испытывал. Одна проблема — батарейка сдохла от таких перепадов, что в принципе логично.
ну не стоит судить сильно строго, это «первые птички» и я их очень уважаю за смелы попытки. Хотя лично я тоже считаю что это перебор и интерфейс достаточно топорный.
Про залапанные экраны думаю проблема надуманная. Матовый (очень слегка) экран эту проблему легко устраняет, это я по тачу в моей машине могу судить.
По поводу отвлечения — тяжело себе представить полноценную навигацию на кнопках, чтоб это не отвлекало от вождения. Снять трубку, переключить трэк и станцию — это все можно сделать управлением на руле. Все остальное лучше реализовать на таче. Да и вообще тач не предусмотрен для того, чтоб им пользоваться во время движения — об этом он каждый раз напоминает при включении.
Плюс есть голосовое управление, работает оно уже сносно — позвонить определенному абоненту вполне можно, но до гугловского и эппловского распознования ему еще далеко.
Самые смелые в этом плане оказались электромобили от Tesla и я думаю в этом направлении постепенно будут двигаться все остальные:
меня вот удивляет те решения, которые встроены в машины. У меня дорогучая высокотехнологичная машина передового производителя: Toyota Highlander Hybrid, а компьютер начала двухтысячных годов:
— очень плохой экран, который засвечивается при ярком свете и большой пикселизацией
— ужасный резистивный тачскрин
— нереально корявая навигация, ехать по ней вообще нереально (дороги и маршрут нечитабельные, поиск по адресу занимает минут 5 )
— графика начала двухстысячных
— анимация на уровне 90-х
— юзабилити вообще отсуствует как класс
Вставляется эта штука как опция и стоит эта опция $2000!!! И от этого модуля вообще не зависит функциональная часть машины, так как это опция, так что особых требований к надежности и отказоустойчивости вообще нет. Для меня большая загадка почему такой консерватизм в этой части автомибелестроения.
Передовыми в этом плане являются Ситроен и Пэжо, но и их системы вызывают кучу нареканий.
virtual frame buffer — это тулза для отладки на обычной машине — она эмулирует фреймбуфер поверх иксов или винды или макоси. Фрймбуфер внутри операционки. А сам QWS работает напрямую с железом, для этого нужно и писать плагины.
Qt4 и даже Qt4 embedded работают без X-сервера. Там есть QWS, очень урезанный оконный менеджер с самым базовым функционалом. Он может работать как поверх иксов так поверх и любого другого плагина, например фреймбуфера или даже VNC из коробки.
Хорошая площадка для старта и создания своего кастомного решения. Только два вопроса возникают пока:
— насколько активно это будет развиваться
— под какой лицензией будет распространяться эта штку
поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK
проясните пожалуйста, что именно СДК мог бы предоставить?
Тяжело объяснить в двух словах, ну что-то вроде наподобие AFIncrementalStore или вообще на основе него. Для удобного переключения между бэкэндами.
экспорт и мержинг при изменении CoreData модели в BaaS
пожалуйста проясните юз-кейс. Что делает клиент, что ожидается от сервера?
Это нужно в процессе разработки, смысл в том, что модель данных приходится делать 2 раза. 1 раза в CoreData и второй раз в BaaS. Чтоб этот процесс исключить, можно просто один раз сделать модель данных и экспортировать её в BaaS, и так-же поступать со всеми изменениями. В Heroku есть такая штука, называется BuildPack.
возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.
согласен. Мы рассматриваем этот режим запуска сервиса как «Backendless Enterprise». Планируется предоставить возможность загрузки продукта ближе к концу лета.
Вопрос как раз не в том, чтоб разворачивать это у себя на сервере. Суть в том, чтоб быстро это запустить на своей локальной машине только для разработки, а потом одной командой деплоить это на сервер. В Deployd посмотрите, там это основной способ работы. Это очень удобно, если над проектом работает один разработчик. Он работает со своей локальной копией, которая быстро работает без сети через lo интерфейс. А задеплоены все версии, которые уже были выпущены. На них работают тестеры или боевые релизы.
еще одну функцию забыл: возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.
Хорошо конечно, но то чего я не нашел ни в одном существующем сервисе:
— автоизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth), у тех что есть ограничего все Facebook и Twitter. Для русского сегмента не хватает как минимум вконтакта. Жду когда в http://deployd.com появится поддержка passport фреймворка. Умел бы — сам допилил.
— нормальный способ писать логику на сервере (побольше возможностей, дергать сторонние сервисы например, писать свои модули).
— поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK (это не сложно, но писать для того-же parse.com нет охоты, если и сделаю, то для deployd)
— поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либо. В том-же Parse это реализовано через CallBack, то-есть нужен кто-то кто бы эти функции периодически дергал
— экспорт и мержинг при изменении CoreData модели в BaaS.
Вот этого не хватает ни в одном существующем BaaS, а практически для каждого приложения это нужно, из тех, что я делаю.
По поводу отвлечения — тяжело себе представить полноценную навигацию на кнопках, чтоб это не отвлекало от вождения. Снять трубку, переключить трэк и станцию — это все можно сделать управлением на руле. Все остальное лучше реализовать на таче. Да и вообще тач не предусмотрен для того, чтоб им пользоваться во время движения — об этом он каждый раз напоминает при включении.
Плюс есть голосовое управление, работает оно уже сносно — позвонить определенному абоненту вполне можно, но до гугловского и эппловского распознования ему еще далеко.
Самые смелые в этом плане оказались электромобили от Tesla и я думаю в этом направлении постепенно будут двигаться все остальные:
— очень плохой экран, который засвечивается при ярком свете и большой пикселизацией
— ужасный резистивный тачскрин
— нереально корявая навигация, ехать по ней вообще нереально (дороги и маршрут нечитабельные, поиск по адресу занимает минут 5 )
— графика начала двухстысячных
— анимация на уровне 90-х
— юзабилити вообще отсуствует как класс
Вставляется эта штука как опция и стоит эта опция $2000!!! И от этого модуля вообще не зависит функциональная часть машины, так как это опция, так что особых требований к надежности и отказоустойчивости вообще нет. Для меня большая загадка почему такой консерватизм в этой части автомибелестроения.
Передовыми в этом плане являются Ситроен и Пэжо, но и их системы вызывают кучу нареканий.
Но от LGPL я бы был только рад :-)
— насколько активно это будет развиваться
— под какой лицензией будет распространяться эта штку
Тяжело объяснить в двух словах, ну что-то вроде наподобие AFIncrementalStore или вообще на основе него. Для удобного переключения между бэкэндами.
Это нужно в процессе разработки, смысл в том, что модель данных приходится делать 2 раза. 1 раза в CoreData и второй раз в BaaS. Чтоб этот процесс исключить, можно просто один раз сделать модель данных и экспортировать её в BaaS, и так-же поступать со всеми изменениями. В Heroku есть такая штука, называется BuildPack.
Вопрос как раз не в том, чтоб разворачивать это у себя на сервере. Суть в том, чтоб быстро это запустить на своей локальной машине только для разработки, а потом одной командой деплоить это на сервер. В Deployd посмотрите, там это основной способ работы. Это очень удобно, если над проектом работает один разработчик. Он работает со своей локальной копией, которая быстро работает без сети через lo интерфейс. А задеплоены все версии, которые уже были выпущены. На них работают тестеры или боевые релизы.
— автоизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth), у тех что есть ограничего все Facebook и Twitter. Для русского сегмента не хватает как минимум вконтакта. Жду когда в http://deployd.com появится поддержка passport фреймворка. Умел бы — сам допилил.
— нормальный способ писать логику на сервере (побольше возможностей, дергать сторонние сервисы например, писать свои модули).
— поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK (это не сложно, но писать для того-же parse.com нет охоты, если и сделаю, то для deployd)
— поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либо. В том-же Parse это реализовано через CallBack, то-есть нужен кто-то кто бы эти функции периодически дергал
— экспорт и мержинг при изменении CoreData модели в BaaS.
Вот этого не хватает ни в одном существующем BaaS, а практически для каждого приложения это нужно, из тех, что я делаю.