Планируется написание мобильного клиента лдя некоторых нужд по данную ОС.
хотелось бы услышать мниения спецов что лучше выбрать, задача такая что это будет мобильные клиент, оторые цеплятется к серверу через сокет и делает всякие разные манипуляции..
Есть несколько попросов
Хотелось бы услышать мнение бывалых специалистов по поводу сабжа.
А так же ответы на вопросы:

1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?
2) Возьмем только устройства с Symbian. Верно ли, что все что можно закодировать на j2me можно закодировать на с++ и намного больше ?
3) Что можно создать под Symbian на с++ чего нельзя создать на j2me ?

Здравствуйте, Vyatsek, Вы писали:


V>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?
Есть, за счет более низкой цены на железо

V>2) Возьмем только устройства с Symbian. Верно ли, что все что можно закодировать на j2me можно закодировать на с++ и намного больше ?
Да, верно.

V>3) Что можно создать под Symbian на с++ чего нельзя создать на j2me ?
См Series60 SDK, UIQ SDK

Здравствуйте, Vyatsek, Вы писали:

V>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?

Не уверен.

V>2) Возьмем только устройства с Symbian. Верно ли, что все что можно закодировать на j2me можно закодировать на с++ и намного больше ?

Да.

V>3) Что можно создать под Symbian на с++ чего нельзя создать на j2me ?

Чем ближе проект к железу и операционке, тем меньше можно сделать на j2me.

Здравствуйте, Crypto, Вы писали:

C>Здравствуйте, Vyatsek, Вы писали:

V>>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?

C>Не уверен.

V>>2) Возьмем только устройства с Symbian. Верно ли, что все что можно закодировать на j2me можно закодировать на с++ и намного больше ?

C>Да.

V>>3) Что можно создать под Symbian на с++ чего нельзя создать на j2me ?

C>Чем ближе проект к железу и операционке, тем меньше можно сделать на j2me.

Что касается 1 вопроса — можно смело поднимать ругань и мат в противоборстве с писателями для WM. Ничего другого обычно не получается.

Здравствуйте, Аноним, Вы писали:

А>Что касается 1 вопроса — можно смело поднимать ругань и мат в противоборстве с писателями для WM. Ничего другого обычно не получается.

Ну и кроме того, что есть WM, сейчас несколько интересных платформ рождается, что говорить о перекосе в сторону в Symbian в будущем по-моему еще преждевременно.

Здравствуйте, Vyatsek, Вы писали:

V>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?

Почти в тему:
Кстати, буквально вчера на уважаемом мною блоге mobilephonedevelopment.com была тема Top Devices for Development?. Пусть это не "тенденция развития", но как для разработчиков — интересная информация.

V>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?
Скорее уверен в обратном. Думаю судьба симбиана предрешена — наверняка будет и 10-я, и 11-я версия, и даже процент телефонов на нём, возможно, ещё выростет — но как платформа симбиан будет умирать. Не по силам нокии тащить такую огромную проприетарную платформу, к тому же с огромным грузом legacy архитектурных решений. Думаю, что место симбиана заменит embedded linux, в виде гугловского Android или чего-то вроде него.

Здравствуйте, Vyatsek, Вы писали:

V>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?
Да в сегменте смартфонов, как минимум до 2010 года конкурентов у Symbian не будет.
V>2) Возьмем только устройства с Symbian. Верно ли, что все что можно закодировать на j2me можно закодировать на с++ и намного больше ?
Да, но уровень затрат несоизмеримо выше. Найти специалиста по Symbian С++ довольно трудно.
V>3) Что можно создать под Symbian на с++ чего нельзя создать на j2me ?
Все зависит от исходной задачи. Для выбора между J2ME и С++ недостаточно данных по вашему проекту.

V>>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?
VPT>Да в сегменте смартфонов, как минимум до 2010 года конкурентов у Symbian не будет.
Будет, будет. "Золотое время" симбиана уже прошло. Система разрослась до масштабов, когда развивать её обеспечивая обратную совместимость очччень дорого. Уже переход с 7-й на 9-ю версию нарушил не только бинарную совместимость, но и совместимость на уровне усходных кодов. Ну и к тому же как мне кажется главный гробовщик симбиана — это отношение разработчиков ОС к разработчикам прикладных программ. Ещё на 7-ке жизнь симбиан разработчика была далеко не сахаром — убогая, багливая и несистематизированная документация, бедный выбор средств разработки, отсутствие third-party библиотек, сложность и неудобство программирования на том что они называют Symbian C++... А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков... У Linux масса преимуществ — открытый исходный код, куча кода, более-менее приличная документация, огромное сообщество программистов, книги и всё такое... Осталось только найти жирного и пробивного дядьку (типа google ) который сможет это пропихнуть в плане маркетинга. А современное железо в мобильных телефонах (даже самое слабенькое) потянет что Linux, что Symbian без особых проблем.

Здравствуйте, Left2, Вы писали:

V>>>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?
VPT>>Да в сегменте смартфонов, как минимум до 2010 года конкурентов у Symbian не будет.
L>Будет, будет. "Золотое время" симбиана уже прошло. Система разрослась до масштабов, когда развивать её обеспечивая обратную совместимость очччень дорого. Уже переход с 7-й на 9-ю версию нарушил не только бинарную совместимость, но и совместимость на уровне усходных кодов. Ну и к тому же как мне кажется главный гробовщик симбиана — это отношение разработчиков ОС к разработчикам прикладных программ. Ещё на 7-ке жизнь симбиан разработчика была далеко не сахаром — убогая, багливая и несистематизированная документация, бедный выбор средств разработки, отсутствие third-party библиотек, сложность и неудобство программирования на том что они называют Symbian C++... А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков... У Linux масса преимуществ — открытый исходный код, куча кода, более-менее приличная документация, огромное сообщество программистов, книги и всё такое... Осталось только найти жирного и пробивного дядьку (типа google ) который сможет это пропихнуть в плане маркетинга. А современное железо в мобильных телефонах (даже самое слабенькое) потянет что Linux, что Symbian без особых проблем.

При всем уважении, давайте не будем нести чушь. Вы видимо начитались какихто форумов или напридумывали? Это форум программистов всетаки, соответствуйте.

Утверждение — "Система разрослась до масштабов, когда развивать её обеспечивая обратную совместимость очччень дорого."
Ответ — Глупость откровенная. У Вас есть исходники или Вы замеряли размер Firmware на телефонах? откуда такие выводы? Symbian OS в отличие от WindowsMobile как раз и отличается небольшими размерами, потому что не тащит груз багов накопленный годами ( WinCE год выпуска, и после этого только "косметический ремонт") (и до сих пор 2007 год на дворе 64K цветов...).

Утверждение — "Ещё на 7-ке жизнь симбиан разработчика была далеко не сахаром — убогая, багливая и несистематизированная документация, бедный выбор средств разработки, отсутствие third-party библиотек, сложность и неудобство программирования на том что они называют Symbian C++."


Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
Багливая документация? Бедный выбор средств разработки? Сложность и неудобство? Видимо Вам после какого нить MFC все показалось "сложным и неудобным", а разбираться что к чему было лень. Каких же Вам "third-party библиотек" не хватило, если вы и с API разобраться не смогли?

Утверждение — "А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков..."
Ответ — 60% API не требует никаких "платных" лицензий. Остальное из соображений безопасности, да и то DevСert — для разработчиков бесплатен, а FreeWare подписывается бесплатно. Цена для "лицензирования" как Вы называете программу SymbianSigned — 200 у.е. за сертификат на год, + 20 у.е. за подписывание приложения.

Ну и в конце концов, посмотрите http://www.symbian.com/about/fastfacts/fastfacts.html и поговорим о Рынке и кто на нем лидер.

http://www.idc.com/getdoc.jsp?containerId=pr2007_10_24_202412
http://www.canalys.com/pr/2007/r2007024.htm

Здравствуйте, ValentinPT, Вы писали:

VPT>Утверждение — "А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков..."
VPT>Ответ Цена для "лицензирования" как Вы называете программу SymbianSigned — 200 у.е. за сертификат на год, + 20 у.е. за подписывание приложения.

Будем исходить из того, что большинство все-таки разрабатывает коммерческие приложения. И раз уж решили перечислить все траты, то самые объемные то вы и позабыли:
Сколько тестирование стоит, напомнить? И если у вас будет ошибка в проге (или даже документации — как у меня было когда-то), то еще столько же за реаплоад.

Здравствуйте, Crypto, Вы писали:

C>Здравствуйте, ValentinPT, Вы писали:

VPT>>Утверждение — "А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков..."
VPT>>Ответ Цена для "лицензирования" как Вы называете программу SymbianSigned — 200 у.е. за сертификат на год, + 20 у.е. за подписывание приложения.

C>Будем исходить из того, что большинство все-таки разрабатывает коммерческие приложения. И раз уж решили перечислить все траты, то самые объемные то вы и позабыли:
C>Сколько тестирование стоит, напомнить? И если у вас будет ошибка в проге (или даже документации — как у меня было когда-то), то еще столько же за реаплоад.


Вы правы, коммерческие приложения, должны приносить прибыль? Реаплоад будет вам стоить +20 y.e. — средняя стоимость одной продажи. Я не позабыл сколько стоит тестирование, Вы видимо давно не следите за изменениями в SymbianSigned. Ну и никто Вам не мешает продавать self-signed программы.

Здравствуйте, ValentinPT, Вы писали:

VPT>Вы правы, коммерческие приложения, должны приносить прибыль? Реаплоад будет вам стоить +20 y.e. — средняя стоимость одной продажи. Я не позабыл сколько стоит тестирование, Вы видимо давно не следите за изменениями в SymbianSigned.

Согласен, ознакомился, рад, что хоть в этом квартале до них дошло. Кстати, оно уже работает?
Ну и смотрю, что например для моего приложения все равно придется проходить Independent Test House testing, а там походу стоимость та же.

VPT>Ну и никто Вам не мешает продавать self-signed программы.

В моем случае это совсем не вариант.

VPT>При всем уважении, давайте не будем нести чушь. Вы видимо начитались какихто форумов или напридумывали? Это форум программистов всетаки, соответствуйте.
Да нет, разработал пару проектов. Все утверждения — из собственного опыта, работал и с Symbian (7.1 и 9, средства разработки Carbide и Carbide.VS), и с Windows Mobile, и с Embedded Linux.

VPT>Утверждение — "Система разрослась до масштабов, когда развивать её обеспечивая обратную совместимость очччень дорого."
VPT>Ответ — Глупость откровенная. У Вас есть исходники или Вы замеряли размер Firmware на телефонах? откуда такие выводы?
Размер firmware честно говоря меня не слишком волнует. А вот количество сервисов и размер API — огромно, и именно по нему можно судить о размере и сложности операционки.

VPT>Symbian OS в отличие от WindowsMobile как раз и отличается небольшими размерами, потому что не тащит груз багов накопленный годами ( WinCE год выпуска, и после этого только "косметический ремонт")

Windows Mobile — первый релиз April of 2000
The Series 5 device, released in 1997, used the first iterations of the EPOC32 OS.

Ну и кто из них старше, простите?

Кстати, для примера — Windows Mobile 6.0 имеет кардинально переработанное ядро OS по сравнению с 5.0, с целью снять ограничение в 32 метра адресного пространства на процесс. При этом подавляющее большинство программ для 5.0 прекрасно работает на 6.0. В Symbian при переходе с 7 на 9 подавляющее большинство программ даже не компилируется. В итоге, многие шароварные (а самое обидное — фриварные) программы под 9-ку так и не вышли.

VPT>(и до сих пор 2007 год на дворе 64K цветов...).
А при чём тут количество цветов? Да и кому на мобильном девайсе нужно больше?

VPT>Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
Простите, а Carbide.VS когда начал поддерживать Visual Studio 2005? 2 месяца назад? А до этого — только 2003.
Ущемления в средствах разработки примерно такие:
1. Эмулятор. Классный эмулятор, нечего сказать. Стартует он на моей машине пару минут. Я даже могу сказать почему — потому что при этом грузится порядка 2-х тысяч (!) Dll. В итоге — для того чтобы работать хоть чуть быстрее (меня никак не устраивает каждый раз после несколькосекундного фикса 2 минуты ждать старта эмулятора) приходится держать его постоянно запущеным, а для отладки делать Attach to process. К сожалению, работает такое примерно в 9 случаях из 10 — в итоге, всё равно эмулятор постоянно приходится перезапускать.
2. Отладочные символы (debug symbols). Благодаря их полному отсутствию, callstack зачастую абсолютно неактуален, что добавляет духа аркадности в процесс отладки. С другой стороны, если бы отладочные символы всё же были — боюсь, эмулятор пришлось бы запускать с вечера чтобы утром можно было хоть что-то запустить.
3. On-target debugging — обещали вроде бы только в платной версии Carbide? И то, только для Eclipse?
4. Аналоги WinCE-шных утилит Remote Process Viewer, Remote Spy, Remote File Viewer... Где взять?

ну и прочая, прочая...

VPT> Багливая документация? Бедный выбор средств разработки? Сложность и неудобство? Видимо Вам после какого нить MFC все показалось "сложным и неудобным", а разбираться что к чему было лень. Каких же Вам "third-party библиотек" не хватило, если вы и с API разобраться не смогли?
Да смог я разобраться с API (кстати, при чём тут MFC?). Проблема только в том что на это времени уходило в разы больше чем если бы документация была вменяемой. Оцените сам подход к документации — она разделена на 3 части:
1. API reference — в CHM (в нескольких, дабы разработчики не расслаблялись)
2. API description — в PDF (в куче PDF, часть из которых идёт с SDK, часть надо качать с сервера)
3. HowTo — на форуме (на самом деле на двух форумах, Nokia и NewLC).
Теперь представьте, что я хочу всего-то найти описание функции и понять как ей пользоваться. Квест да и только.

Ну и неудобство... В API reference описано процентов 80 API. Но вот лаконичность описания там зачастую — просто потрясающая. Для большинства нечасто используемого API описание состоит максимум из одного предложения. В итоге часто проще смотреть h-файлы — зачастую там документации больше. Ну а в большинстве случаев единственный способ разобраться — писАть тестовые примеры. Что очень сильно замедляет разработку.

VPT>Утверждение — "А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков..."
VPT>Ответ — 60% API не требует никаких "платных" лицензий.
Проблема в том что реально эти 60% API покрывают потребности только самых простейших приложений — игрушек и простейших клиентов для on-line сервисов (последние, кстати, к тому же на порядки проще писАть на Java2ME). Всё остальное — только за деньги. Да и к тому же — для большинства приложений для начала прийдётся купить DevKit. Сколько он там нынче стОит, килоевро?

VPT>Ну и в конце концов, посмотрите http://www.symbian.com/about/fastfacts/fastfacts.html и поговорим о Рынке и кто на нем лидер.
VPT>http://www.idc.com/getdoc.jsp?containerId=pr2007_10_24_202412
VPT>http://www.canalys.com/pr/2007/r2007024.htm
А я и не говорил что Symbian на рынке не лидер. Я говорил (и говорю) о том что дни его как лидера рынка (да и как конкурентноспособной системы вообще) сочтены.

VPT>Ответ — Глупость откровенная. У Вас есть исходники или Вы замеряли размер Firmware на телефонах? откуда такие выводы? Symbian OS в отличие от WindowsMobile как раз и отличается небольшими размерами, потому что не тащит груз багов накопленный годами ( WinCE год выпуска, и после этого только "косметический ремонт") (и до сих пор 2007 год на дворе 64K цветов...).

На что больше всего плевать юзеру — то это на размер операционки. У WinCE есть масса проблем которые тянутся с десктопов из древних виндовс, это я согласен, во многом убогость связана с GDI и компонентами на его базе, хотя ядро само по себе интересное. По поводу 64k — намного ли лучше современные дисплеи? Переход с 16bpp (64k цветов) на 32bpp (RGB8 + alpha) удвоит размер фреймбуффера. Для VGA это лишние полмегабайта. Переход на VGA — те же проблемы, экран в четыре раза больше, FPS падает в 4 раза, а большинство мобильных девайсов без видеоускорителей. Бездумный переход на глубокую цветность и высокие разрешения приведет к проблемам с производительностью, да уже есть проблемы с VGA. MS и рада бы на 24/32bpp перейти, да понимают что это создаст новые проблемы с перформансом и памятью

L>Кстати, для примера — Windows Mobile 6.0 имеет кардинально переработанное ядро OS по сравнению с 5.0, с целью снять ограничение в 32 метра адресного пространства на процесс. При этом подавляющее большинство программ для 5.0 прекрасно работает на 6.0. В Symbian при переходе с 7 на 9 подавляющее большинство программ даже не компилируется. В итоге, многие шароварные (а самое обидное — фриварные) программы под 9-ку так и не вышли.

Windows Mobile 6 базируется на ядре WinCE 5.0, также, как и WM5. Изменения чисто косметические, поэтому и проблем с переносимостью никаких. WinCE 6.0 действительно сильно переработано, но WM для него еще нет, и появится не очень скоро. WM6 — это не больше чем сервис пак для WM5 + мелкие улучшения приложений.

VPT>>(и до сих пор 2007 год на дворе 64K цветов...).
L>А при чём тут количество цветов? Да и кому на мобильном девайсе нужно больше?

Да не отказался бы, счас норма дисплеев 256k. Проблема в том, что переходить скорее всего надо на 32k — изза двух бит придется менять формат c RGB565 на RGBA8888 — ARM очень не любит невыровненные данные. Теоретически он могут перейти на RGB888. Мне очень нравится также картинка на VGA — проблема только в перформансе и потреблении энергии.

Здравствуйте, Left2, Вы писали:
L>Размер firmware честно говоря меня не слишком волнует. А вот количество сервисов и размер API — огромно, и именно по нему можно судить о размере и сложности операционки.

L>Windows Mobile — первый релиз April of 2000
L>The Series 5 device, released in 1997, used the first iterations of the EPOC32 OS.
L>Ну и кто из них старше, простите?
L>Кстати, для примера — Windows Mobile 6.0 имеет кардинально переработанное ядро OS по сравнению с 5.0, с целью снять ограничение в 32 метра адресного пространства на процесс. При этом подавляющее большинство программ для 5.0 прекрасно работает на 6.0. В Symbian при переходе с 7 на 9 подавляющее большинство программ даже не компилируется. В итоге, многие шароварные (а самое обидное — фриварные) программы под 9-ку так и не вышли.

Дело не в старшинстве, то что Symbian старше, только подчеркивает ее устойчивость к требованиям современного мира. И не надо рассказывать про "не компилирующиеся" программы, при переходе с 7 на 9. При внесении небольших изменений, которые затронуты новой моделью Security ( между прочим для пользователей сделано, и требование операторов сотовой связи) все работает. Заменили несколько устаревших API на новые и все ОК. А про Real Time Kernel вы чтонибудь слышали? Не скажите, когда у конкурентов что либо подобное появится?

VPT>>(и до сих пор 2007 год на дворе 64K цветов...).
L>А при чём тут количество цветов? Да и кому на мобильном девайсе нужно больше?
Хаха, как то билл гейтс сказал, "да вы што, кому нужно больше чем 640Кб памяти?"

VPT>>Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
L>Простите, а Carbide.VS когда начал поддерживать Visual Studio 2005? 2 месяца назад? А до этого — только 2003.
L>Ущемления в средствах разработки примерно такие:
L>1. Эмулятор. Классный эмулятор, нечего сказать. Стартует он на моей машине пару минут. Я даже могу сказать почему — потому что при этом грузится порядка 2-х тысяч (!) Dll. В итоге — для того чтобы работать хоть чуть быстрее (меня никак не устраивает каждый раз после несколькосекундного фикса 2 минуты ждать старта эмулятора) приходится держать его постоянно запущеным, а для отладки делать Attach to process. К сожалению, работает такое примерно в 9 случаях из 10 — в итоге, всё равно эмулятор постоянно приходится перезапускать.
L>2. Отладочные символы (debug symbols). Благодаря их полному отсутствию, callstack зачастую абсолютно неактуален, что добавляет духа аркадности в процесс отладки. С другой стороны, если бы отладочные символы всё же были — боюсь, эмулятор пришлось бы запускать с вечера чтобы утром можно было хоть что-то запустить.
L>3. On-target debugging — обещали вроде бы только в платной версии Carbide? И то, только для Eclipse?
L>4. Аналоги WinCE-шных утилит Remote Process Viewer, Remote Spy, Remote File Viewer... Где взять?

Добавление поддержки Visual Studio 2005, вышел новый эмулятор S60 Fp2 который стартует ГОРАЗДО быстрее, бесплатный Carbide.Express 1.2 ( скоро будет 1.3) все это говорит о том что система развивается и очень динамично. А что простите смотреть с помощъю Remote Process Viewer, Remote Spy, Remote File Viewer на Symbian? И зачем Вам отладка на Девайсе? это же не WinCE, где на эмуляторе одно, а на тел. хрен знает что происходит.

L>ну и прочая, прочая...

VPT>> Багливая документация? Бедный выбор средств разработки? Сложность и неудобство? Видимо Вам после какого нить MFC все показалось "сложным и неудобным", а разбираться что к чему было лень. Каких же Вам "third-party библиотек" не хватило, если вы и с API разобраться не смогли?
L>Да смог я разобраться с API (кстати, при чём тут MFC?). Проблема только в том что на это времени уходило в разы больше чем если бы документация была вменяемой. Оцените сам подход к документации — она разделена на 3 части:
L>1. API reference — в CHM (в нескольких, дабы разработчики не расслаблялись)
L>2. API description — в PDF (в куче PDF, часть из которых идёт с SDK, часть надо качать с сервера)
L>3. HowTo — на форуме (на самом деле на двух форумах, Nokia и NewLC).
L>Теперь представьте, что я хочу всего-то найти описание функции и понять как ей пользоваться. Квест да и только.
L>Ну и неудобство... В API reference описано процентов 80 API. Но вот лаконичность описания там зачастую — просто потрясающая. Для большинства нечасто используемого API описание состоит максимум из одного предложения. В итоге часто проще смотреть h-файлы — зачастую там документации больше. Ну а в большинстве случаев единственный способ разобраться — писАть тестовые примеры. Что очень сильно замедляет разработку.

Это вы о чем? в CHM файлах все описание, и функции и дескрипшин и How to есть статьи в том же хелпе. Руки надо иметь подходящие. М ненадо говорить, что программируя под WM вы не посещаете форумы или тому подобное.

VPT>>Утверждение — "А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков..."
VPT>>Ответ — 60% API не требует никаких "платных" лицензий.
L>Проблема в том что реально эти 60% API покрывают потребности только самых простейших приложений — игрушек и простейших клиентов для on-line сервисов (последние, кстати, к тому же на порядки проще писАть на Java2ME). Всё остальное — только за деньги. Да и к тому же — для большинства приложений для начала прийдётся купить DevKit. Сколько он там нынче стОит, килоевро?

Может просветите меня по поводу DevKit что это такое? и о каких простейших клиентах идет речь? когда 90% программ вполне обходятся self-signed сертификатами? Всё остальное — только за деньги. — Это простите о чем?

Ну и немного "о закате". Вчера объявили о выходе на Японский рынок еще 2 моделей Symbian смартфонов FOMA D905i и FOMA SH905i, Mitsubishi и Sharp соответственно, с поддержкой "наземного телевизионного вещания" ( перевод доведя общее число смартфонов на Японском рынке до 66.

Здравствуйте, AntZ, Вы писали:



AZ> Для VGA это лишние полмегабайта. Переход на VGA — те же проблемы, экран в четыре раза больше, FPS падает в 4 раза, а большинство мобильных девайсов без видеоускорителей. Бездумный переход на глубокую цветность и высокие разрешения приведет к проблемам с производительностью, да уже есть проблемы с VGA. MS и рада бы на 24/32bpp перейти, да понимают что это создаст новые проблемы с перформансом и памятью

Многие VGA WM-устройств имеют как минимум 2Д ускоритель:
Toshiba e800/e805 — ATI Imageon
iPAQ 4700/4705 — ATI Imageon
Acer N310/311 — NVidia GoForce 4000
+ аппаратное 3Д на axim x50v/x51v (intel 2700g) и O2 XDA Flame/imate 6150/8150 (GoForce 5500)

Кстати, продвинутые видеоплейеры (CorePlayer, в девичестве TCPMP) умеют использовать преимущества аппаратных ускорителей для вывода и проигрывания. Тесты на x50v того же tcpmp показывают различие ~1.5 раза между hw-ускоренным и неускоренным режимом.

Аналогичная тенденция (использовать аппаратный ускоритель для больших экранов) и в Symbian — в Nokia E90 hw 3D.

Здравствуйте, AntZ, Вы писали:


AZ>Да не отказался бы, счас норма дисплеев 256k. Проблема в том, что переходить скорее всего надо на 32k — изза двух бит придется менять формат c RGB565 на RGBA8888 — ARM очень не любит невыровненные данные. Теоретически он могут перейти на RGB888. Мне очень нравится также картинка на VGA — проблема только в перформансе и потреблении энергии.

В Symbian тоже ARM и имеем как RGB666X, так и RGB888X. На Nokia N80 и E70 (экраны 352х416) имеем RGB666X, на E90 (800х352 экран) — RGB888X

Кто мешает WM такие цвета сделать?

VPT>Дело не в старшинстве, то что Symbian старше, только подчеркивает ее устойчивость к требованиям современного мира. И не надо рассказывать про "не компилирующиеся" программы, при переходе с 7 на 9. При внесении небольших изменений, которые затронуты новой моделью Security ( между прочим для пользователей сделано, и требование операторов сотовой связи) все работает. Заменили несколько устаревших API на новые и все ОК.
Не компилируется — значит не компилируется. Значит что нельзя взять проект и просто его откомпилировать. Товарищ работает в конторе, они на перевод проекта (довольно крупного, правда) с 7-ки на 9-ку потратили несколько человеко-месяцев.

VPT>А про Real Time Kernel вы чтонибудь слышали? Не скажите, когда у конкурентов что либо подобное появится?
Насколько я помню, Windows CE соответствовала требованиям к real-time с самого начала. Real-time ядра Linux тоже вроде как не вчера появились.

VPT>>>(и до сих пор 2007 год на дворе 64K цветов...).
L>>А при чём тут количество цветов? Да и кому на мобильном девайсе нужно больше?
VPT>Хаха, как то билл гейтс сказал, "да вы што, кому нужно больше чем 640Кб памяти?"
Хм. При чём тут Билл? Давайте как-нибудь поменьше слюны, а то не слишком приятно в таком тоне разговаривать.

VPT>>>Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
L>>Простите, а Carbide.VS когда начал поддерживать Visual Studio 2005? 2 месяца назад? А до этого — только 2003.
L>>Ущемления в средствах разработки примерно такие:
L>>1. Эмулятор. Классный эмулятор, нечего сказать. Стартует он на моей машине пару минут. Я даже могу сказать почему — потому что при этом грузится порядка 2-х тысяч (!) Dll. В итоге — для того чтобы работать хоть чуть быстрее (меня никак не устраивает каждый раз после несколькосекундного фикса 2 минуты ждать старта эмулятора) приходится держать его постоянно запущеным, а для отладки делать Attach to process. К сожалению, работает такое примерно в 9 случаях из 10 — в итоге, всё равно эмулятор постоянно приходится перезапускать.
L>>2. Отладочные символы (debug symbols). Благодаря их полному отсутствию, callstack зачастую абсолютно неактуален, что добавляет духа аркадности в процесс отладки. С другой стороны, если бы отладочные символы всё же были — боюсь, эмулятор пришлось бы запускать с вечера чтобы утром можно было хоть что-то запустить.
L>>3. On-target debugging — обещали вроде бы только в платной версии Carbide? И то, только для Eclipse?
L>>4. Аналоги WinCE-шных утилит Remote Process Viewer, Remote Spy, Remote File Viewer... Где взять?

VPT>Добавление поддержки Visual Studio 2005,
Простите, на дворе какой год? 2007, и тот уже заканчивается. 2005-й студии уже почти 3(!) года, а поддержку её только-только добавили.

VPT>вышел новый эмулятор S60 Fp2 который стартует ГОРАЗДО быстрее, бесплатный Carbide.Express 1.2 ( скоро будет 1.3) все это говорит о том что система развивается и очень динамично.
Очень динамично — это конечно да. На самом деле года полтора-два назад Carbide.Express практически захлох — нокия решила забросить его потому что Carbide казался ей более прогрессивным. Однако, оказалось что как Eclipse+CDT слишком сильно проигрывает MSVC как IDE для разработки на С++. Вот и вытащили его с полки. ЕМНИП, года полтора новых версий Carbide.VS вообще не выходило и никакой разработки в этом направлении не велось.

VPT>А что простите смотреть с помощъю Remote Process Viewer, Remote Spy, Remote File Viewer на Symbian?
Процессы, окошки, файлы — всё на target device. И, желательно, на эмуляторе тоже. Чтобы одной и той же программой.

VPT>И зачем Вам отладка на Девайсе? это же не WinCE, где на эмуляторе одно, а на тел. хрен знает что происходит.
Дражайший, Вы бы перед тем как плевать на Windows Mobile для начала поинтересовались бы в чём разница между эмулятором Symbian и эмулятором Windows CE и почему последний в разы адекватнее первого...

VPT>Это вы о чем? в CHM файлах все описание, и функции и дескрипшин и How to есть статьи в том же хелпе. Руки надо иметь подходящие.
Откройте каталог C:\Symbian\9.1\S60_3rd_MR\S60Doc\
Теперь расскажите, как мне по виду функции (начнём, к примеру, с AknLayoutUtils::LayoutEdwin) найти её описание и примеры работы.

VPT>М ненадо говорить, что программируя под WM вы не посещаете форумы или тому подобное.
Посещаю. Вот только за ответами на вопросы я в 99% случаев хожу в документацию, а не на форум.

VPT>Может просветите меня по поводу DevKit что это такое?
Могу просветить:
http://developer.symbian.com/wiki/pages/viewpage.action?pageId=1859
DevKit содержит Include и Lib файлы для различных API, которых нет в SDK. К примеру, без DevKit не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего.

VPT>когда 90% программ вполне обходятся self-signed сертификатами?
Обходятся. К примеру, для того чтобы получить IMEI телефона — self-signed сертификата уже мало. В итоге, мне проще этот IMEI спросить у самого пользователя, чтобы он его ручками ввёл. Именно что обходятся.

VPT>Всё остальное — только за деньги. — Это простите о чем?
Все более-менее серьёзные API — только через Symbian Signed, да и к тому же через покупку DevKit.

VPT>Ну и немного "о закате". Вчера объявили о выходе на Японский рынок еще 2 моделей Symbian смартфонов FOMA D905i и FOMA SH905i, Mitsubishi и Sharp соответственно, с поддержкой "наземного телевизионного вещания" ( перевод доведя общее число смартфонов на Японском рынке до 66.
Ну и как это противоречит моему утверждению?

Здравствуйте, ValentinPT, Вы писали:

VPT>Добавление поддержки Visual Studio 2005, вышел новый эмулятор S60 Fp2 который стартует ГОРАЗДО быстрее, бесплатный Carbide.Express 1.2 ( скоро будет 1.3) все это говорит о том что система развивается и очень динамично. А что простите смотреть с помощъю Remote Process Viewer, Remote Spy, Remote File Viewer на Symbian? И зачем Вам отладка на Девайсе? это же не WinCE, где на эмуляторе одно, а на тел. хрен знает что происходит.

Когда говорят: "И зачем Вам отладка на Девайсе?", это, сори, очень смешно .
Может расскажете как отлаживать программу, работающую с камерой, ETel API, phone uplink?

По поводу документрированности, возможностей отладки согласен с Left2 на все 100%: Symbian в этом плане в большом проигрыше.

Здравствуйте, Left2, Вы писали:

VPT>>Дело не в старшинстве, то что Symbian старше, только подчеркивает ее устойчивость к требованиям современного мира. И не надо рассказывать про "не компилирующиеся" программы, при переходе с 7 на 9. При внесении небольших изменений, которые затронуты новой моделью Security ( между прочим для пользователей сделано, и требование операторов сотовой связи) все работает. Заменили несколько устаревших API на новые и все ОК.
L>Не компилируется — значит не компилируется. Значит что нельзя взять проект и просто его откомпилировать. Товарищ работает в конторе, они на перевод проекта (довольно крупного, правда) с 7-ки на 9-ку потратили несколько человеко-месяцев.

Давайте поконкретнее, а то "какойто парень", "какойто проект". С чем были проблемы, что за проект и квалификацию программиста занятого портированием ( может он только на работу устроился?)

VPT>>А про Real Time Kernel вы чтонибудь слышали? Не скажите, когда у конкурентов что либо подобное появится?
L>Насколько я помню, Windows CE соответствовала требованиям к real-time с самого начала. Real-time ядра Linux тоже вроде как не вчера появились.

Вы неправильно помните, пожалуйста ссылочки на Real time в WinCE и в ядрах для Mobile Linux.

VPT>>>>(и до сих пор 2007 год на дворе 64K цветов...).
L>>>А при чём тут количество цветов? Да и кому на мобильном девайсе нужно больше?
VPT>>Хаха, как то билл гейтс сказал, "да вы што, кому нужно больше чем 640Кб памяти?"
L>Хм. При чём тут Билл? Давайте как-нибудь поменьше слюны, а то не слишком приятно в таком тоне разговаривать.
В таком тоне начали Вы разговаривать, обратите внимание, чье высказывание про "да кому это надо" идет первым.


VPT>>>>Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
L>>>Простите, а Carbide.VS когда начал поддерживать Visual Studio 2005? 2 месяца назад? А до этого — только 2003.
L>>>Ущемления в средствах разработки примерно такие:
L>>>1. Эмулятор. Классный эмулятор, нечего сказать. Стартует он на моей машине пару минут. Я даже могу сказать почему — потому что при этом грузится порядка 2-х тысяч (!) Dll. В итоге — для того чтобы работать хоть чуть быстрее (меня никак не устраивает каждый раз после несколькосекундного фикса 2 минуты ждать старта эмулятора) приходится держать его постоянно запущеным, а для отладки делать Attach to process. К сожалению, работает такое примерно в 9 случаях из 10 — в итоге, всё равно эмулятор постоянно приходится перезапускать.
L>>>2. Отладочные символы (debug symbols). Благодаря их полному отсутствию, callstack зачастую абсолютно неактуален, что добавляет духа аркадности в процесс отладки. С другой стороны, если бы отладочные символы всё же были — боюсь, эмулятор пришлось бы запускать с вечера чтобы утром можно было хоть что-то запустить.
L>>>3. On-target debugging — обещали вроде бы только в платной версии Carbide? И то, только для Eclipse?
L>>>4. Аналоги WinCE-шных утилит Remote Process Viewer, Remote Spy, Remote File Viewer... Где взять?

VPT>>Добавление поддержки Visual Studio 2005,
L>Простите, на дворе какой год? 2007, и тот уже заканчивается. 2005-й студии уже почти 3(!) года, а поддержку её только-только добавили.

Микрософт изо всех сих старается нагадить, и поздняя поддержка 2005 студии изза закрытых форматов данных в Микрософт, которые были переделаны по сравнению с 2003. А под WinCE вы на 2007 студии работаете позвольте узнать?

VPT>>А что простите смотреть с помощъю Remote Process Viewer, Remote Spy, Remote File Viewer на Symbian?
L>Процессы, окошки, файлы — всё на target device. И, желательно, на эмуляторе тоже. Чтобы одной и той же программой.
Что вы будете делать с этими процессами, окошками? Это вам не виндовс, приаттачится не выйдет. А для эмулятора, есть встроенный менеджер, который показывает список процессов, размер памяти и т.д.


VPT>>И зачем Вам отладка на Девайсе? это же не WinCE, где на эмуляторе одно, а на тел. хрен знает что происходит.
L>Дражайший, Вы бы перед тем как плевать на Windows Mobile для начала поинтересовались бы в чём разница между эмулятором Symbian и эмулятором Windows CE и почему последний в разы адекватнее первого...

Ну расскажите мне в чем же он такой адекватный и почему эмулятоп Symbian нет.

VPT>>Это вы о чем? в CHM файлах все описание, и функции и дескрипшин и How to есть статьи в том же хелпе. Руки надо иметь подходящие.
L>Откройте каталог C:\Symbian\9.1\S60_3rd_MR\S60Doc\
L>Теперь расскажите, как мне по виду функции (начнём, к примеру, с AknLayoutUtils::LayoutEdwin) найти её описание и примеры работы.
VPT>>М ненадо говорить, что программируя под WM вы не посещаете форумы или тому подобное.
L>Посещаю. Вот только за ответами на вопросы я в 99% случаев хожу в документацию, а не на форум.

Существует проблема с документированием S60, но никак не с Symbian OS. На форуме Нокии это оперативно исправляется.

VPT>>Может просветите меня по поводу DevKit что это такое?
L>Могу просветить:
L>http://developer.symbian.com/wiki/pages/viewpage.action?pageId=1859
L>DevKit содержит Include и Lib файлы для различных API, которых нет в SDK. К примеру, без DevKit не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего.

Если бы утрудили себя переводом или хотя бы чтением — "used by device manufacturers for phone creation" Это ДевКиты для Производителей телефонов!!
"не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего"
Да неужели прямо не сделать?
Про хелп.

в Папке S60_3rd_FP1\Doc файл — _index.chm и все в нем подцеплено, ни одного .pdf нет.

"How to use the Camera API"

класс CCamera
PrepareVideoCaptureL

Capturing video images
Video capture involves the following:

Before video can be captured, a client calls the CCamera::PrepareVideoCaptureL() function to initialise the required resources. This function enables the client application to set the number of buffers to use and the number of frames per buffer. Buffers are then filled as frames become available. Once a buffer has been filled it is passed to the client via MCameraObserver::FrameBufferReady(). Once the data has been used the buffer should be released by calling the MFrameBuffer::Release() function.


VPT>>когда 90% программ вполне обходятся self-signed сертификатами?
L>Обходятся. К примеру, для того чтобы получить IMEI телефона — self-signed сертификата уже мало. В итоге, мне проще этот IMEI спросить у самого пользователя, чтобы он его ручками ввёл. Именно что обходятся.
Вы это мне говорите? self-signed сертификата ДОСТАТОЧНО. Можете посмотреть в моих программах, если сомневаетесь.

VPT>>Всё остальное — только за деньги. — Это простите о чем?
L>Все более-менее серьёзные API — только через Symbian Signed, да и к тому же через покупку DevKit.
Думаю Вам чтобы сделать программу, которой понадобится "более-менее серьёзные API" придется сильно напрячь свое воображение.

VPT>>Ну и немного "о закате". Вчера объявили о выходе на Японский рынок еще 2 моделей Symbian смартфонов FOMA D905i и FOMA SH905i, Mitsubishi и Sharp соответственно, с поддержкой "наземного телевизионного вещания" ( перевод доведя общее число смартфонов на Японском рынке до 66.
L>Ну и как это противоречит моему утверждению?

Здравствуйте, Crypto, Вы писали:

C>Здравствуйте, ValentinPT, Вы писали:

VPT>>Добавление поддержки Visual Studio 2005, вышел новый эмулятор S60 Fp2 который стартует ГОРАЗДО быстрее, бесплатный Carbide.Express 1.2 ( скоро будет 1.3) все это говорит о том что система развивается и очень динамично. А что простите смотреть с помощъю Remote Process Viewer, Remote Spy, Remote File Viewer на Symbian? И зачем Вам отладка на Девайсе? это же не WinCE, где на эмуляторе одно, а на тел. хрен знает что происходит.

C>Когда говорят: "И зачем Вам отладка на Девайсе?", это, сори, очень смешно .
C>Может расскажете как отлаживать программу, работающую с камерой, ETel API, phone uplink?
Эмулятор принимает СМС, ММС, позволяет коннектится в Интернет, Блютус поддерживает, что такое "phone uplink" мне неизвестно.
Я не говорю что это не нужно ВООБЩЕ, я говорю что круг задач невелик.

В свое время пытался отладить пару программ на PocketPC Embedded Studio 4.0( помоему), это ж тихий ужос, постоянно отваливалось, скорость по комманде в час. Отладка с помощьюю логов в 10 раз оказалась быстрее.

C>По поводу документрированности, возможностей отладки согласен с Left2 на все 100%: Symbian в этом плане в большом проигрыше.
По поводу документации, если человек не умеет читать, то ему и Большая советская энциклопедия будет "книжкой где ничего нет".

Здравствуйте, ValentinPT, Вы писали:

C>>Когда говорят: "И зачем Вам отладка на Девайсе?", это, сори, очень смешно .
C>>Может расскажете как отлаживать программу, работающую с камерой, ETel API, phone uplink?
VPT>Эмулятор принимает СМС, ММС, позволяет коннектится в Интернет, Блютус поддерживает, что такое "phone uplink" мне неизвестно.
VPT>Я не говорю что это не нужно ВООБЩЕ, я говорю что круг задач невелик.

Например мой круг задач это совсем не игрушки и приложения personal productivity.. И эмулятор для отладки, тем более такой, какой он сейчас, мне совсем не помогает. Может в новых версиях будет лучше, остается надеяться.

VPT>В свое время пытался отладить пару программ на PocketPC Embedded Studio 4.0( помоему), это ж тихий ужос, постоянно отваливалось, скорость по комманде в час. Отладка с помощьюю логов в 10 раз оказалась быстрее.

Время не стоит на месте: сейчас под студией все будет поживее.

C>>По поводу документрированности, возможностей отладки согласен с Left2 на все 100%: Symbian в этом плане в большом проигрыше.
VPT>По поводу документации, если человек не умеет читать, то ему и Большая советская энциклопедия будет "книжкой где ничего нет".

Вы бы попробовали другие платформы, сравнили. Мне приходилось писать и под "большую винду", и под "малую", и под j2me/Nokia&SE, и под j2me/Blackberry. Их качество документации даже нельзя ставить в сравнение с той, что идет с S60 SDK.

Я не говорю, что писать под S60 C++ невозможно — нет, пишем постоянно, но сцепив зубы, и с Forum Nokia, Wiki и NewLC перед глазами, чтоб не напороться на очередной баг системы или в поисках очередного workaround.

VPT>Давайте поконкретнее, а то "какойто парень", "какойто проект". С чем были проблемы, что за проект и квалификацию программиста занятого портированием ( может он только на работу устроился?)
Проект большой, связаный с телефонией. Основные проблемы были с отловом багов которые повылазили из-за недокументированных изменений в поведении телефонии под 9-кой. Подробности — под NDA.

L>>Насколько я помню, Windows CE соответствовала требованиям к real-time с самого начала. Real-time ядра Linux тоже вроде как не вчера появились.
VPT>Вы неправильно помните, пожалуйста ссылочки на Real time в WinCE и в ядрах для Mobile Linux.
http://www.windowsfordevices.com/articles/AT6761039286.html

VPT>Микрософт изо всех сих старается нагадить, и поздняя поддержка 2005 студии изза закрытых форматов данных в Микрософт, которые были переделаны по сравнению с 2003.
Да ну? Интересно, а почему приличные тулзы для Visual Studio (тот же Visual Assist) работали начиная с Beta-версий? Наверняка майкрософт во всём виноват, да...

VPT>А под WinCE вы на 2007 студии работаете позвольте узнать?
В смысле? 2007-й студии насколько я знаю не существует. Работаю на 2005-й. Практически с момента её выхода. Вышла 2008-я — как приедет, пересяду под неё.

VPT>Что вы будете делать с этими процессами, окошками? Это вам не виндовс, приаттачится не выйдет. А для эмулятора, есть встроенный менеджер, который показывает список процессов, размер памяти и т.д.
Зачем мне для эмулятора? Мне для девайса нужно. Про эмулятор см. ниже.

VPT>>>И зачем Вам отладка на Девайсе? это же не WinCE, где на эмуляторе одно, а на тел. хрен знает что происходит.
L>>Дражайший, Вы бы перед тем как плевать на Windows Mobile для начала поинтересовались бы в чём разница между эмулятором Symbian и эмулятором Windows CE и почему последний в разы адекватнее первого...
VPT>Ну расскажите мне в чем же он такой адекватный и почему эмулятоп Symbian нет.
Потому что эмулятор CE начиная с 5-й версии эмулирует ARM-овский процессор, а не является билдом всей оси для работы под Windows/x86. Внутри эмулятора — та же самая ось что и внутри девайса (ну, за исключением драйверов видео/клавиатуры и т.п.). Т.е., билд под эмулятор и под конкретный девайс в случае WinMobile один и тот же. Одним и тем же компилятором (в отличие от Symbian, где даже компиляторы для эмуляторной и боевой версии зачастую различаются).

VPT>>>Может просветите меня по поводу DevKit что это такое?
L>>Могу просветить:
L>>http://developer.symbian.com/wiki/pages/viewpage.action?pageId=1859
L>>DevKit содержит Include и Lib файлы для различных API, которых нет в SDK. К примеру, без DevKit не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего.
VPT>Если бы утрудили себя переводом или хотя бы чтением — "used by device manufacturers for phone creation" Это ДевКиты для Производителей телефонов!!
Я в курсе. Но только там есть практически всё доступное API.

VPT>"не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего"
VPT>Да неужели прямо не сделать?
Насколько я помню это работает начиная с 9-ки. А камеры ставят в телефоны уже Бог знает сколько времени.

VPT>Вы это мне говорите? self-signed сертификата ДОСТАТОЧНО. Можете посмотреть в моих программах, если сомневаетесь.
Достаточно для получения IMEI телефона? Ну что ж, теперь наверное да — после того как защиту симбиана сломали....

L>>Все более-менее серьёзные API — только через Symbian Signed, да и к тому же через покупку DevKit.
VPT>Думаю Вам чтобы сделать программу, которой понадобится "более-менее серьёзные API" придется сильно напрячь свое воображение.
Хотя бы телефония. Перехват звонков, переадресация, и вообще серьёзная работа с ними.

А>В Symbian тоже ARM и имеем как RGB666X, так и RGB888X.

Не вижу абсолютно никакого смысла в формате RGB666 — 18 бит это ни к селу, ни к городу. В памяти будет все равно минимум 24 бита.

На Nokia N80 и E70 (экраны 352х416) имеем RGB666X, на E90 (800х352 экран) — RGB888X
А>Кто мешает WM такие цвета сделать?

Сделают, когда надобность возникнет, и когда железо будет готово.

Здравствуйте, Left2, Вы писали:

L>Проект большой, связаный с телефонией. Основные проблемы были с отловом багов которые повылазили из-за недокументированных изменений в поведении телефонии под 9-кой. Подробности — под NDA.
Опять вода, вода.. Начиная с 2000 года, как я работаю с SymbianOS, "недокументированных изменений в поведении телефонии" как то не замечал. удивительно просто как мне везет.

L>>>Насколько я помню, Windows CE соответствовала требованиям к real-time с самого начала. Real-time ядра Linux тоже вроде как не вчера появились.
VPT>>Вы неправильно помните, пожалуйста ссылочки на Real time в WinCE и в ядрах для Mobile Linux.
L>http://www.windowsfordevices.com/articles/AT6761039286.html

Изучаем http://pdf.eccn.com/pdf1/pdf.newpro2005/Other/JXJ(12).pdf и естественно речь идет о Hard Real time kernel, которое позволяет производить single chip решения для смартфонов.

VPT>>Микрософт изо всех сих старается нагадить, и поздняя поддержка 2005 студии изза закрытых форматов данных в Микрософт, которые были переделаны по сравнению с 2003.
L>Да ну? Интересно, а почему приличные тулзы для Visual Studio (тот же Visual Assist) работали начиная с Beta-версий? Наверняка майкрософт во всём виноват, да...
Одно дело макросы, и примочки к студии, другое дело компилятор, отладка и прочее.

VPT>>>>Может просветите меня по поводу DevKit что это такое?
L>>>Могу просветить:
L>>>http://developer.symbian.com/wiki/pages/viewpage.action?pageId=1859
L>>>DevKit содержит Include и Lib файлы для различных API, которых нет в SDK. К примеру, без DevKit не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего.
VPT>>Если бы утрудили себя переводом или хотя бы чтением — "used by device manufacturers for phone creation" Это ДевКиты для Производителей телефонов!!
L>Я в курсе. Но только там есть практически всё доступное API.
Там действительно есть ВСЁ, собственно в DevKit входит весь Symbian вместе с исходниками.

VPT>>"не сделать захват видео с камеры в режиме стриминга, и ещё много-много чего"
VPT>>Да неужели прямо не сделать?
L>Насколько я помню это работает начиная с 9-ки. А камеры ставят в телефоны уже Бог знает сколько времени.
А мы разве не про Symbian начитая с 9-ки разговариваем? или давайте вспомним как PocketPC 2002 работал. и как там классно все было.

VPT>>Вы это мне говорите? self-signed сертификата ДОСТАТОЧНО. Можете посмотреть в моих программах, если сомневаетесь.
L>Достаточно для получения IMEI телефона? Ну что ж, теперь наверное да — после того как защиту симбиана сломали....
И еще раз, кто там кому что сломал?

L>>>Все более-менее серьёзные API — только через Symbian Signed, да и к тому же через покупку DevKit.
VPT>>Думаю Вам чтобы сделать программу, которой понадобится "более-менее серьёзные API" придется сильно напрячь свое воображение.
L>Хотя бы телефония. Перехват звонков, переадресация, и вообще серьёзная работа с ними.
Потрудитесь в хелп слазить, "Перехват звонков, переадресация, и вообще серьёзная работа с ними..." все там есть, не надо голословных заявлений.

Здравствуйте, Crypto, Вы писали:

C>Здравствуйте, ValentinPT, Вы писали:

C>>>Когда говорят: "И зачем Вам отладка на Девайсе?", это, сори, очень смешно .
C>>>Может расскажете как отлаживать программу, работающую с камерой, ETel API, phone uplink?
VPT>>Эмулятор принимает СМС, ММС, позволяет коннектится в Интернет, Блютус поддерживает, что такое "phone uplink" мне неизвестно.
VPT>>Я не говорю что это не нужно ВООБЩЕ, я говорю что круг задач невелик.

C>Например мой круг задач это совсем не игрушки и приложения personal productivity.. И эмулятор для отладки, тем более такой, какой он сейчас, мне совсем не помогает. Может в новых версиях будет лучше, остается надеяться.

VPT>>В свое время пытался отладить пару программ на PocketPC Embedded Studio 4.0( помоему), это ж тихий ужос, постоянно отваливалось, скорость по комманде в час. Отладка с помощьюю логов в 10 раз оказалась быстрее.

C>Время не стоит на месте: сейчас под студией все будет поживее.

C>>>По поводу документрированности, возможностей отладки согласен с Left2 на все 100%: Symbian в этом плане в большом проигрыше.
VPT>>По поводу документации, если человек не умеет читать, то ему и Большая советская энциклопедия будет "книжкой где ничего нет".

C>Вы бы попробовали другие платформы, сравнили. Мне приходилось писать и под "большую винду", и под "малую", и под j2me/Nokia&SE, и под j2me/Blackberry. Их качество документации даже нельзя ставить в сравнение с той, что идет с S60 SDK.

C>Я не говорю, что писать под S60 C++ невозможно — нет, пишем постоянно, но сцепив зубы, и с Forum Nokia, Wiki и NewLC перед глазами, чтоб не напороться на очередной баг системы или в поисках очередного workaround.

Ммм, интересно конечно.
Можно в кратце о Ваших проектах, было бы интересно пообщатся по конкретным проблемам. Особенно чтоб не напороться на очередной баг системы так сказать для самообразования будет полезно.
Я пробовал, и Palm и Дос и "большой" Windows и PocketPC и немного Линукса. Архитектура Symbian мне лично! нравится гораздо более остальных.

Здравствуйте, ValentinPT, Вы писали:

VPT>(и до сих пор 2007 год на дворе 64K цветов...).
Лично по моему это нисколько не проблема...

VPT>Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
А каким компилером пользуетесь?

VPT> Багливая документация? Бедный выбор средств разработки? Сложность и неудобство? Видимо Вам после какого нить MFC все показалось "сложным и неудобным", а разбираться что к чему было лень. Каких же Вам "third-party библиотек" не хватило, если вы и с API разобраться не смогли?
Ну это спорно ИМХО. По удобству разработки и качеству АПИ симба занимает твёрдое второе место после WM.

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, ValentinPT, Вы писали:

VPT>>(и до сих пор 2007 год на дворе 64K цветов...).
NBN>Лично по моему это нисколько не проблема...

VPT>>Ответ — Программируя в Visual Studio 2005.Net каких то "ущемлений в средствах разработки" не испытываю.
NBN>А каким компилером пользуетесь?
Нокиевский компилятор, устанавливается с СДК + Carbide.vs 3.0
До недавнего прошлого, пользовал 2003.Net и Carbide.vs 2.01, разницы особой замечено не было, перешел на 2005 т.к. новый эмулятор S60 FP2 в несколько раз быстрее грузится.

Также у нас в компании есть люди, до сих пор программирующие в Visual Studio 6 с эмулятором под S60v1, он то просто летает, а если писать с головой, портирование на UIQ3,S60v3 занимает пол дня.

VPT>> Багливая документация? Бедный выбор средств разработки? Сложность и неудобство? Видимо Вам после какого нить MFC все показалось "сложным и неудобным", а разбираться что к чему было лень. Каких же Вам "third-party библиотек" не хватило, если вы и с API разобраться не смогли?
NBN>Ну это спорно ИМХО. По удобству разработки и качеству АПИ симба занимает твёрдое второе место после WM.
Я и не спорю, что она супер и самая лучшая, просто все совсем не так плохо как некоторые высказываются, да и не основное это в разработке. В первую очередь, доля рынка определяет что и подо что писать. Будет мега крутой спрос на Андроид, портируем туда наши игры и программы ( если API позволит). Но чтото сомневаюсь даже в 5% рынка в течении след. пары лет. ИМХО ( чтоб не спорить )

Здравствуйте, Left2, Вы писали:


VPT>>Вы это мне говорите? self-signed сертификата ДОСТАТОЧНО. Можете посмотреть в моих программах, если сомневаетесь.
L>Достаточно для получения IMEI телефона? Ну что ж, теперь наверное да — после того как защиту симбиана сломали....

IMEI при self-signed можно было получать с самого начала.
Через

    CTelephony::TPhoneIdV1Pckg phoneIdPckg( iPhoneId ); 
    iTelephony->GetPhoneId(iStatus, phoneIdPckg);

Здравствуйте, Crypto, Вы писали:


C>Например мой круг задач это совсем не игрушки и приложения personal productivity.. И эмулятор для отладки, тем более такой, какой он сейчас, мне совсем не помогает. Может в новых версиях будет лучше, остается надеяться.

Так в чем проблема CodeWarrior использовать? Afaik, многие серьезные проекты его и используют, а вовсе не Карбиды и Ко.

Здравствуйте, ValentinPT, Вы писали:

VPT>Ммм, интересно конечно.
VPT>Можно в кратце о Ваших проектах, было бы интересно пообщатся по конкретным проблемам. Особенно чтоб не напороться на очередной баг системы так сказать для самообразования будет полезно.

Вкратце уже было — telephony API, видео/фото с камеры, Audio Proxy Server. Из свежих "радостных" багов — KIS000759. Самое большое удовольствие — объяснять заказчику, в чем отличие FP1 от "не FP1", и почему на FP1 не работает, хотя на "не FP1" работает.

VPT>Я пробовал, и Palm и Дос и "большой" Windows и PocketPC и немного Линукса. Архитектура Symbian мне лично! нравится гораздо более остальных.

Сочувствую

Здравствуйте, Crypto, Вы писали:

C>Сочувствую
Кстати и не стоит недооценивать personal productivity и games. Бывают и на порядок сложнее какойнить системы не видимой пользователю.
Юзеры они ж такие... привередливые.. а на низком уровне что, лишь бы работало, а как дело десятое.
P.S. Занимался разработкой пары сервисов для SE P800 когда он был в разработке.

Здравствуйте, Left2, Вы писали:


L>Потому что эмулятор CE начиная с 5-й версии эмулирует ARM-овский процессор, а не является билдом всей оси для работы под Windows/x86. Внутри эмулятора — та же самая ось что и внутри девайса (ну, за исключением драйверов видео/клавиатуры и т.п.). Т.е., билд под эмулятор и под конкретный девайс в случае WinMobile один и тот же.

Выделенное доставляет немало радостных минут
Никакими WM эмуляторами, например, не узнать о нестандартном видео-буфере в Motorola Q* (а сайт motorola своих на этот счет не предлагает)
Например, в Motorola Q9 h "y_pitch" равно вовсе не 320*2 байт (как следовало бы ожидать, исходя из размеров и ориентации экрана), а 4096.
А уж про работу с Treo 700w, Treo 700wx — просто песня. Эмулятор, скачанный с pdn.palm.com в этом случае ведет себя по-другому (почему-то считает, что там 32bpp), не как стандартный (и оба отличны от реальной работы на устройстве).
Кстати, нестандартные значения для параметров видео-буферов и раньше появлялись у некоторых WM устройств.
Еще раньше было (и тоже не отслеживалось никакими средствами, кроме как самими устройствами)

* Cassiopeia E-115 (xPitch = 2, yPitch = 512)
* Toshiba e740 (xPitch = 2, yPitch = 480)
* HP IPAQ 36xx series (xPitch = 640, yPitch = -2)
* HP IPAQ 38xx series (xPitch = -640, yPitch = 2)

Правда, вышеописанные проблемы актуальны только там, где нужна прямая запись в видео-буфер (плейеры там, некоторые игры и т.д.) Если использовать win api, то об этом и не догадываешься.
Вот у Symbian' не возникает проблем с нестандартным видео-буфером в устройствах. И любой формат цвета легко отладить, используя эмулятор.

Здравствуйте, ValentinPT, Вы писали:

VPT>Утверждение — "А в 9-ке к этому добавилась система платного лицензирования, которая отсекает мелких независимых разработчиков..."
VPT>Ответ — 60% API не требует никаких "платных" лицензий. Остальное из соображений безопасности, да и то DevСert — для разработчиков бесплатен, а FreeWare подписывается бесплатно.
Уточню, этих 60% API — хватает для 99.5% программ.

Здравствуйте, ValentinPT, Вы писали:

VPT>>>Вы это мне говорите? self-signed сертификата ДОСТАТОЧНО. Можете посмотреть в моих программах, если сомневаетесь.
L>>Достаточно для получения IMEI телефона? Ну что ж, теперь наверное да — после того как защиту симбиана сломали....
Да Left2 еще полгода назад советовали — прежде, чем что-то о Symbian писать — хоть что-то почитать из документации.
И про IMEI в прошлой ветке точно так же он говорил, насколько мне помнится.

А как первые S60 3rd Edition телефоны пошли — почему-то вполне нормально работало все на них.

Здравствуйте, Left2, Вы писали:

L>Windows Mobile — первый релиз April of 2000
L>The Series 5 device, released in 1997, used the first iterations of the EPOC32 OS.

L>Ну и кто из них старше, простите?

Справедливости ради, Windows CE выросла из проекта Пегас, который датируется 96-м годом. Вездесущий Джеффри Рихтер написал о нём статью, которую можно прочитать здесь: http://www.microsoft.com/msj/archive/S5FD.aspx. Тогда же были заложены основные архитектурные принципы и ограничения (32 процесса, 32MB виртуальной памяти на процесс и т. д.), которые просуществовали целых 10 лет – вплоть до выхода Windows CE 6.0 в 2006 году.

Кстати, до сих пор, взяв в руки новый девайс на базе WM6, можно найти в папке Windows файлы с префиксом "peg" — это ни что иное как наследие Пегаса. Например, справочная система peghelp.exe осталась ещё с тех времён.

L>Кстати, для примера — Windows Mobile 6.0 имеет кардинально переработанное ядро OS по сравнению с 5.0, с целью снять ограничение в 32 метра адресного пространства на процесс. При этом подавляющее большинство программ для 5.0 прекрасно работает на 6.0.

К тому, что сказал AntZ, добавлю, что, по нашим оценкам, с выходом WM7 придётся кардинально перерабатывать добрую половину наших продуктов.

Да, миграция на WM6 тоже была не такой безболезненной, как ты описываешь. Когда появился первый эмулятор WM6 с разрешением 320x320, мы проверили на нём программы из списка top10 на Handango. Так вот, из десяти программ с новым разрешением нормально работало штуки две.

L>А я и не говорил что Symbian на рынке не лидер. Я говорил (и говорю) о том что дни его как лидера рынка (да и как конкурентноспособной системы вообще) сочтены.

Кстати, рынок — понятие растяжимое. В Европе Симбиан — безоговорочный лидер, а вот в Азии и в Америке его позиции слабее. В Азии рулит Linux, а в Америке — Blackberry.

Здравствуйте, Denis Mingulov, Вы писали:

DM>Уточню, этих 60% API — хватает для 99.5% программ.

Мне вот интересно, это вы как замеряли?

Здравствуйте, Crypto, Вы писали:

DM>>Уточню, этих 60% API — хватает для 99.5% программ.
C>Мне вот интересно, это вы как замеряли?
Извините, NDA.
Но повторить исследование очень легко.

Здравствуйте, Denis Mingulov, Вы писали:

DM>Извините, NDA.


DM>Но повторить исследование очень легко.
Проход по какому-то каталогу приложений для сбора использованного API? Ну дык, это по этому совсем не исследование..

C>Проход по какому-то каталогу приложений для сбора использованного API? Ну дык, это по этому совсем не исследование..

Сори, имелось в виду "это по-моему совсем не".

Здравствуйте, Crypto, Вы писали:

DM>>Извините, NDA.
C>
Угу. И ответственность, кажется, до 5и миллионов евро.

DM>>Но повторить исследование очень легко.
C>Проход по какому-то каталогу приложений для сбора использованного API?
Нет.

Здравствуйте, Vyatsek, Вы писали:

V>1) Верно ли что есть тенденция развития в сторону устройств с поддержкой Symbian и что такие устройства будут доминировать ?

Smartphone рынок US & Canada:

Nokia на 4 месте. А на первом месте канадский RIM c Blackberry.

Так, на всякий случай.

AS>К тому, что сказал AntZ, добавлю, что, по нашим оценкам, с выходом WM7 придётся кардинально перерабатывать добрую половину наших продуктов.

У Вас многие продукты слишком глубоко внедряются в виндовс Думаю, для Xonix переработки будут несущественными

AS>Да, миграция на WM6 тоже была не такой безболезненной, как ты описываешь. Когда появился первый эмулятор WM6 с разрешением 320x320, мы проверили на нём программы из списка top10 на Handango. Так вот, из десяти программ с новым разрешением нормально работало штуки две.

Давайте не будем рассматривать экзотику Подержка тучи разрешений начинает становится головной болью — слишком их много развелось. Поддержать все разрешения — это непросто (вернее, недешего). Если WM5 меняется на WM6 на том-же девайсе, то никаких проблем со старыми программами нет Научное исследование не проводил — это ненаучное частное мнение.

AS>Кстати, рынок — понятие растяжимое. В Европе Симбиан — безоговорочный лидер, а вот в Азии и в Америке его позиции слабее. В Азии рулит Linux, а в Америке — Blackberry.

Apple и Android не дремлют. Скоро на мобильном рынке будет жарко.

Здравствуйте, AntZ, Вы писали:

AZ>Давайте не будем рассматривать экзотику Подержка тучи разрешений начинает становится головной болью — слишком их много развелось. Поддержать все разрешения — это непросто (вернее, недешего). Если WM5 меняется на WM6 на том-же девайсе, то никаких проблем со старыми программами нет Научное исследование не проводил — это ненаучное частное мнение.

С этим никто и не спорит. Но для меня "compatible with WM6" обозначает, что продукт на 100% поддерживает все разрешения и формфакторы, поддерживаемые этой платформой. Новые разрешения являются экзотикой только пока — Микрософт добавила их поддержку не сама по себе, а под давлением со стороны OEMов, и очень скоро таких девайсов будет много. Последнее время я постоянно слышу от OEMов вопрос: а поддерживает ли ваша программа X разрешение 320x320 и WVGA (480x800)? И если ответ на этот вопрос — "Не поддерживает", то фиг я такую программу кому-то продам.

Ну а что касается усилий, на поддержку новых разрешений и (особенно) DPI уходит уйма ресурсов. Вспоминаю выход 2003SE, "косметического" апдейта 2003, когда мы все несколько месяцев перетаскивали наши продукты на неё. С WM6 ситуация аналогичная — появился новый DPI, и как минимум всю графику нужно переделывать в ещё одном варианте. А на практике и программистам работы хватит.

AS>>Кстати, рынок — понятие растяжимое. В Европе Симбиан — безоговорочный лидер, а вот в Азии и в Америке его позиции слабее. В Азии рулит Linux, а в Америке — Blackberry.

AZ>Apple и Android не дремлют. Скоро на мобильном рынке будет жарко.

По-моему, там уже жарко. Но перспективы Apple представляются мне сомнительными. Android — другое дело, но с ним пока слишком много неясностей. Когда начнут продаваться первые девайсы на его основе, ситуация должна проясниться.

AS>С этим никто и не спорит. Но для меня "compatible with WM6" обозначает, что продукт на 100% поддерживает все разрешения и формфакторы, поддерживаемые этой платформой. Новые разрешения являются экзотикой только пока — Микрософт добавила их поддержку не сама по себе, а под давлением со стороны OEMов, и очень скоро таких девайсов будет много. Последнее время я постоянно слышу от OEMов вопрос: а поддерживает ли ваша программа X разрешение 320x320 и WVGA (480x800)? И если ответ на этот вопрос — "Не поддерживает", то фиг я такую программу кому-то продам.

А у Вас программы только OEM покупают? Вот WVGA вообще штука которая все очень конкретно портит. 640x480 и 320x240 по лейауту идентичны (банальный скайлинг), то же самое 480x480, 320x320, 240x240 — все это скайлинг. А вот WVGA ни в какие ворота не лезет

AS>Ну а что касается усилий, на поддержку новых разрешений и (особенно) DPI уходит уйма ресурсов. Вспоминаю выход 2003SE, "косметического" апдейта 2003, когда мы все несколько месяцев перетаскивали наши продукты на неё. С WM6 ситуация аналогичная — появился новый DPI, и как минимум всю графику нужно переделывать в ещё одном варианте. А на практике и программистам работы хватит.

И не понятно, окупится это или нет — девайсов тваких кот наплакал.

AS>По-моему, там уже жарко. Но перспективы Apple представляются мне сомнительными. Android — другое дело, но с ним пока слишком много неясностей. Когда начнут продаваться первые девайсы на его основе, ситуация должна проясниться.

МS задержит WM7 и похоже до 2009 года, это может дать шанс другим. Я тоже очень скептически относился к Apple, пока не поигрался с этим аппаратом вживую. Если Apple откроет платформу для разработчиков, игрок будет сильный, микрософтовский GDI в сравнению с OpenGL выглядит как терминал VT102 по сравнению с современным PC. Android — пока сферический конь в вакууме, но деньги там такие, что не рассматривать в серьез нельзя.

Я пока поставил на WM, но рассмотрю и другие платформы.

Здравствуйте, AntZ, Вы писали:

AS>>С этим никто и не спорит. Но для меня "compatible with WM6" обозначает, что продукт на 100% поддерживает все разрешения и формфакторы, поддерживаемые этой платформой. Новые разрешения являются экзотикой только пока — Микрософт добавила их поддержку не сама по себе, а под давлением со стороны OEMов, и очень скоро таких девайсов будет много. Последнее время я постоянно слышу от OEMов вопрос: а поддерживает ли ваша программа X разрешение 320x320 и WVGA (480x800)? И если ответ на этот вопрос — "Не поддерживает", то фиг я такую программу кому-то продам.

AZ>А у Вас программы только OEM покупают?

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

AZ>Вот WVGA вообще штука которая все очень конкретно портит. 640x480 и 320x240 по лейауту идентичны (банальный скайлинг), то же самое 480x480, 320x320, 240x240 — все это скайлинг. А вот WVGA ни в какие ворота не лезет

WVGA — интересное разрешение. В режиме списка оно позволяет увидеть больше итемов без скроллирования, а в режиме лендскейпа удобно работать с текстами и вебом — большинство сайтов всё-таки нормально влазят в 800 точек в ширину, а вертикальный скроллинг — это не так страшно. Плюс ко всему — широкоэкранное видео.

К тому же WVGA использует тот же DPI, что и 640x480, то есть графику переделывать не надо. Поэтому с этим разрешением проблем как раз сравнительно немного.

AZ>И не понятно, окупится это или нет — девайсов тваких кот наплакал.

Думаю, это временно. Например, Palm Treo в варианте 320x320 выйдет наверняка, а Treo — очень популярная линейка в Штатах.

AZ>Я тоже очень скептически относился к Apple, пока не поигрался с этим аппаратом вживую. Если Apple откроет платформу для разработчиков, игрок будет сильный, микрософтовский GDI в сравнению с OpenGL выглядит как терминал VT102 по сравнению с современным PC.

Согласен. iPhone — хорошая штука, по слухам даже Билл Гейтс это признал. И всё же у них в экосистеме не хватает одного очень существенного звена — OEMов. Одно дело — конкурировать со всякими Креативами и ириверами, а совсем другое — с тандемом производителей мобильных телефонов (Motorola, Samsung, Nokia, HTC и др.). Эти ребята без особых проблем клонируют удачные решения Apple, этот процесс уже во всю идёт, и как дальше с ними бороться — не ясно. Понятно, что свою нишу имиджевых продуктов Apple займёт, но вот сможет ли он претендовать на большее — большой вопрос.

AZ>Android — пока сферический конь в вакууме, но деньги там такие, что не рассматривать в серьез нельзя.

Угу, потенциал большой. С интересом ждём продолжения банкета.

AZ>Я пока поставил на WM, но рассмотрю и другие платформы.

У нас та же фигня.

AS>WVGA — интересное разрешение. В режиме списка оно позволяет увидеть больше итемов без скроллирования, а в режиме лендскейпа удобно работать с текстами и вебом — большинство сайтов всё-таки нормально влазят в 800 точек в ширину, а вертикальный скроллинг — это не так страшно. Плюс ко всему — широкоэкранное видео.

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

AS>К тому же WVGA использует тот же DPI, что и 640x480, то есть графику переделывать не надо. Поэтому с этим разрешением проблем как раз сравнительно немного.

Нет девайсов — нет проблем Можно тупо адаптировать VGA (изменять размеры контролсов, по другому алайнить элементы и т.д), а можно дизайнить интерфейс под это разрешение. В этом случае можно и переосмыслить интерфейс, переделать графику для него (изменив пропорции). Но думаю, что проще сделать поддержку этого разрешения для "галочки". Типа есть, юзеров не очень сильно пугает и хорошо Думаю, Вы не сильно "паритесь" с этим разрешением

AS>Думаю, это временно. Например, Palm Treo в варианте 320x320 выйдет наверняка, а Treo — очень популярная линейка в Штатах.

Я бы себе не купил — знаю, как дела с поддержкой этого разрешения, QVGA landscape и тот не идеально поддерживается

AZ>Одно дело — конкурировать со всякими Креативами и ириверами, а совсем другое — с тандемом производителей мобильных телефонов (Motorola, Samsung, Nokia, HTC и др.).

Есть примеры, когда Apple пишел на высококонкурентный рынок и всех там "порешил" — это рынок mp3 плейеров. Не знаю, зватит ли у них ума не конкурировать против всего мира и использовать потенциал iPhone

Здравствуйте, AntZ, Вы писали:

AZ>В смартфоне я такое чудо представить не могу

Кстати, Apple тоже ведь не зря сделал у iPhone широкоформатный экран.

AZ>Думаю, Вы не сильно "паритесь" с этим разрешением

Сильно не паримся, но это и не нужно. Например, различные списки встречаются в программах (не только наших) достаточно часто. Они просто растягиваются на всю высоту экрана, что улучшает юзабилити. Диалоги — да, не меняем, нет смысла.

AZ>Я бы себе не купил — знаю, как дела с поддержкой этого разрешения, QVGA landscape и тот не идеально поддерживается

А я вообще не признаю квадратные экраны. Но я уже давно смирился с тем, что вкусы массового юзера как правило сильно отличаются от моих.

AZ>>Одно дело — конкурировать со всякими Креативами и ириверами, а совсем другое — с тандемом производителей мобильных телефонов (Motorola, Samsung, Nokia, HTC и др.).

AZ>Есть примеры, когда Apple пишел на высококонкурентный рынок и всех там "порешил" — это рынок mp3 плейеров.

Мне как раз кажется, что есть качественная разница между конкурентами Apple там и здесь. "Там" Apple был слоном в посудной лавке, а здесь ему предстоит конкурировать с компаниями, которые не уступают ему ни в финансовых и маркетинговых возможностях, ни в опыте и культуре разработки. У Apple, конечно, есть свои козыри, тот же iTunes... Ну да посмотрим.

Здравствуйте, c-smile, Вы писали:


CS>Nokia на 4 месте. А на первом месте канадский RIM c Blackberry.

Даже не на 4-м, как я посмотрю.
PDF с результатами продаж смартфонов по производителю и по странам:
Q3/07 Smartphone Market Share