Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
Нужно больше золота… )
В некоторую, может быть, защиту, перескажу слова знакомого. Обновления под iOS/Android все равно нужны ежегодно, потому что постоянно обновляются ОС. Потому они все равно будут покупаться. С другой стороны, если нужен только саппорт, а впереди тишина и ни одного заказа, можно оставить только одну лицензию на платформу на билд сервере и собирать там.
Так что… отключите вентилятор :)
Так что… отключите вентилятор :)
Я согласен. Обновления нужны, да и работать со свежей версией всегда приятно. Вон например поддержка PCL появилась.
Вопрос только в том кто им нужен. Либо это сотня крупных компаний и куцее комьюнити, тогда цена ок, либо это широкое международное комьюнити и тогда цена совсем не ок.
И конечно молчание. Я вообще обо всем этом узнал постфактум, случайно! Это не серьезный подход…
Вопрос только в том кто им нужен. Либо это сотня крупных компаний и куцее комьюнити, тогда цена ок, либо это широкое международное комьюнити и тогда цена совсем не ок.
И конечно молчание. Я вообще обо всем этом узнал постфактум, случайно! Это не серьезный подход…
Все почти так.
Я думаю, что для iOS реально будет возможно использовать Xamarin в течение еще примерно 1 года после последнего обновления. По истечение года есть высокая вероятность, что Apple перестанет принимать приложения собарнные старой версией Xamarin, потому, что… (теперь надо и 64 бита обязательно, теперь уже нельзя armv7, теперь надо собирать еще и с такими-то сертификатами, таким-то иконками, таким-то молитвами) нужное по вкусу.
Поэтому, если проект развивается, то Xamarin нужно обновлять регулярно. А если у проекта только небольшая поддержка, то через год или проект придется закрыть или все таки продлить лицензию Xamarin.
Но вот для Android все не так. Таких сложностей, как в iOS нет. Я думаю, что возмущались именно Андроид разработчики :))
Я думаю, что для iOS реально будет возможно использовать Xamarin в течение еще примерно 1 года после последнего обновления. По истечение года есть высокая вероятность, что Apple перестанет принимать приложения собарнные старой версией Xamarin, потому, что… (теперь надо и 64 бита обязательно, теперь уже нельзя armv7, теперь надо собирать еще и с такими-то сертификатами, таким-то иконками, таким-то молитвами) нужное по вкусу.
Поэтому, если проект развивается, то Xamarin нужно обновлять регулярно. А если у проекта только небольшая поддержка, то через год или проект придется закрыть или все таки продлить лицензию Xamarin.
Но вот для Android все не так. Таких сложностей, как в iOS нет. Я думаю, что возмущались именно Андроид разработчики :))
Больше золота, больше!
Glittering prizes. Zug-zug
Статья тролля
На самом деле, 1000 в год с разработчика. Те 12 тысяч — с 12-ти разработчиков. Это раз. Второе — будьте честны при расчетах :) Три платформы? Те на iOS/Android и… Mac? :) WinPhone — то остается под Vusial Studio + Windows… те если говорить о мобильной разработке, то платформы — две
Таким образом, если у вас 4 разработчика и на каждого необходима лицензия скажем на 3 платформы по 999$ то вы тратите 12 000$ в год только на возможность разработки/доработки/обновления
На самом деле, 1000 в год с разработчика. Те 12 тысяч — с 12-ти разработчиков. Это раз. Второе — будьте честны при расчетах :) Три платформы? Те на iOS/Android и… Mac? :) WinPhone — то остается под Vusial Studio + Windows… те если говорить о мобильной разработке, то платформы — две
У вас цитаты по тексту, похоже, местами перепутаны, по статье как будто они сперва опубликовали плохую новость, а потом уже хорошую.
До 1 ноября там было написано следующее
Your Xamarin license is perpetual. If you choose not to renew your subscription, you will no longer have access to new releases and support, and we will be very sad.
Вместо старого порядка лицензирования в FAQ появился новый порядок:
Your apps will continue to run even after your subscription has expired. You must have an active subscription in order to build or deploy your app.
Получается новый порядок лучше чем старый, народ запутываете.
До 1 ноября там было написано следующее
Your Xamarin license is perpetual. If you choose not to renew your subscription, you will no longer have access to new releases and support, and we will be very sad.
Вместо старого порядка лицензирования в FAQ появился новый порядок:
Your apps will continue to run even after your subscription has expired. You must have an active subscription in order to build or deploy your app.
Получается новый порядок лучше чем старый, народ запутываете.
мм, вроде нет или я не понял замечания.
До первого ноября было «Xamarin license is perpetual.» потом стало «You must have an active subscription in order to build or deploy your app.» (что хуже)
До первого ноября было «Xamarin license is perpetual.» потом стало «You must have an active subscription in order to build or deploy your app.» (что хуже)
До 1 ноября, ( If you choose not to renew your subscription, you will no longer have access to new releases and support,) если вы выбираете НЕ обновлять лицензию у вас пропадают плюшки.
Новый порядок, (Your apps will continue to run even after your subscription has expired. ) вы сможете билдить даже после того как истечет лицензия — что помоему лучше гораздо.
Новый порядок, (Your apps will continue to run even after your subscription has expired. ) вы сможете билдить даже после того как истечет лицензия — что помоему лучше гораздо.
Нет, там написано другое.
До 1 ноября: «лицензия перманентная. вы не будете получать новые релизы и обновления если не подписаны»
Новый порядок: «ваше приложение продолжит работать (у Xamarin защита на триалке, программа запускается только 30 минут), вам нужна активная подписка для построения и обновления ПО.»
Видимо я все-таки не достаточно четко описал это
До 1 ноября: «лицензия перманентная. вы не будете получать новые релизы и обновления если не подписаны»
Новый порядок: «ваше приложение продолжит работать (у Xamarin защита на триалке, программа запускается только 30 минут), вам нужна активная подписка для построения и обновления ПО.»
Видимо я все-таки не достаточно четко описал это
Все, я понял, тупанул. Не правильно контекст себе представил, извиняюсь.
> Your apps will continue to run
Ваши (уже собранные) приложения не перестанут запускаться, но
> You must have an active subscription in order to build
собрать вы их уже не сможете.
Ваши (уже собранные) приложения не перестанут запускаться, но
> You must have an active subscription in order to build
собрать вы их уже не сможете.
Ещё когда Мигель де Иказа только начал продвигать Mono как свободный вариант .net для линукса, все уже тогда смотрели на проект косо и предсказывали что обернётся это «анальным рабством». И хоть пока не с той стороны, откуда ожидали, но кажется так и вышло.
Да ладно, с Mono никаких проблем нет, новые релизы выходят регулярно, поддержка всего нужного на уровне. Xamarin Studio же изначально платный продукт, за который с самого начала просили деньги. Студия (самая полная версия) вон 10К на разработчика стоит, вас это почему-то не возмущает.
если бы студия стоила на разработчика 30к в год за платформу то это бы тоже вас возмутило я думаю
вообще если брать не-Windows хост, а Mac, то получится другая картина. iOS+Android (WinPhone брать не буду тк не особо популярен в заказах на аутсорсе) = $400 / год.
Если брать Visual Studio online (тоже подписка), получим 45*12 = $540
т.е. надо как-то более корректно сравнивать что-ли )
Если брать Visual Studio online (тоже подписка), получим 45*12 = $540
т.е. надо как-то более корректно сравнивать что-ли )
У VS функций больше, но она под винду. Для iOS/Android разработки Xamarin (имхо) лучшее что есть и платить есть за что. Так что кругом одни вопросы ) Дорого, да. Но слишком ли дорого?
Ну смотря что понимать под словами «проблем нет». С технической точки зрения да. Но вот вздумалось мне встроить её в качестве скриптового движка в уже готовое приложение для Android и тут возник пункт соглашения, что я должен получить разрешение у Xamarin. А на письмо мое они так и не ответили. Для PC таких ограничений, насколько мне известно, нет.
Но вот вздумалось мне встроить её в качестве скриптового движка в уже готовое приложение для AndroidРантайм-то? Встраивайте сколько угодно он под GPL. У вас ведь приложение тоже под GPL, правда?
Рантайм под LGPL 2.0 лицензией.
Но дело не в этом. Если когда-нибудь приложение доползет до релиза видно будет.
Я просто сказал, что Мигель советовал использовать Mono как скриптовый движок и это звучит привлекательно, но на деле такой возможности нет. Для iOS LGPL, очевидно, не пойдет, но и не о нем речь.
The runtime libraries are under the GNU Library GPL 2.0 (LGPL 2.0).
Но дело не в этом. Если когда-нибудь приложение доползет до релиза видно будет.
Я просто сказал, что Мигель советовал использовать Mono как скриптовый движок и это звучит привлекательно, но на деле такой возможности нет. Для iOS LGPL, очевидно, не пойдет, но и не о нем речь.
Я всё ещё не понимаю, в чём ваша проблема, если рантайм под LGPL, а реализация фреймворка вообще под MIT. При таких условиях распространения спрашивать разрешения ни у кого не надо.
Хм. Смущала строчка в лицензионном соглашении
Но после вашего комментария дошло, что на Android как раз ограничение не распространяется. А вот на iOS вполне себе. В любом случае я уже большую часть его переписал на Xamarin.Android с целью потом портировать на другие платформы.
We only require licensing for uses of Mono and Moonlight on embedded systems, or systems where you are unable to fulfill the obligations of the GNU LGPL
Но после вашего комментария дошло, что на Android как раз ограничение не распространяется. А вот на iOS вполне себе. В любом случае я уже большую часть его переписал на Xamarin.Android с целью потом портировать на другие платформы.
Но крутого WPF нету и не планируется, есть только winforms. А на них солжный интерфейс, насколько я понимаю, не соберёшь.
1) Используйте нативные для *nix тулкиты, GTK и Qt, к ним есть вполне приличные биндинги (пакеты к Qtшным, правда, в убунте вечно сломаны, надо за собой таскать)
2) На WinForms можно сделать очень сложный интерфейс, но для этого вам надо уметь клепать свои виджеты, отрисовывая их через System.Drawing.
2) На WinForms можно сделать очень сложный интерфейс, но для этого вам надо уметь клепать свои виджеты, отрисовывая их через System.Drawing.
1) Наверное, да — но я вот не уверен, что вот такое
легко сделать на GTK.
2) Ну, мне кажется это гемор, нет? Хочется как в андроиде — мышкой покликал и готово.
легко сделать на GTK.
2) Ну, мне кажется это гемор, нет? Хочется как в андроиде — мышкой покликал и готово.
Может, Вы прямо покажете, какие современные биндинги есть к Qt? В своё время я много времени потратил на «самый лучший» от проекта KDE — так и не завелись у меня на более-менее современном Qt.
К потоку нехороших слов, которые я подумал в их адрес, но не стал тут писать, ещё надо добавить пару слов о новом MonoDevelop 4. Неоттестированный, тормозной (даже на i7 с SSD тормозит, мак ос), просто ужас, почитал в интернетах я не одинок в своих мучениях с этой хренью, и никто толко не знает что сделать чтобы не тормозило (если знаете — напишите мне).
А вообще очень хороший проект, будет жалко, если загнётся или станет недоступным по цене.
Им бы конкурентов бы штук несколько.
А вообще очень хороший проект, будет жалко, если загнётся или станет недоступным по цене.
Им бы конкурентов бы штук несколько.
Дешевле изучить Objective-C.
К сожалению, после C#, Objective-C выглядит СТРАШНО. Прям как обратно к C++ возвращаешься.
Писал я на Objective-C после C#, для меня порог вхождения оказался необычно высок, но справился, плюшки языка заметил (нативная связь с C, есть блоки (те же лямбды), скорость), но подсчёт ссылок убивает..:) Скажу, что возвращаться НЕ хочется, НО деньги около этого языка крутятся немалые. С++ нынче довольно крут стал, вот думаю посмотреть на него снова. С плюсами хоть нормальная кроссплатформенность (QT).
>> (QT)
Вообще — Qt, а QT — это Quick Time…
>> С плюсами хоть нормальная кроссплатформенность (QT)
В С++ и без Qt нормальная кроссплатформенность. А, учитывая возможности стандарта С++11, так вообще сказка))
>> С++ нынче довольно крут стал
Мне понравился Managed C++ для Windows 8/Windows Phone приложений. Можно писать на С++/XAML и C++/DirectX. И даже в C# приложениях через Managed C++ использовать NATIVE код… Никто не знает, насколько это востребовано, стоит ли уделять время?
Вообще — Qt, а QT — это Quick Time…
>> С плюсами хоть нормальная кроссплатформенность (QT)
В С++ и без Qt нормальная кроссплатформенность. А, учитывая возможности стандарта С++11, так вообще сказка))
>> С++ нынче довольно крут стал
Мне понравился Managed C++ для Windows 8/Windows Phone приложений. Можно писать на С++/XAML и C++/DirectX. И даже в C# приложениях через Managed C++ использовать NATIVE код… Никто не знает, насколько это востребовано, стоит ли уделять время?
C++ без QT — это миллион разных реализаций строк и контейнеров (кстати не знаю откуда вы взяли что camel case имя меняет контекст).
Managed C++ — они переколбашивают синтаксис языка почти каждый релиз Visual Studio — потому на managed c++ ничего серьезного не поделаешь, максимум обвязки для unmanaged кода, причем только в тех случаях, когда особо нет возможности переделать интерфейсы unmanaged части.
Managed C++ — они переколбашивают синтаксис языка почти каждый релиз Visual Studio — потому на managed c++ ничего серьезного не поделаешь, максимум обвязки для unmanaged кода, причем только в тех случаях, когда особо нет возможности переделать интерфейсы unmanaged части.
Где вы такой C++ берёте, что без QT у вас миллион реализаций строк и контейнеров? Неужто так STL'ных не хватает? Мне вот вообще с QT не приходилось сталкиваться в работе, да и не хочется как-то — очередная большая довольно таки монолитная байда с большим рантаймовым довеском. Уж проще даже Буст подключить если хайтек хочется. Там вам и строковые функции дополнительные, и контейнеры и прочая-прочая. При этом большая часть хидер онли и можно вычленить отдельные модули.
+1. Я вообще не понимаю, почему при совмещении понятий «С++» и «Кроссплатформенная разработка» все сразу вспоминают Qt… Я не против, инструмент довольно крутой и мощный, но одним Qt дело-то не ограничивается…
Вы на 100% уверены что реализация STL для g++ абсолютно совместима с релаизацией для cl(Майкрософт), это для примера. Я вот нет.
Я скорее буду уверен в STL, нежели в любой «левой» библиотеке. STL работает с какого года? И когда появились boost или Qt?
И ответ на Ваш вопрос: я писал кроссплатформенное ПО, и та часть STL, которую мы использовали — работает везде: и на Windows (MSVS/MinGW), и на Linux (g++), и на MacOS (clang)
И ответ на Ваш вопрос: я писал кроссплатформенное ПО, и та часть STL, которую мы использовали — работает везде: и на Windows (MSVS/MinGW), и на Linux (g++), и на MacOS (clang)
И конечно же это повод притащить в проект Qt и пачку yes-another-containers-and-strings вместе с ним. Ну и я не припоминаю живых проблем жесткой несовместимости G++ и MSVC актуальных (не старше пятилетней давности) версий. Какие-то мелочи решаются ifdef'ами, смотрим как это делает Буст опять же. Скорее проблемы с STL могут быть на каких-то других более экзотических компиляторах/платформах со старыми или такими же кастомно-экзотическими CRT/STL. Но на них вероятно и у Qt будут проблемы.
Qt конечно можно использовать, но уж точно не только и не столько ради альтернативных контейнеров со строками. Такое уж если берёшь, то уже оттуда надо брать всё и дороги назад нет. В своей области (геймдев) я бы его взял писать редакторы и тулзы с гуи. И то, если бы требовалась задача линковаться с движком или использовать его бинарные структуры данных. Иначе бы вообще C# с .Net взял бы.
Qt конечно можно использовать, но уж точно не только и не столько ради альтернативных контейнеров со строками. Такое уж если берёшь, то уже оттуда надо брать всё и дороги назад нет. В своей области (геймдев) я бы его взял писать редакторы и тулзы с гуи. И то, если бы требовалась задача линковаться с движком или использовать его бинарные структуры данных. Иначе бы вообще C# с .Net взял бы.
Да это только мое предположение было — таблици виртуальных функций например у студии и MinGW несовместимы (да они и у разных версий MinGW несовместимы — можно много шишек набить если есть библиотеки динамической линковки), Кто интересовался темой тот видел что один и тот же код на GCC и Студии разворачивается в неодинаковые последовательности Ассемблерных комманд (даже если оптимизацию отключить) — а раз есть различия на уровне машинных комманд, то почему не может быть различия и на уровне библиотек поставки (Ну там разночтения стандарта, замена недоописанного фантазиями).
Да конечно могут быть. Но они могут быть везде и во всём, и даже с Qt. Применение STL тут сильно картину не меняет. Ну вот скажем начнёшь линковать что-то писаное под Qt и собраное MSVC и пытаешься влинковать другой собранный уже модуль вроде бы тоже с Qt, но сделанное в MinGW — будут сюрпризы. Там даже не только таблицы виртуальных функций вылезут, банально разные юзаемые CRT уже дадут почти наверняка нерабочий билд, почти наверняка оно просто не слинкуется, если это статик линковка на уровне lib файлов. Поэтому, MSVC сборки и MinGW сборки надо считать не просто разными компиляторами, а разными платформами, так же как и сборку под Qt+некий компилер. И если релизишь какую статическую закрытую библиотеку под это всё, то делать разные версии под всё. С DLL проще, если соблюдать некоторые правила.
Вообще, подобные проблемы состыковки несовместимости бинарных модулей собранных под винду неплохо решал COM, но его всё меньше применяют. А тот же MinGW с MSYS это вообще такой отдельный мир, совсем отдельная среда, такой себе Posix слой под виндой. Но и на нём можно писать COM-модули при желании.
Вообще, подобные проблемы состыковки несовместимости бинарных модулей собранных под винду неплохо решал COM, но его всё меньше применяют. А тот же MinGW с MSYS это вообще такой отдельный мир, совсем отдельная среда, такой себе Posix слой под виндой. Но и на нём можно писать COM-модули при желании.
>> Managed C++ — они переколбашивают синтаксис языка почти каждый релиз Visual Studio
Managed C++ — это старый набор расширений для написания managed кода на плюсах, который появился в VS 2002, и стал deprecated в VS 2005. Там все ключевые слова были с подчеркиваниями — __gc и так далее.
C++/CLI — это новый набор расширений для того же, но более грамотно задизайненый на основе печального опыта с MC++. Он появился в VS 2005, заменив собой МС++, и с тех пор не изменялся — т.е. синтаксис и семантика там стабильны уже 5 релизов VS как (2005, 2008, 2010, 2012, 2013). На нем вполне можно спокойно «поделать что-то серьезно» — другой вопрос, что для .NET шарп все равно удобнее, поэтому C++/CLI так и остается в основном языком для создания обвязок вокруг нативных библиотек.
C++/CX, который для Windows Store — это вообще другая вещь, не имеющая отношения ни к MC++, ни к C++/CLI, поскольку она заточена под нативный код. Синтаксис там процентов на 90 взят из C++/CLI, но это не замена последнему.
Managed C++ — это старый набор расширений для написания managed кода на плюсах, который появился в VS 2002, и стал deprecated в VS 2005. Там все ключевые слова были с подчеркиваниями — __gc и так далее.
C++/CLI — это новый набор расширений для того же, но более грамотно задизайненый на основе печального опыта с MC++. Он появился в VS 2005, заменив собой МС++, и с тех пор не изменялся — т.е. синтаксис и семантика там стабильны уже 5 релизов VS как (2005, 2008, 2010, 2012, 2013). На нем вполне можно спокойно «поделать что-то серьезно» — другой вопрос, что для .NET шарп все равно удобнее, поэтому C++/CLI так и остается в основном языком для создания обвязок вокруг нативных библиотек.
C++/CX, который для Windows Store — это вообще другая вещь, не имеющая отношения ни к MC++, ни к C++/CLI, поскольку она заточена под нативный код. Синтаксис там процентов на 90 взят из C++/CLI, но это не замена последнему.
Managed C++ не взлетел в своё время, не думаю, что взлетит сейчас. Хотя надо глянуть чего там намутили.
Это не Managed C++, а C++/CX. Managed в нем ничего нет, там все полностью компилируется в нативный код, и тоже кстати с подсчетом ссылок для объектов. Похожего в нем только то, что синтаксис по большей части взят от C++/CLI.
Для WP не обязательно использовать Managed C++, достаточно использовать RT расширение(в качестве синтаксического сахара) а можно даже без них, только прийдеться вспоминать что такео COM
Ну он же не сказал «приятнее». Он сказал «дешевле».
И что? Получится писать кроссплатформенные приложения? Я уж не говорю о синтаксисе.
Уж лучше сразу застрелиться.
Так и знал, что будет подвох.
«4 разработчика и на каждого необходима лицензия скажем на 3 платформы по 999$ то вы тратите 12 000$ в год только на возможность разработки/доработки/обновления.»
Пример высосан немного из пальца. Для доработки вполне хватает по одной лицензии на каждую платформу.
4 разработчика одновременно на трех платформах — это уже мегакорпорация. Я уже не говорю что одну лицензию можно использовать на 4х компьютерах…
Пример высосан немного из пальца. Для доработки вполне хватает по одной лицензии на каждую платформу.
4 разработчика одновременно на трех платформах — это уже мегакорпорация. Я уже не говорю что одну лицензию можно использовать на 4х компьютерах…
Примерно такое же с Мармаладом происходит — лицензия каждый год становится дороже и обрастает всё большим количеством условий. А качество продукта и особенно поддержки идёт вниз.
Обычно отличие подписки на средства разработки от покупки конкретной версии в том, что может использоваться любая из версий и апдейтов, вышедших в период подписки. Если подписка закончилась, новые версии и апдейты недоступны. Лишать работоспособности купленный ранее продукт — это шантаж. При этом текущих подписчиков не уведомили об изменениях в условиях подписки, и вообще запрятали их поглубже. К тому же, при таких изменениях и цена должна была уменьшиться.
Уточню только, после поднятия бучи xamarin отговорился тем что существующие подписчики сохранят старый порядок лицензирования и только новые подписчики будут работать по новой лицензии. Однако тех кто был на evaluate и решал использовать или нет продукт — разные тимлиды или одиночки, тех да, не уведомили об этом и это их тоже возмутило
А если 56 разработчиков по 3 платформы, так и вообще 168 тыщ! Надо было так и написать — «Стоимость Xamarin — 168 тыщ баксов в год!»
Заголовок желтушный дальше некуда. Я не пользовался этим продуктом, но просветите меня, четко и нормально, что было раньше? Покупал лицензию на год? а после не получал новых обновлений, но мог на старом разрабатывать? По новым правилам стало, что и билдить нельзя даже на старой купленной версии?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Драма которая прошла мимо нас, или как Xamarin захотел 12000$ в год с клиента