Comments 51
Добавлю еще, что для маководов, или тех, кто не может себе позволить Visual Studio Professional и выше, существует среда MonoDevelop, там также есть плагин для разработки под Android (Mono for Android).
+1
Раз затронули MonoDevelop и мак, могу добавить, что по моим личным впечатлениям Mono Android работает лучше именно на маке.
Почему?
1. Опять же по личным ощущениям, гораздо быстрее работает deploy на эмулятор. На Windows я достаточно долго подбирать сочетание версии проекта/версии Android на эмуляторе, для более-менее приемлемого времени deploy (остановился на версии 2.1 для проекта и 2.1.1 для эмулятора).
2. (самое главное) Корректно работает отладка. Не знаю почему, но в Visual Studio в отладка работает невероятно медленно. Практически всегда нет возможности даже увидеть значение переменной на breakpoint. Вместо значения, выдается сообщение о том, что время ожидания истекло.
Так что когда мне нужно что-либо отладить, я перехожу на мак.
Почему?
1. Опять же по личным ощущениям, гораздо быстрее работает deploy на эмулятор. На Windows я достаточно долго подбирать сочетание версии проекта/версии Android на эмуляторе, для более-менее приемлемого времени deploy (остановился на версии 2.1 для проекта и 2.1.1 для эмулятора).
2. (самое главное) Корректно работает отладка. Не знаю почему, но в Visual Studio в отладка работает невероятно медленно. Практически всегда нет возможности даже увидеть значение переменной на breakpoint. Вместо значения, выдается сообщение о том, что время ожидания истекло.
Так что когда мне нужно что-либо отладить, я перехожу на мак.
+1
Это я к тому, что полезно было бы в статье заметочку сделать о том, что есть еще стредство, а то у вас «необходимо установить Visual Studio». Кто захочет просто попробовать и не имеет студии — лучше за 5 минут поставить MonoDevelop, чем час ставить Visual Studio.
+1
UFO just landed and posted this here
А я вот хотел бы разобраться, что есть регистр Windows и при чем тут Java?
Если, все-таки, имеется в виду реестр, то не вижу проблем. Работаю с реестром и с Python — и все отлично получается, без всяких извращений. Собственно, реестр та же база данных, и получать доступ из Java или из Brainfuck'a, — все равно, тут главное, чтоб бинд для языка был.
Единственный минус в том, что приложение «не родное», но как показывает моя практика, 95% эффекта в приложениях дает радиус кривизны рук, а остальное — уже нативность, «языковость», инструменты и прочие факторы.
Если, все-таки, имеется в виду реестр, то не вижу проблем. Работаю с реестром и с Python — и все отлично получается, без всяких извращений. Собственно, реестр та же база данных, и получать доступ из Java или из Brainfuck'a, — все равно, тут главное, чтоб бинд для языка был.
Единственный минус в том, что приложение «не родное», но как показывает моя практика, 95% эффекта в приложениях дает радиус кривизны рук, а остальное — уже нативность, «языковость», инструменты и прочие факторы.
+1
UFO just landed and posted this here
>> Тот, кто писал на C#/C++ с использованием Win API остается в выйгрышном положении.
В некотором роде — да. Но код все равно придется переписать. К тому же вы правильно заметили, что нужно верно подбирать инструмент. В этом случае я смотрю, насколько жива разработка этого инструмента.
Насчет изменений в API. Когда API какого-либо продукта обновляется, обычно старое API еще есть как deprecated одну или несколько версий продукта, либо старое API просто остается, а появляется новое, — используй какое хочешь. Вряд ли разработчики API будут просто так все ламать, чтобы все клиенты упали, это и им в том числе не выгодно, ну разве что в случае полного неадеквата, такое, к сожалению, также встречается.
В некотором роде — да. Но код все равно придется переписать. К тому же вы правильно заметили, что нужно верно подбирать инструмент. В этом случае я смотрю, насколько жива разработка этого инструмента.
Насчет изменений в API. Когда API какого-либо продукта обновляется, обычно старое API еще есть как deprecated одну или несколько версий продукта, либо старое API просто остается, а появляется новое, — используй какое хочешь. Вряд ли разработчики API будут просто так все ламать, чтобы все клиенты упали, это и им в том числе не выгодно, ну разве что в случае полного неадеквата, такое, к сожалению, также встречается.
+1
но по мне так это извращение — писать на C# под Android
Есть один подкупающий момент. Написанное на c# можно запустить на Android, iOS, Maemo, BlackBerry, Symbian, Windows Mobile, Windows Phone. Т.е. накрыть практически весь мобильный рынок… хотя не без костылей))
+6
В этом подходе кажется, что костылей может оказаться столько, что проще изначально писать приложения под отдельные платформы.
+3
UFO just landed and posted this here
Что касается именно кода на c#, то я не заметил ни одной платформо-зависимой строки. А вот раскладки (описание формы в xml) могут отличаться. Правда и в таком случае не составляет сложности написать небольшой XSLT или инициализировать раскладки из кода.
Потом мне не совсем понятно ограничение «ни строчки кода»? Если у меня появится #if SOMEPLATFORM на одну строчку кода, то вся кросс-платформенность сразу рухнет? И проще написать под Android на Java, под iOS на ObjectiveC, под WP7 на c# и далее по спиcку?
Потом мне не совсем понятно ограничение «ни строчки кода»? Если у меня появится #if SOMEPLATFORM на одну строчку кода, то вся кросс-платформенность сразу рухнет? И проще написать под Android на Java, под iOS на ObjectiveC, под WP7 на c# и далее по спиcку?
0
UFO just landed and posted this here
то я не заметил ни одной платформо-зависимой строки
Activity, ListActivity, ArrayAdapter, Button, Context, View, LayoutInflater, TextView…
Конечно, круто было бы написать, один и тот же код сразу для всех устройств. Но пока различия между ними большие и уровень абстракции настолько низок, что Mono — это для тех кто не хочет писать на Java для Android и не более того.
Activity, ListActivity, ArrayAdapter, Button, Context, View, LayoutInflater, TextView…
Конечно, круто было бы написать, один и тот же код сразу для всех устройств. Но пока различия между ними большие и уровень абстракции настолько низок, что Mono — это для тех кто не хочет писать на Java для Android и не более того.
+1
Но пока различия между ними большие и уровень абстракции настолько низок, что Mono — это для тех кто не хочет писать на Java для Android и не более того.
Лично я в приведенном ТС примере вижу совместимость процентов на 80%. Основные различия кроются преимущественно в реализации GUI, которая заменяется контрактами на раз. Тема GUI вообще скользкая. Написанное на Java под Android
-1
портировать не проще, но может и не сложнее))
0
Я вот как раз и не вижу 80% совместимости, только модель RssReader'a. Xml layouts свои, вьюхи тоже. Тут, действительно, надо подумать, что проще — разрабатывать сразу под все или написать для одной и портировать под другую. А различия с iOS вообще кардинальны.
+1
Возможно мы по-разному смотрим. Я не рассматриваю реализацию ТС как эталон кросс-платформенности, а просто моделирую в уме, как бы я его реализовывал с прицелом на переносимость. А потом не акцентирую внимание на переносимости того, что непереносимо. Очевидно, что платформенные SDK диктуют нам ряд условностей, кросс-платформенных средств для которых просто нет. Иногда даже вспомогательные врапперы и прочие абстракции не помогут, когда UI, например, будет отличаться принципиально в силу специфики того или иного девайса.
В чем именно? В реализации бизнес-логики и прочей «математики», работе с бд, с сетью, криптография, XML, веб-сервисы — практически все одно и то же. Да, трединг, гуи имеют свою специфику, хотя по большей часть все те же виджеты. Просто для кого-то и между Button.Click += someHandler и UIButton.TouchDown += someHandler велика разница.
В общем не знаю, кому как, а мне все равно гораздо проще, когда больше половины кода (как тот же класс RssReader из примера) с основной логикой полностью переносимы, а оставшийся платформенный код я пишу на одном языке, чем писать абсолютно автономные приложения на разных. А уж про поддержку такого зоопарка я боюсь и думать. Правда все это при условии, что рантайм для C# & Co. работает близко к безупречному, потому как бороться на каждой платформе со своими граблями может оказаться себе дороже))
А различия с iOS вообще кардинальны.
В чем именно? В реализации бизнес-логики и прочей «математики», работе с бд, с сетью, криптография, XML, веб-сервисы — практически все одно и то же. Да, трединг, гуи имеют свою специфику, хотя по большей часть все те же виджеты. Просто для кого-то и между Button.Click += someHandler и UIButton.TouchDown += someHandler велика разница.
В общем не знаю, кому как, а мне все равно гораздо проще, когда больше половины кода (как тот же класс RssReader из примера) с основной логикой полностью переносимы, а оставшийся платформенный код я пишу на одном языке, чем писать абсолютно автономные приложения на разных. А уж про поддержку такого зоопарка я боюсь и думать. Правда все это при условии, что рантайм для C# & Co. работает близко к безупречному, потому как бороться на каждой платформе со своими граблями может оказаться себе дороже))
0
Можно значительно сократить время разработки не переписывая один и тот же код многократно. Чтобы не быть голословным, приведу пример из собственной практики. У меня сейчас есть приложения, написанные для Windows Phone 7 и Android. Оба приложения используют паттерн MVC. Так вот, оба приложения используют одну и ту же модель. В ней действительно не нужно менять ни строчки кода.
+1
А модель лежит где-то в общей папке? Или это один проект для Phone 7 и Android?
0
Модель находится в общей папке. В соответствующих solution есть отдельный проект (Mono for Android Class Library либо Silverlight Class Library). В этих проектах добавлены линки на файлы. Вообще линки на файлы — незаслуженно забытая вещь. Например, с их помощью можно создавать unit tests логики приложение для тех же Mono Android проектов.
0
Подскажите какой размер apk файла получился в данном проекте?
+4
5.34 MB
+1
Оу, а чего так много?
+1
Из-за того, что в пакет, кроме всего прочего, входят сборки для Mono Android.
Например, в этом пакете директория assemblies содержит:
Mono.Android, Mono.Security, mscorlib, System.Core, System, System.Xml, System.Xml.Linq
Например, в этом пакете директория assemblies содержит:
Mono.Android, Mono.Security, mscorlib, System.Core, System, System.Xml, System.Xml.Linq
+1
Довольно много…
Какая часть из этого пакета переносится андроидом на Flash?
Какая часть из этого пакета переносится андроидом на Flash?
-1
Если честно, не до конца понял ваш вопрос. Если вас интересует размер приложения после установки на аппарат, то он также достаточно большой — 9.71MB.
0
А можно пару слов, что получается в итоге и что выполняет платформа?
Т.е. если я пишу на Java, то получаю байт-код, который в Java и крутиться.
Если я пишу под Iphone на Obj-c, то я получаю нативный для IPhone код.
А что в этом случае?
Получается такой же нативный код или он крутиться в еще одной прослойке?
Т.е. если я пишу на Java, то получаю байт-код, который в Java и крутиться.
Если я пишу под Iphone на Obj-c, то я получаю нативный для IPhone код.
А что в этом случае?
Получается такой же нативный код или он крутиться в еще одной прослойке?
+1
А есть ли какая-нибудь выгода написания приложения на моно, вместо жавы?
0
Наверное общий код для разных платформ (исключая, конечно же, код GUI) плюс большое количество синтаксических сладостей в C#.
+2
Если кратко, то можно значительно сократить время разработки не переписывая один и тот же код многократно (для разных платформ). Ну и удобство для c# разработчиков, которые получили возможность писать приложения для Android используя привычный язык.
Более развернутые ответы также есть в комментариях выше.
Более развернутые ответы также есть в комментариях выше.
+3
Я правильно понял, что для того чтобы писать под Android на Mono нужен Windows или Mac, а Linux не годится?
Фантастика!
Фантастика!
0
А сколько это стоит? Я так понимаю мне нужно купить лицензию за 999 енотов? Если использовать Eclipse + Java то мне это будет стоит — бесплатно.
0
Не совсем. Писать приложения «для себя», с использованием эмулятора, можно бесплатно. Платить прийдется только тогда, когда есть планы продукт разместить на одном из маркетов. Для размещения в Android Market/Amazon Appstore приложения написанного на Mono Android, от лица компании, потребуется Enterprise версия ($999). Для размещения от собственного имени достаточно версии Professional ($399).
Это — плата за удобство. Хотите писать на c#? Выкладывайте денежки.
Это — плата за удобство. Хотите писать на c#? Выкладывайте денежки.
0
Не могли бы вы поделиться информацией о производительности подобных приложений на реалльных устройствах? Больше всего интересует время первого запуска приложения и общая отзывчивость программ, по сравнению с приложениями, напианных на Java.
+1
К сожалению, я и сам пока не располагаю подобной информацией. Визуально различий в скоростях я не заметил. Я сейчас как раз занимаюсь изучением вопросов производительности Mono Android. Как только появится какая-либо интересная информация (а она появится), я ею обязательно поделюсь. И скорее всего я вынесу ее в отдельный топик.
0
Прошло больше года :)
Можете поделиться накопленным опытом?
Можете поделиться накопленным опытом?
0
О да, время летит быстро :)
К сожалению, от Mono Android достаточно быстро я ушел в сторону простой разработки под Android на java.
Могу поделиться теми данными, которыми я располагаю (их мало, но лучше, чем ничего).
1) Скорость работы приложений сопоставима. Я имею в виду такое себе сферическое приложение в вакууме с десятком активити, сервисом, минимумом вычислений.
2) Размер apk. Вот тут моно проигрывает из-за необходимости тянуть за собой несколько либ. Готовый apk весит на порядок больше, чем apk собранный из java проекта. Собственно это и сыграло решающую роль.
Эта информация чуть менее, чем годичной давности, так что она могла уже и устареть.
Теперь же для классического Android + java очень много замечательных 3rd party либ (таких как ActionBarSherlock или HoloEverywhere). Для Моно, к сожалению, такого нет — комьюнити развито слабее :(
К сожалению, от Mono Android достаточно быстро я ушел в сторону простой разработки под Android на java.
Могу поделиться теми данными, которыми я располагаю (их мало, но лучше, чем ничего).
1) Скорость работы приложений сопоставима. Я имею в виду такое себе сферическое приложение в вакууме с десятком активити, сервисом, минимумом вычислений.
2) Размер apk. Вот тут моно проигрывает из-за необходимости тянуть за собой несколько либ. Готовый apk весит на порядок больше, чем apk собранный из java проекта. Собственно это и сыграло решающую роль.
Эта информация чуть менее, чем годичной давности, так что она могла уже и устареть.
Теперь же для классического Android + java очень много замечательных 3rd party либ (таких как ActionBarSherlock или HoloEverywhere). Для Моно, к сожалению, такого нет — комьюнити развито слабее :(
0
Sign up to leave a comment.
Articles
Change theme settings
Пишем первое приложение на Mono Android