Ну, как сказать… Мне лично понравился оригинал, поэтому и решил его перевести. Всё-таки нельзя говорить, что это давно всем известно. Да, для тех, кто очень внимательно следит за всеми платформами, большинство сведений и не покажутся новыми, но тут-то смысл был в объединении и некотором структурировании текущей информации по платформам.
Про корпоративный сектор ИМХО надо тогда отдельную статью писать :)
Это многозадачность, но специально ограниченная, вот в чём дело. Т.е. естественно, что в юниксе не может не быть многозадачности, но в айфоне её искусственно зарезали — сторонние приложения нельзя запускать пачками, только по одной штуке. Аргументируют тем, что, мол, батарейку чтобы не сажали всякие фоновые приложения.
Подросток — это значит не достигла половой зрелости :) Т.е. ещё не присутствует на рынке. В оригинале статьи там написано Adolescent. На самом деле, не совсем понятно, почему webOS «Young», по идее тоже подростком быть должна. Можно наехать на автора попробовать, что это он так :)
Я тут как-то пытался узнать, как разрабатываются виджеты на Samsung Omnia (i900). И я узнал, что там весь этот хитрый рабочий стол, это вроде как, флеш и есть. А я всё понять не мог, почему там так тормозит таскание виджетов по экрану! Чёрт, ну не было бы этой полупрозрачности, зато всё бы летало… ан нет, пошли по другому пути. Особенно жестоко, когда стоишь в каком-нибудь MediaMarkt и сравниваешь Omina и iPhone. Мало того, что сенсорный экран на палец плохо отзывается, так ещё и 5-7 кадров в секунду при таскании виджетов по экрану… жуть, короче. Не хочу много флеша на WinMobile — он там тормозит :)
Дело в том, что с прозрачными PNG при разработке приложений есть проблемы. Что native, что managed. Вот почему этот момент акцентировали. Про сложности работы с прозрачностью я писал отдельную статью: habrahabr.ru/blogs/mobiledev/44327/
Про сложнее и интереснее — не спорю. Гугл не по делу не выпендривается. Мне кажется, что тут вопрос в поддержке Java на системном уровне в Android… Отчасти можно сравнить с поддержкой .NET в десктоп Windows.
Кста, из той же википедийной статьи — там крутая концовка:
>> Набор команд RCT не привязан жёстко к языку Java и может использоваться для компиляции байт-кодов прочих интерпретируемых языков, таких как Perl, Python, а также языков, поддерживаемых технологией .NET фирмы Microsoft.
Т.е. нас может то же счастье ждать и в CF.NET? Кайф :) Другой вопрос, что может не значит будет… Мы и Windows Mobile 7 вряд ли дождёмся в обозримом будущем :(
Я не забываю, я смирился. Но только со скоростью запуска. С ней почти ничего нельзя поделать. Отчасти спасает демонстрация прогресса загрузки. А ещё спасает модель выгрузки приложений из памяти в Windows Mobile — после запуска и сворачивания, повторное разворачивание происходит моментально.
А вот со скоростью работы я решил вопрос полностью — всё летает от и до. (Ну и что, что из родных контролов только TextBox и InputPanel)
Quick Entry вспомнить, к сожалению, не мог, т.к. с Finance знаком только по описанию, но идею улавливаю, безусловно — я ведь сам такоей же end-user, как и все.
Кстати, а вот ещё момент интересный. На том же Андроиде мы вынужденны программировать на чём? Верно, на Java. А чем Java (в общемировом масштабе) отличается от .Net? В случае с Андроидом отличие большое — это единственный способ писать программы для него (если не считать веб-приложений, которые почти что не считаются).
А в реальности-то Java — ни разу не нативный язык для устройств и этим не сильно отличается от .Net…
Ну так ведь и для десктопа на C# далеко не сразу начали активно программировать. Но сейчас-то это совсем не так.
Лично в моей ситуации попасть в top100 просто физически невозможно — сегмент узковат :)
Кстати, если, например, сравнить различный софт от Spb Software House ( судя по профилю, Вы оттуда :) ). Сегмент юзеров Mobile Shell однозначно шире, чем Wireless Monitor или Finance, верно? И причина ведь очевидна!
И если для Wireless Monitor, вероятнее всего, платформа критична, то для Finance — очень сомневаюсь. Конечным юзерам Finance с большой вероятностью всё равно, дотнет там или нет. Т.к. приложение работает и выполняет свои функции.
А в виде отдельной статьи этот урок можно сделать? ИМХО было бы круче. Видео попробовал скачать, uploadbox не смог (503 Error), начал смотреть на rutuble, где-то через минуту (в ролике) появилось строк 10 кода :) Ну, т.е. кайфа не очень много получил, хотя в виде статьи, скорее всего, получил бы больше удовольствия :)
Хм. Проект, изначально созданный для смарт-дивайса, должен быть куда-то задеплоен, чтобы автоматически началась отладка по F5. Деплоиться ему можно только в выбранный из списка дивайс. Без описанного в статье хака, в списке либо реальный дивайс (подключённый через ActiveSync), либо эмулятор.
Я так понимаю, что если проект отдельно сделать для десктопа и использовать общий с мобильным устройством BLL, то тогда да, оттуда в эмулятор вообще никак не попасть. Но у меня-то соль в том, что я только таргет при сборке меняю, а файл проекта один, общий.
Возможно, у Вас на других этапах были танцы с бубном, но Вы подзабыли? Пока не вижу другого объяснения.
Короче говоря, то, о чём Вы говорите, больше похоже на общий BLL и абсолютно разный GUI.
Отладка в эмуляторе — это одно, отладка десктопной сборки — другое. Эмулятор меня не устраивает тем, что даже на 2.5ГГц Core2Duo приложение визуально работает несколько хуже, чем на живом дивайсе :)
Естественно, что я знаю об отладке в эмуляторе, и пользуюсь ей регулярно. Удивительно даже, что из статьи может показаться, что я случайно нашёл какой-то единственный для себя способ :)
Про формы — в моём конкретном случае так сложилось, что у меня полностью свой GUI фреймворк, поэтому на десктопе просто используется VGA-скин, а весь внешний вид фактически такой же, как на дивайсе — поэтому мне вообще не нужно делать разные формы для разных платформ, только немного #if #endif.
Разрабатывая свой продукт для Windows Mobile, сталкиваешься с тем, что появляются люди, которые бы хотели пользоваться твоим продуктом на десктопе. Серьёзно. Полностью написать другое приложение, положим, просто нет ни времени, не желания. В моём случае, я потратил около 5 часов на то, чтобы всё собралось и заработало. Учитывая, что на разработку в целом было потрачено более 800 часов, можно сказать, что десктоп версия появилась даром.
Безусловно, можно сказать, что от десктоп приложений люди могут ждать большего или совсем другого, но, поверьте, это действительно удобно. Более того, даже тестировать десктоп версию проще, чем мобильную, т.к. не нужно поднимать эмулятор. Естественно, что особенности (или косяки) фреймворков не удастся отловить, но вот ошибки в логике приложения — легко! Доказано неоднократными багрепортами от пользователей десктоп версии.
lmgtfy.com/?q=android+on+a+windows+mobile+device
Я видел более крутую тему — dual boot на iPhone, второй ОС выступал Windows Mobile 6.1 :)
www.engadget.com/2008/10/13/windows-mobile-ported-to-iphone-we-think/
Судя по коментам это фейк, но очень стёбный :)
Про корпоративный сектор ИМХО надо тогда отдельную статью писать :)
Про сложнее и интереснее — не спорю. Гугл не по делу не выпендривается. Мне кажется, что тут вопрос в поддержке Java на системном уровне в Android… Отчасти можно сравнить с поддержкой .NET в десктоп Windows.
Кста, из той же википедийной статьи — там крутая концовка:
>> Набор команд RCT не привязан жёстко к языку Java и может использоваться для компиляции байт-кодов прочих интерпретируемых языков, таких как Perl, Python, а также языков, поддерживаемых технологией .NET фирмы Microsoft.
Т.е. нас может то же счастье ждать и в CF.NET? Кайф :) Другой вопрос, что может не значит будет… Мы и Windows Mobile 7 вряд ли дождёмся в обозримом будущем :(
А вот со скоростью работы я решил вопрос полностью — всё летает от и до. (Ну и что, что из родных контролов только TextBox и InputPanel)
Quick Entry вспомнить, к сожалению, не мог, т.к. с Finance знаком только по описанию, но идею улавливаю, безусловно — я ведь сам такоей же end-user, как и все.
А в реальности-то Java — ни разу не нативный язык для устройств и этим не сильно отличается от .Net…
Лично в моей ситуации попасть в top100 просто физически невозможно — сегмент узковат :)
Кстати, если, например, сравнить различный софт от Spb Software House ( судя по профилю, Вы оттуда :) ). Сегмент юзеров Mobile Shell однозначно шире, чем Wireless Monitor или Finance, верно? И причина ведь очевидна!
И если для Wireless Monitor, вероятнее всего, платформа критична, то для Finance — очень сомневаюсь. Конечным юзерам Finance с большой вероятностью всё равно, дотнет там или нет. Т.к. приложение работает и выполняет свои функции.
Я так понимаю, что если проект отдельно сделать для десктопа и использовать общий с мобильным устройством BLL, то тогда да, оттуда в эмулятор вообще никак не попасть. Но у меня-то соль в том, что я только таргет при сборке меняю, а файл проекта один, общий.
Возможно, у Вас на других этапах были танцы с бубном, но Вы подзабыли? Пока не вижу другого объяснения.
Короче говоря, то, о чём Вы говорите, больше похоже на общий BLL и абсолютно разный GUI.
Естественно, что я знаю об отладке в эмуляторе, и пользуюсь ей регулярно. Удивительно даже, что из статьи может показаться, что я случайно нашёл какой-то единственный для себя способ :)
Про формы — в моём конкретном случае так сложилось, что у меня полностью свой GUI фреймворк, поэтому на десктопе просто используется VGA-скин, а весь внешний вид фактически такой же, как на дивайсе — поэтому мне вообще не нужно делать разные формы для разных платформ, только немного #if #endif.
Разрабатывая свой продукт для Windows Mobile, сталкиваешься с тем, что появляются люди, которые бы хотели пользоваться твоим продуктом на десктопе. Серьёзно. Полностью написать другое приложение, положим, просто нет ни времени, не желания. В моём случае, я потратил около 5 часов на то, чтобы всё собралось и заработало. Учитывая, что на разработку в целом было потрачено более 800 часов, можно сказать, что десктоп версия появилась даром.
Безусловно, можно сказать, что от десктоп приложений люди могут ждать большего или совсем другого, но, поверьте, это действительно удобно. Более того, даже тестировать десктоп версию проще, чем мобильную, т.к. не нужно поднимать эмулятор. Естественно, что особенности (или косяки) фреймворков не удастся отловить, но вот ошибки в логике приложения — легко! Доказано неоднократными багрепортами от пользователей десктоп версии.