Comments 19
А почему бы просто для общего ядра для wp7, monotouch, monodroid не написать разные *.csproj для одного и того же кода и референсить их? (без всяких add as link).
>Главная неожиданность: никаких генериков и никакой рефлексии.
Это не так. Есть и дженерики и рефлексия.
В дженериках не поддерживаются виртуальные методы.
Рефлексия работает, кроме рантайм генерации кода.
Это не так. Есть и дженерики и рефлексия.
В дженериках не поддерживаются виртуальные методы.
Рефлексия работает, кроме рантайм генерации кода.
Что касается дженериков – согласитесь, возможность переопределять виртуальные методы generic-типов – одно из их главных преимуществ в .NET. И отсутствие возможности реализовать IEnumerable очень сильно огорчает. Хотя тут да, вы правы, я погорячился, говоря что нет «никаких» генериков. Правильнее было бы сказать «большинства возможностей генериков».
На счет рефлексии – вы правы, тут я то же погорячился как и в предыдущем примере :) Однако согласитесь, вряд ли в клиентских приложениях потребуется сложная логика по анализу классов без возможности работы с их экземплярами. Лично мне не приходит в голову сценарий использования этого функционала.
На счет рефлексии – вы правы, тут я то же погорячился как и в предыдущем примере :) Однако согласитесь, вряд ли в клиентских приложениях потребуется сложная логика по анализу классов без возможности работы с их экземплярами. Лично мне не приходит в голову сценарий использования этого функционала.
Работать с их экземплярами тоже можно будет. Не стоит путать Reflection и Emit.
Reflection позволяет как инспектировать типы, так и создавать объекты нужного типа и вызывать произвольные методы. Все это возможно и на monotouch.
Emit же дает возможность комплировать код на лету в monotouch он не доступен, но в mono for android есть.
Reflection позволяет как инспектировать типы, так и создавать объекты нужного типа и вызывать произвольные методы. Все это возможно и на monotouch.
Emit же дает возможность комплировать код на лету в monotouch он не доступен, но в mono for android есть.
А можно попробовать разжевать для тупых? :) Ну т.е. вот у меня проект на C# под Win Phone, скажем. Какая должна быть последовательность шагов чтобы его заставить работать на других платформах? Какие встретятся подводные камни (ну, типа, «Если вы использовали ObservableCollection, то фиг вам а не моно»). Как могут себя повести сторонние компоненты? Как устроен GUI в портах моно и работает ли XAML (если работает, то как)?
Вот такая статья была бы очень полезна.
Вот такая статья была бы очень полезна.
Это огорчает больше всего.
А меня, как пользователя, это радует. Я не хочу в своём телефоне (будь то iPhone, wp7, android) видеть интерфейс от другой платформы. У каждой из платформ свои гайдлайны, свои особенности навигации, свой пользовательский опыт.
Как разработчику, конечно хочется написать один раз, если учесть предыдущий факт, то оптимально было бы один раз написать бизнес-логику и работу с сервером, а экраны уже на каждую раскидать.
эх мечты, мечты...
Как разработчику, конечно хочется написать один раз, если учесть предыдущий факт, то оптимально было бы один раз написать бизнес-логику и работу с сервером, а экраны уже на каждую раскидать.
эх мечты, мечты...
Особенности интерфейса можно было бы задать стилями, а заново писать все контролы + логику взаимодействия это значит писать с нуля 50% приложения. Учитывая, что у похожих сущностей на разных платформах могут быть свои милые особенности внутренних интерфейсов, которые не позволят осуществить даже простой порт привязки данных.
Задать стилями? Я не знаю как панораму WP7 поменяв стили, можно было бы превратить в связку из ТабБарКонтроллера и НавигейшенКонтроллеров в iOS. Это не десктоп, где такой подход с примитивными окошками мог бы работать.
Особенности интерфейса может и можно было бы задать стилями, но это значит что вы забываете об особенностях UX. Вам уже ответили про навигацию в панораме wp7, могу привести пример гайдов для андроида, где описана навигация не существующая ни на iPhone, ни на wp7.
Теоритически, вы можете создать интерфейс, который при помощи стилизации будет органично смотреться на всех трех платформах, но практически у вашего приложения будет ограниченный UX и вы заведомо проиграете в этом вопросе конкурентам, которые заточили приложение под конкретную платформу.
Теоритически, вы можете создать интерфейс, который при помощи стилизации будет органично смотреться на всех трех платформах, но практически у вашего приложения будет ограниченный UX и вы заведомо проиграете в этом вопросе конкурентам, которые заточили приложение под конкретную платформу.
В том то и дело, что проиграю с чужим UI я не заведомо, а лишь с какой-то вероятностью. Зато в принципе не выпустив приложение на других платформах (т.к. портирование стоит очень много усилий) я проиграю 100%
Если вы делаете очередное никому не нужное прилжение-рекламку, типа нафиг нам самим оно не надо, но это модно и что бы было, то да, вам интереснее использовать какой-нибудь phoneGap, а не писать все по 10 раз. Как только вы пишете что-то действительно нужное, вас начнут копировать. Понятно что в каждой конкретной ситуации нужно принимать отдельные решения, но ненативный интерфейс выглядит как издёвка над пользователем, а «стилизованный» попросту беден.
Почему мечты?
Моно какраз под такой сценарий и заточен — и подразумевает использование нативных компонентов на каждой системе.
Это не кроссплатформа в стиле Write Once — Run Everywhere, но я, как разработчик, готов платить эту цену за доступ ко всем возможностям каждой системы.
Моно какраз под такой сценарий и заточен — и подразумевает использование нативных компонентов на каждой системе.
Это не кроссплатформа в стиле Write Once — Run Everywhere, но я, как разработчик, готов платить эту цену за доступ ко всем возможностям каждой системы.
Можно и разжевать :)
Смотрите, при реализации кроссплатформенных приложений – главное, правильная архитектура, разделение кода на логические слои: GUI, бизнес-логика, слой коммуникации. В данной статье я по сути описал именно алгоритм создания такого слоя коммуникации.
Что же касается GUI – тут все плохо: для каждой платформы пишется свой GUI. Но если грамотно спроектировать приложение, то вам по сути и придется, что только перерисовать несколько вьюшек, если конечно не шибко замудренный интерфейс.
ObservableCollection — можно, но осторожно, все упирается в отсутствие нормальной поддержки generic-типов. :) Так что если вы будете работать с ObservableCollection как с необобщенной коллекцией – то попробовать можно, хотя я этого делать крайне не рекомендую. Лично я для этого написал свой класс, который реализует все не типизированные интерфейсы ObservableCollection, и горя не знаю:)
На счет XAML – должен вас огорчить. По сети давно ходят слухи, что некие энтузиасты работают над таким решением, но рабочего решения я так и не видел. Однако не все так печально: нативные библиотеки iOS и Andorid весьма богаты функционально и просты в использовании. А учитывая гайды по построению пользовательских интерфейсов – для каждой платформы должен быть свой интерфейс, учитывающий специфику платформы (поверьте, iOS пользователь, увидев на Айпаде Metro-интерфейс на долго впадет в ступор и врядли заъочет использовать ваше приложение).
Если эта тема в самом деле интересна – я могу написать по ней еще несколько статей.
Смотрите, при реализации кроссплатформенных приложений – главное, правильная архитектура, разделение кода на логические слои: GUI, бизнес-логика, слой коммуникации. В данной статье я по сути описал именно алгоритм создания такого слоя коммуникации.
Что же касается GUI – тут все плохо: для каждой платформы пишется свой GUI. Но если грамотно спроектировать приложение, то вам по сути и придется, что только перерисовать несколько вьюшек, если конечно не шибко замудренный интерфейс.
ObservableCollection — можно, но осторожно, все упирается в отсутствие нормальной поддержки generic-типов. :) Так что если вы будете работать с ObservableCollection как с необобщенной коллекцией – то попробовать можно, хотя я этого делать крайне не рекомендую. Лично я для этого написал свой класс, который реализует все не типизированные интерфейсы ObservableCollection, и горя не знаю:)
На счет XAML – должен вас огорчить. По сети давно ходят слухи, что некие энтузиасты работают над таким решением, но рабочего решения я так и не видел. Однако не все так печально: нативные библиотеки iOS и Andorid весьма богаты функционально и просты в использовании. А учитывая гайды по построению пользовательских интерфейсов – для каждой платформы должен быть свой интерфейс, учитывающий специфику платформы (поверьте, iOS пользователь, увидев на Айпаде Metro-интерфейс на долго впадет в ступор и врядли заъочет использовать ваше приложение).
Если эта тема в самом деле интересна – я могу написать по ней еще несколько статей.
Не очень понял в чем смысл статьи если честно!
У разработчиков на net есть большой опыт написание библиотек для разных платформ WPF,SL,WP7. Вроде для тех кто писал кроссплатформенные сборки все очевидно
Делали сборку под каждую версию и определяли в них conditional compilation symbols специфичные для платформы а далее писали ровно следующее
#if NET
//net framework spec code
#endif
#if SL
//sl spec code
#endif
Так было с появления sl. Все прекрастно понимали что эти фреймворки не совсем одно и тоже. Что есть определенные множества пересекающиеся и не пересекающиеся.
Фактически Вы написали очень много текста, который легко сворачивается в 1 абзац
Написать 100% переносимую сборку не реально, если она сложнее hello world хоть на миллиметор
У разработчиков на net есть большой опыт написание библиотек для разных платформ WPF,SL,WP7. Вроде для тех кто писал кроссплатформенные сборки все очевидно
Делали сборку под каждую версию и определяли в них conditional compilation symbols специфичные для платформы а далее писали ровно следующее
#if NET
//net framework spec code
#endif
#if SL
//sl spec code
#endif
Так было с появления sl. Все прекрастно понимали что эти фреймворки не совсем одно и тоже. Что есть определенные множества пересекающиеся и не пересекающиеся.
Фактически Вы написали очень много текста, который легко сворачивается в 1 абзац
Написать 100% переносимую сборку не реально, если она сложнее hello world хоть на миллиметор
Sign up to leave a comment.
Сетевая недокроссплатформенность