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

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.
Ну и как это противоречит моему утверждению?