Идем в обход: альтернативные платформы разработки под iOS
Примечание от редакции. Мы продолжаем публиковать материалы, связанные с программированием под девайсы Apple. Сегодняшнюю статью по просьбе AppleInsider подготовил ведущий разработчик компании Parallels Александр Швецов (на фото). Он хорошо знаком с платформой iOS еще по самому первому «Айфону», ну и, конечно, по работе над несколькими версиями Parallels Desktop для Mac, как известно, самого производительного и быстрого приложения для запуска Windows на Mac. Данной заметкой мы открываем подборку статей «для продвинутых». Обращаем внимание читателей на то, что вы можете задать автору вопросы или предложить новую тему для материала. Приятного чтения!
iOS уже далеко не новая платформа.«Кул хацкеры» (а с ними и автор этих строк), ломавшие выпущенные эксклюзивно для AT&T iPhone первого поколения, следуя, разумеется, окольными путями, писали под них еще в 2007-м, да и «цивильный» способ разработки — официальный SDK — вышел уже около трех лет назад. Но речь сегодня пойдет не о нем, а об альтернативных средствах разработки.
Для того, чтобы отвернуться от традиционных Objective-C и Cocoa Touch, может быть много причин — кросс-платформенность, существующие наработки, опыт, команда, или просто предпочтения. Но главное — для этого шага есть много возможностей: Corona, Unity, Appcelerator, PhoneGap, MonoTouch, XnaTouch, BatteryTech, или даже «хардкорный» C. И хотя у нас в Parallels и Cocoa, и Cocoa Touch активно используется (как в Parallels Desktop, так и в Parallels Mobile), не буду скрывать: лично мне Objective-C не нравится, Почему? Да потому что Apple делает свои продукты исключительно для пользователей, а к разработчикам поворачивается тем местом, что находится пониже поясницы. Другими словами, в фирменных продуктах Apple для девелоперов нет ни нормальной среды разработки, ни вменяемой документации. Поэтому я расскажу обо всех альтернативах, которые я сумел найти и попробовать, прежде чем нашел удобное и кросс-платформенное решение.
Corona
http://www.anscamobile.com/corona/
Разработчики каждой платформы очень хотят кушать и ездить на хороших немецких машинах, поэтому Corona SDK платный. Стоит она $199 на iOS, $349 — на iOS и Android. Платить нужно только за возможность публикации в AppStore и Android Marketplace (как бонус — доступ к закрытым разделам форума и ежедневным сборкам). А разработка, включая отладку на устройстве при наличии подписки ADC, бесплатна.
Единственный язык программирования, поддерживаемый Короной — Lua, которая, на мой взгляд, есть нечто среднее между JavaScript, ActionScript и Delphi (правда, команда “end” почему-то используется без “begin”). Одним словом — на любителя.
Впрочем, и сама платформа — на любителя. Делать на ней можно только игры, причем только двумерные. Приложение с нативным интерфейсом с помощью «Короны» сделать не получится.
Почитать туториал и посмотреть на примеры можно у них же на сайте — http://developer.anscamobile.com/resources/docs/.
Unity3D
«Юнити» — это и мощный кросс-платформенный движок, и кросс-платформенная среда разработки (интегрированная с MonoDevelop или VisualStudio под Windows), и конвертер всевозможных форматов ресурсов, и симулятор. А еще сервер ресурсов (если захотите сделать свой World of Warcraft). А в довесок — магазин ресурсов для независимых разработчиков.
Есть только одно “но”. «Юнити» — самое дорогое из решений. Бесплатно доступна только разработка под Windows и Mac (включая браузерные игры), для разработки под iOS придется отдать от $400 до $3000 (за свой сплеш-скрин, плагины, аудиофильтры и пиксельные шейдеры), Android обойдется столько же, а цена за полный кросс-платформенный комплект — $4500!!! Другими словами — платформа серьезная, и по меркам независимых разработчиков стоит изрядных денег. Получить качественный и многофункциональный инструментарий на халяву не получится – будущим «убийцам Angry Birds» стоит это учесть. Стоимость исходного кода, ученических лицензий и лицензии для разработки под консоли не разглашается. Для всех версий, конечно же, есть триал на 30 дней.
При разработке под мобильные платформы можно использовать два распространенных языка — JavaScript и C#, для настольных игр — еще и Boo, который весьма похож на Python.
Разобраться в «Юнити» непросто, а рассказать о ней во всех подробностях в рамках этой статьи — просто невозможно. Для тех, кто все-таки решится попробовать этого гиганта на зуб, советую начать с основ (http://unity3d.com/support/documentation/Manual/Unity%20Basics.html), поучить интерфейс, а потом взяться за мой любимый туториал по созданию трехмерного платформера — http://unity3d.com/support/resources/tutorials/3d-platform-game.
PhoneGap
Хоть создатели PhoneGap и не сознаются, но идея их детища явно навеяна Palm WebOS, само название которой говорит нам о том, что разработка под нее сродни созданию веб-приложений. Но, в отличие от WebOS, PhoneGap мне совершенно не нравится, и я бы не советовал его использовать. Почему? Потому что приложения на PhoneGap — это по сути полноэкранный браузер, внутри которого доступны некоторые «хвосты» наружу — к файловой системе, сети или геолокации. Лучше попробуйте Appcelerator.
Но раз платформа существует, значит, это кому-нибудь нужно. А если это кому-то нужно, значит, платформа достойна внимания. Как минимум интересен тот факт, что команда PhoneGap работает над облачным сервисом сборки и упаковки приложений — http://build.phonegap.com/, в том числе включающий поддержку iOS, а это значит что с помощью PhoneGap можно будет писать под iOS без Мака.
Appcelerator
«Аппселератор» я обнаружил случайно попробовав одно из приложений написанных с его помощью — Wunderlist. Привлекло меня в первую очередь то, что для разработки приложений используется лаконичный JavaScript, а сама платформа на 90% бесплатна. Платить придется только за расширенную техническую поддержку, модули для платежных систем, штрих-кодов и омнитуру.
Но самое удивительное в этой платформе то, что приложения построенные на ней не просто выглядят нативно и на Android, и на iOS, они и есть нативные: вы создаете кнопку средствами JavaScript, а рисует ее сама iOS.
Начать изучение «Аппселератора» стоит с классического «Getting Started» — http://wiki.appcelerator.org/display/guides/Getting+Started+with+Titanium, постепенно переходя к использованию документации по API — http://developer.appcelerator.com/apidoc/mobile.
MonoTouch и XnaTouch
http://monotouch.net/ и http://monogame.codeplex.com/
«Моно», как открытый порт Microsoft .NET разрабатывается с начала 2000-х. При активной поддержке Novel «Моно» начала особенно активно развиваться после открытия Microsoft исходного кода их фреймворка, а так же публикации стандартов языка C# под открытой лицензией. Это отличный проект.
Но с мобильными версиями — MonoTouch, Mono for Android — явно что-то не так. С первого взгляда — мощный и функциональный инструмент, но почему тогда на нем нет достойных приложений? Непонятно. Пока что я бы посоветовал использовать его только для портирования приложений с Windows или Windows Phone, а писать новое приложение на MonoTouch пока бы не стал.
BatteryTech
http://www.batterypoweredgames.com/batterytech
BatteryTech, как заявлено, — это высокопроизводительный фреймворк для iOS и Android, построенный на понятии игровых объектов и использующий C++. Я очень старался связаться с создателями этой платформы, что бы узнать, а потом и рассказать подробнее об этой платформе, но не получилось — почта молчит, а копирайты обновлялись последний раз аж 2 года назад. Хотя официальная страница проекта на Facebook время от времени подает признаки жизни.
Что еще?
Сообщество Qt портирует Lighthouse и Quick на Android и iOS. Appcelerator получает большой объем инвестиций, покупает платформу для разработки веб-приложений и планирует покорять Blackberry (бета уже доступна для платных подписчиков) и Windows Phone 7. А Unity3D идет на консоли третьего поколения.
Тщательно все взвесив, для себя я сделал выбор — Appcelerator для обычных приложений и Unity3D для игр. Именно об этих инструментах, а так же Objective-C и даже о проблемах, возникающих уже после выпуска своего приложения, я с радостью готов рассказывать в будущих заметках.
Кстати, вопросы и идеи для будущих статей в комментариях всячески приветствуются!
![[Стив Джобс. Биография.] Глава 33. Часть третья. Развод.](http://www.appleinsider.ru/wp-content/uploads/2012/05/jobs1-50x50.jpg "[Стив Джобс. Биография.] Глава 33. Часть третья. Развод.")
Спасибо, большое Александр.
Все что надо расписали, пищу для размышлений подкинули.
Был рад!
Надеюсь поделитесь результатом «переваривания»? +)
Аффтар, пеши исчо!))
А если серьезно, то к списку я бы monoTouch добавил- причем, в варианте, как сделать кросс-платформенный backend приложения со специфической мордой для десктопа (win/Mac) и мобильных платформ (iOS, android). Ну и к вопросу отсутствия софта на моно в маркетах-андроидный моно вышел вот этой зимой, он еще реально сырой!
Постараюсь писать регулярно +)
По поводу MonoTouch можно написать отдельный и очень объемный обзор, правда моего опыта с ней хватит только на статью из раздела «Getting Started», коих уже достаточно в сети, в т.ч. на http://monotouch.net/Tutorials.
Что касается отсутствия приложений — то тут (это конечно мое личное мнение) дело не в сырости и не в новизне, а в составе комьюнити Моно.
ИМХО, также важное значение имеет порог вхождения на платформу — $400 только за лицензию monoTouch и monoDroid. Это останавливает энтузиастов!
Было бы круто раздавать лицензии бесплатно для free software или НКО.
Примерно это я и имел ввиду под «составом комьюнити» +)
Кстати, вы смогли бы внести «посильный вклад» в решение этой проблемы — напишите им насчет их политики выдачи лицензий! Вас послушают, особенно если «на бланке» Parallels sw))
Regards!
Спасибо, познавательно. Я тоже остановил свой выбор на Appcelerator, поэтому есть вопросы по нему.
1. Использует ли автор подход MVC при разработке приложений, если да, то как это организовано (при разработке для iOS и Android), какие библиотеки используются (например ORM JazzRecord).
2. Официальная документации API скудна, какие еще есть источники (я много интересных примеров кода нахожу поиском в pastebin.com и github.com).
3. Если есть, то какие приложения на Appcelerator автор уже разработал.
Очень рад +)
Что касается вопросов, наверное дам не столь исчерпывающие ответы, все-таки разработка под мобильные девайсы это скорее хобби в свободное от работы время:
1. Все ОРМы для JS однообразны, поэтому я искал «заточенный» под Appcelerator — https://github.com/xavierlacot/joli.js
Что касается интерфейса, то, по-моему, мобильные приложения в большинстве своем просты и должны такими быть, поэтому UI собранный через Ti.UI вполне читаемый, даже с адоптацией под платформы/девайсы обычными ифами и конструкциями типа () ? () : ().
Вдобавок, поскольку вся инициализация компонентов происходит словарями, а имена параметров иногда различаются для iOS/Android, проставлять сразу оба набора.
2. Возможно это сказывается привычка писать по MSDN, но мне документация показалась очень неплохой. Помимо нее лишь несколько раз пришлось использовать Гугл и их же форум.
3. Одно очень секретное приложение сейчас в разработке +)
Спасибо за развернутый ответ и особенно за joli.js
Странно, что здесь не упомянули нашумевшую отечественную разработку AppCode (http://www.jetbrains.com/objc/) — почти полностью заменяет собой Xcode, и по мнению многих пользователей превосходит его в области рефакторингов, генерации кода, анализа и автоматического исправления ошибок (memory leaks, type checking, data flow analysis). О нем можно отдельную статью написать. Могу помочь (я один из его разработчиков:))
Александр,
AppCode это альтернативная IDE, в обзоре же я писал о том как вообще обойти использование ObjC, так что темы немного разные.
Я думаю вы можете связаться с редакторами AppleInsider и предложить им эту тему.
Мы не против.
При сохранении статьи в Read It Later все картинки сохраняются в конце статьи. Поправьте сайт!
А за саму статью спасибо.
Тут скорей надо Read It Later править.
У нас WP обычный.
Однако кроме вашего сайта мне ни один такой не попадался. Со всех сайтов с которых я сохранял статьи все сохраняется корректно. Так что вряд ли Read It Later виноват.
Мой любимый http://www.instapaper.com/
Сохранил прекрасно эту старницу.
Спрошу програмистов… но думаю они тут не помогут.
У нас стоит движок который пишем не мы.
Я думаю это из-за увеличивающихся картинок.
Я уже потратился на Read It Later Pro… Обидно…
Извините, а каким образом у вас страницы в .html генерируются?
А почему нет AirPlay? На нем делают игры многие студии, геймлофт например
«лично мне Objective-C не нравится, Почему? Да потому что Apple делает свои продукты исключительно для пользователей, а к разработчикам поворачивается тем местом, что находится пониже поясницы. Другими словами, в фирменных продуктах Apple для девелоперов нет ни нормальной среды разработки, ни вменяемой документации»
Это извините полный бред, говорю как разработчик со стажем более 10 лет, знакомый с кучей IDE (последние годы VisualStudio) языками программирования (основная специализация плюсы, но были и объектный паскаль и пхп и сейчас немного питон как скриптов использую чуть-чуть знаком с явой и сишарпом), также кучи фреймворков и библиотек (последние годы Qt, но были и MFC, VCL, WinApi). ОС: винда, линукс немного макось, даже под DOS немного пришлось писать. В том числе мобильные платформы, под winmobile писал с ее рождения тогда еще pocket pc называлась, а среда разработки eVC. Это я не пыль в глаза пускаю
, а просто хочу сказать, что я уже далеко не школьник и мир повидал в свои 30.
Последний год разрабатываю для iOS (вполе успешно я считаю) так вот считаю, что у Apple очень неплохая среда XCode с прекрасными инструментами, кое где выигрывает у VS, последний XCode4 с парсингом на ходу как ObjC так и сложного C++ так вообще супер.. У него только единственный недостаток — мало настроек. У меня например другой стиль расставления скобок, и настроить это нельзя как в Visual Assist. Но эта фишка общая болезнь всех продуктов Apple. Делайте как мы решили. Документация? вроде все супер, материалов куча, примеры, видео не хуже чем в MSDN. ObjC тоже очень интересный язык, синтаксис немного своеобразный и динамизм его с рантайм ошибками иногда напрягает, но язык тем не менее хороший. Объектно-ориентированная стандартная библиотека cocoa вообще кажется верхом совершенства после таких убожеств как winapi и mfc, при этом она легкая и производительная, что выгодно ее отличает от qt.
Мне почему то кажется, что вы веб разработчик, раз выбрали тулкит где программы пишутся на js, и просто не захотели вникать в непревычные низкоуровневые материи. Не осилили в общем
Для сишников же все элементарно и знакомо.
Пс
извиняюсь за ошибки длинные посты на планшете неудобно писать
Уважаемый Coldfire, сравнивать Xcode и Visual Studio — это все равно, что сравнивать двух динозавров периода неолита. Вы на Java вообще когда-нибудь программировали? (нету в вашем длинном списке языков). Если бы программировали, то поняли бы, что прогрессивное человечество давно ушло вперед. Современные IDE (IDEA, Eclipse, …) уже давно умеют больше, чем текстовый редактор. А современные языки программирования (в отличие от Objective C) имеют нормальную систему типов, позволяющую обнаруживать ошибки на этапе компиляции, а не во время выполнения на девайсе.
Вы такую смешную ерунду написали, даже не представляете)) не буду тратить время на убеждение вас в чем-либо, но на будущее — не стоит быть категоричным в вопросах, в которых имеете слабую эрудицию!)
Понятно, аргументы в пользу динамических языков закончились))
Каких динамических языков?? Я вот вам намекал, что вы в сосем комменте ерунду написали. Про языки и слова не было, ни против, ни в пользу!
Своем*
Автозамена-такая автозамена!)
Если непонятно, могу объяснить на примере — в динамических языках типа ObjC можно в любую коллекцию запихнуть значение одного типа, например, строчку, потом забыть про это и прочитать, скажем, число и получить Segfault прямо на девайсе. В языках со статичечской типизацией (Java) есть Generics и такое сделать не удастся — программа просто не скомпилируется. Другие примеры — в C-подобных языках можно забыть проинициализировать переменную, в Джаве опять компилятор заругается. Я не говорю про то, что в ObjC у переменной класса со значением Null можно взять поле и послать любое сообщение, рантайм промолчит, но свалится потом, когда у исходной проблемы уже концов не найти. Давно-давно был такой язык PL/1 — там вообще все можно было
)
Кто вам сказал, что ObjC — динамический язык?
Generics не особо связаны с статической типизацией, и позволяют упрощать создание классов «по шаблону». Вот Delphi7 не имел generics, а языком со статической типизацией был.
В ObjC не удасться в коллекцию запихнуть string и прочитать integer: там string — это объект, а int — это простой тип. И int не удасться поместить в коллекцию. Пруф — ( http://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSMutableArray_Class/Reference/Reference.html%23//apple_ref/occ/instm/NSMutableArray/addObject: ).
Вот как раз отсутствие ошибок и исключений на не-инициализированном объекте — это одна из хороших особенностей ObjC, позволяющая программам не падать при ошибках инициализации. К «поиску концов» отношения эта особенность не имеет!
В общем, ваши представления об ObjC каки-то дремучие! Я бы ещё понял претензии к своеобразному синтаксису ObjC, но вот заявления о его «отсталости» или попытки представления XCode как дремучей IDE — это прям смешно! Ну и попутный наезд на VisualStudio к чему? Одна из лучших IDE.
Если вы жив\те в мире Java, там и живите. Не суйтесь со своими категоричными суждениями — за умного сканаете авось!
Учите матчасть! Сначала узнайте, что такое generics/templates, а потом спорьте.
Я говорил про NSInteger, а не про int, конечно. Кладем NSString, берем NSInteger и получаем совсем не то, что хотели. В джаве такого в принципе не может быть — все контролируется компилятором. На те же грабли можно наступить и в Дельфи7 — типичный пример динамической типизации — тип коллекции известен, а про тип хранимых значений ничего не знаем. Ровно для этого и нужны generics в яве, а не для «создания классов по шаблону».
Все сказанное можно отнести не только к яве, а к любому языку с продуманной системой типов, например, C#.
Про Visual Studio я и говорить не буду — там даже рефакторингов нормальных нет, не понимаю, как люди этим пользуются. Для нормальной работы там нужно устанавливать сторонние плагины.
А синтаксис ObjC мне как раз нравится — писать селекторы для каждого параметра — это очень круто!
Я знаю что такое generics, но в Delphi. В яве это примерно то же самое. И википедия описывает их как «обобщенное программирование, позволяющее описывать классы, параметризируемые типами данных». То есть порождать для определенного типа данных классы по заготовке (шаблону).
Насчет типизации в ObjC. Там промежуточный подход. Вы можете объявить переменную как id, а можете указать вонкретный тип. во втором случае компилятор ругается на отсутствующие методы/свойства.
Теперь напишите мне код, который «кладет NSString, берёт NSInteger и получает совсем не то». Ну и совсем мне не понятно — как можно наступить на грабли в Дельфи7? С чего тип хранимых значений то не известен? В какой такой коллекции Delphi тип не известен? Вы слышали про конструкцию (SomeObject is Class) ну или про банальное SomeObject.Class?
VisualStudio комментировать не буду — сам не пользуюсь
NSMutableArray *a = …//some array
[a addObject: @"7"];
NSInteger i = [a lastObject];
NSLog(@»%d», i.intValue); // Обламываемся в рантайме
List l = …//some list
l.add(«7″);
Integer x = l.get(0); //Compilation error here!
System.out.println(x);
Еще вопросы?
SomeObject is Class — это проверка в рантайме! статически тип неизвестен, а в Яве известен — тот, который в указан.
Все генерики в html не показываются((
на пятой строчке, где начинается java-код, List угл скобка String угл скобка. В последней строчке «тип, который в угловых скобках указан»
Не поленился проверить ваш пример в XCode. Не компилируется!))
пруф: http://pix.am/PTWT.png
Ну и вы не совсем честно поступаете с Java: там вы создаете не универсальный список, а типизированный.
Тогда уж нужно создать в XCode наследника от NSMutableArray с переопределенным методом addObject, который будет проверять чего туда пихают. В общем, было бы желание — все можно сделать. И определенно Xcode и ObjC не совсем запущенные языки в плане контроля типов. Я бы сказал, что ObjC является очень удачным компромисом между гибкостью полностью динамических языков, и скоростью статического С.
Блин, ну попробуйте не NSInteger, а какой-нибудь тип, производный от id, тогда ругаться не будет. Сейчас у меня нет возможности запустить компилятор. То, что вы называете «типизированный список», я называю список с generics — в джаве все списки так создают. Без генериков можно, но это obsolete syntax. Хак, который вы предлагаете для MutableArray, будет работать опять только в динамике. Статически проверить тип хранимых элементов невозможно без введения генериков (может быть, они их все-таки введут, а?)
А джаву можно компилить не в байткод, а напрямую в исполняемый код — будет такая же быстрая, как С.
Если попробовать другой тип, производный от NSObject, то ругаться не будет. И ничего «страшного» в run-time не произойдёт. А вы утверждали, что можно получить «Segfault прямо на девайсе».
Жду кода, дающего Segfault.
Здесь -не будет, а вот если с указателями что-нибудь перемудрите, будет (пример вы сами сможете придумать). В яве указателей вообще нет, а в ObjC — частая практика.
все грубые ошибки использования объектов контролируются xcode на этапе компиляции. Так что, если ObjC так плох, как вы говорите — типа, динозавр и несовременный язык, то уж придумайте в подтверждение ваших слов пример с SegFault.
А то пока все выглядит так, как будто вы глупость ляпнули, и не хотите в этом сознаваться!
desken, вы — двоешник! В теме разбираетесь плохо, а пафоса много.
Вот вам один Segfault:
https://docs.google.com/document/d/1LzZHF0WcHqCtjukwXCdckruKjEmSU4-Rvp1d5hG6mKE/edit?hl=en&authkey=CLS_uuUJ
Вот другой:
https://docs.google.com/document/d/1ZcT59h8XPpyzBYyIUhKYD3MTC9B7aX9gC71wj__Tv5A/edit?hl=en&authkey=COD—ZML
Вот третий:
https://docs.google.com/document/d/1k4qJTKAnjSfZZzqVs65HEtRzAiElTL4TeIG64Vv9YkY/edit?hl=en&authkey=CPqb_N0D
Во всех трех случаях компилятор молчит, как партизан.
Вот вам один Segfault:
NSString* x = @»";
NSLog(@»%@», &x[1]);
Вот второй:
@interface I1: NSObject
-(void) m: (int) s;
@end
@implementation I1
-(void) m: (int) s {
NSLog(@»%d» ,s);
}
@end
@interface I2: NSObject
-(void) m: (NSString*) s;
@end
@implementation I2
-(void) m: (NSString*) s {
NSLog(@»%@» ,s);
}
@end
void foo() {
id i = [[I2 alloc] init];
[i m:1];
[i release];
}
Вот третий:
typedef void(^ block_t1)(NSString* s);
typedef void(^ block_t2)();
void foo() {
block_t2 block = ^(NSString* s) {
NSLog(@»%@», s);
};
block();
}
Н да, .. комменты уже не попадают к нужной ветке! В общем, вы смогли привести примеры, как с помощью сишных (вместо ObjC) указателей попортить память в примере №1 и 3 (третий даже не стал компилировать), и как получить предупреждения при компиляции в примере №2. Надеюсь, вы не попросите меня написать Вам как можно «положить» программу на яве))
Насчёт моего опыта — какой есть, весь мой)) Вам спасибо сказать пока не могу, вы меня ничему тольком не научили. Только ессмысленно потратил время.
На этом дискуссию нужно прекращать — она ни о чём. Вам нравится ява — на ней и пишите. сотни тысяч идиотов останутся на XCode. Я останусь на JS и Delphi)
Скажите, зачем вам в третьем примере block_t1? Он же не используется?
Третий пример с блоками — это не ObjC. Блоки — это конструкция C для GCD. А так как в ObjC может использоваться C, то оттуда и ноги растут.
В общем, ни 1, ни 3 пример не используют ObjC. Только Конструкции С! Ну а про безопасность указателей в C известно всем)
на этот пример XCode ругается warning про множественные доступные версии m (всего 3 предупреждения)
Третий — чистейший Objective C — никакого С, они ввели блоки как новую фичу в Objective C 2.0, все блоки — это объекты Objective C, и, как видите, я получил Segfault без всяких warning-ов компиляции на чистом ObjC.
В общем и правда, холивор надо прекращать — я выиграл, подтведил и доказал все свои изначальные утверждения. Забираю банк.
Действительно, не нужен, я хотел сделать хитрую штуку с подменой блоков разных типов через id, но можно и просто присвоить блоки с разными сигнатурами без ошибок
есть еще 2 — линки запостить не удалось, сюда пихать большие исходники не хочу, давайте емейл
Во всех трех случаях компилятор молчит, как партизан.
Запостил сюда, вроде читается, не надо емейла.
Сразу видно, в теме вы разбираетесь плохо, я советую не переходить на личности в каждом комменте, а наооборот благодарить меня за повышение вашего образования.
Это ж не ObjC! Вы никакого массива/коллекции не объявляете, и ничего в него не добавляете! Вы просто обращаетесь к памяти за пределами константы, причём не методами ObjC, а простым C!
В нормальных языках (Java и C#) так сделать не получится.
Так не получится сделать только в managed языках. за что они и страдают от недостаточного перфоманса.
Такой вопрос. Расскажите, что выдаст ваш Java compiler на код типа:
{
var aObject = new Object;
aObject = null;
aObject.CallSomeMethod; // or .property
}
под рукой нету «приличных» java ide, был только ideone. Он сказал что то типа Exception in thread «main» java.lang.NullPointerException
Андрей,
и в Java, и в C# можно написать каст, который обнаружится только в рантайме.
Компилятор не от каждого человеческого упрямства спасает +)
Против лома нет приема:)) Cast — это лом.
Компилятор промолчит, а IDE (во всяком случае IDEA, Eclipse, NetBeans, …) скажут «Method invocation may produce NullPointerException» во время компиляции. Они делают статический анализ кода перед вызовом javac. Xcode тоже бы мог, но он не делает.
Я бы сказал — не стоит быть категоричным вообще +)
Каждое мнение интересно.
+1! Я бы вообще ничего не сказал, если бы была формулировка «мне кажется» или «для меня».. Все имеют право на свою точку зрения! Но категорично причислять довольно (или одни из самых ) популярные IDE к динозаврам! И утверждать, что динамическая типизация — почти зло.. )))
Александр,
VS на данный момент одна из лучших IDE на рынке. С ней работают на C++ и языках .NET (C#, F#, ASP.NET и т.д.). Сравнивать ее с динозаврами глупо. О динозаврах я представление имею, мне до сих пор приходится сопровождать один крупный проект на C++ Builder 6.0.
XCode 4 уступает VS только по рефакторингу и настраиваемости (что, повторю, болезнь абсолютно всех продуктов Apple, так что можно считать это фичей
). При этом при работе с VS на C++ рефакторинга нет вообще (я правда с VS2010 еще не работал), и нужно использовать сторонние решения — VisualAssist например. Кодекомплит в VS тоже не очень хорош, в XCode он гораздо лучше. VS c VisualAssist уже чуть выигрывает.
По низкоуровневым инструментам VS полностью сливает XCode, там нет вменяемого средства поиска утечек памяти на C/С++, профайлер тоже на мой взгляд похуже.
Называть все слаботипизированные языки устаревшими — бред, при том, что вы не имеете притензий к Lua и JS, где проблема рантайм ошибок стоит на порядки острее чем в ObjC, это полностью интерпретируемые языки и даже простая опечатка в имени переменной приведет к проблеме. Большинство ошибок которые могут возникнуть в рантайме, как то например посылка сообщения не описанного в интерфейсе или протоколе, компилятор ObjC идентифицирует варнингами, надо просто к ним внимательно относиться (новичкам рекомендуют повысить уровень варнингов до ошибки, чтобы не игнорировать их), и решать проблемы с помощью или более строгой типизации или с помощью рантайм проверок / ловили исключений.
Кстати не поясните, что значит:
«Я не говорю про то, что в ObjC у переменной класса со значением Null можно взять поле и послать любое сообщение, рантайм промолчит, но свалится потом, когда у исходной проблемы уже концов не найти.» ? Послать сообщение указателю на объекту с nil можно, и абсолютно ничего страшного не произойдет, посылка просто проигнорируется, вы наверное путаете с С/С++.
О Java я представление имею, Эклипс тоже видел. Но с C# работал плотнее. Технологии одного плана, C# даже посовременнее, и VS как IDE для него гораздо лучше опен-сорсного Эклипса для Явы. И в общем, я соглашусь, что неопытному кодеру писать на шарпе и яве будет проще. Но у ObjC возможностей больше благодаря бесшовной стыковки с C/C++ с полным арсеналом библиотек и средств для них. Также ObjC и Cocoa гораздо «легче» чем технологии работающие в виртуальных машинах (Java и .NET), так как это native код и Cocoa довольно легкий API, при этом они не являются сильно низкоуровневыми технологиями как например C/С++ с Win или Posix API. На мой взгляд ObjC с Cocoa отличный компромисс между тяжеловесностью очень высокоуровневых языков работающих в искусственной платформенно-независимой среде с огромным оверхедом с их тяжеловесными библиотеками и, с другой стороны, низкоуровневых технологий где в голове приходится держать слишком много деталей и писать слишком много кода для выполнения элементарных действий. Этот компромисс для мобильных ОС большой плюс. На Андроиде основанном на Java проблемы производительности решаются тупо гигагерцами и гигабайтами, и ухищрениями типа JIT и NDK.
В общем очевидно, что у вас нет серьезного опыта чтобы судить о XCode и ObjC. Вы категорично утверждаете, что средства разработки Apple полный отстой, также совершенно необоснованно считаете, что там плохая документация и осуществляется плохая поддержка (или как расценивать «а к разработчикам поворачивается тем местом, что находится пониже поясницы»?). При этом предлагаете к использованию какие-то поделки, более менее приличной из которых является разве что Юнити. Не пригодных к созданию серьезного софта использующего платформу iOS по полной. Чем можете навредить начинающим разработчикам.
Вы категорически путаете людей которым отвечаете +)
Мои комментарии — с аватаркой, Александр — один из посетителей.
Ай-ай-ай, как же я про AirPlay-то забыл… Это досадно, ибо платформа-то действительно интересная.
Coldfire,
полностью одобряю ваше мнение, но остаюсь при своем +)
Насчет низкоуровневого софта! Тут народ провел замеры перфоманса javaScript в последнем Хроме. Он уделал по производительности native Delphi x32 (примерно в 3 раза)!
Ссылки не помню, но блог буржуйский, поэтому проще пруфлинк искать в гугле по ключевым словам на английском.
Это я к профиту от низкоуровневых средств! Типа, js нынче не такой уж и тормознутый))
Эмм.. Важное дополнение — перфоманса про вычисления с плавающей точкой (геометрия?).
как уже писал, до сих приходится работать с Builder, там ужасно устаревший компилятор не знающий нечего о процессорах последнего десятилетия, в Делфи он такой же наверное (фирма то одна)
К JS можно прикрутить JIT компиляцию и будет все не так ужасно, что наверное и сделали в Хроме.
Но адекватным нативным средствам он все равно будет проигрывать, бесплатно, чудесным образом JS или Java байт код не превратиться в высокооптимизированный машинный код, это в любом случае лишние затраты времени, высокоуровневый оверхед будет присутствовать неизбежно.
Ну, в Дельфях всё не так плохо, как в стройке. но компилятор староват, летом будут выпускать новую версию — 64 бита и компиляция под мак ось.
Для JS в хроме действительно прикручен JIT (v8?).
Тут вот какая музыка — в JS сейчас вваливается значительно больше человеко-часов, чем в любой другой язык! И, несмотря на очевидный оверхэд динамического языка, JS, сцуко, быстрый! честно говоря, становится немного грустно.. Тут народ с тоски уже ваяет кросс-компилятор Delphi в JS))
Я от этой конторки, решил отойти, и перешел на Qt. Последние релизы были один глючнее другого, 64 бита только обещают, когда как я сам уже более 6 лет сижу на 64битных ОСях. Лучших разработчиков скупила MS для развития своего .NET и C#.
видимо, вы отошли до d2010. Этот релиз — хороший. стабильный, фичи есть, набор инструментов неплохой в бандле. 64бита и мак ось сейчас в closed beta 4 — выпуск летом.
Для дельфей значительное влияние оказало появление remObjects с продуктом Prism, а сейчас они допиливают Cooper — это ObjectPascal Compiler for Java/Android с нативными биндингами.
по факту, паскалевский языковой охват платформ сейчас очень даже неплохой — Win32/64, Mac, .NET/Mono (+monoTouch, monoDroid), Java/Android. Пожалуй, конкурировать с ними может только C/C++
Чуть не забыл ответить на самое «едкое» замечание +)
Дело не в том, что «не осилил», и даже не в том что «непривычные низкоуровневые материи» (по секрету — в АппСторе есть мое приложение написанное в Xcode на ObjC, честно-честно +), а в том, что низкоуровневость эта нужна далеко не всегда. С помощью Аппселератора, к примеру, можно сократить количество кода раза в 3-4, а время написания и отладки — ну уж в 2-3 раза точно (вот он — RAD). А если еще посчитать соотношение затрат на соответсвующих разработчиков — то тут уже получается колоссальная разница.
Конечно, каждому приложению — свое средство. Писать клиента для Seti@HOME на JS — расточительство, а вот 90% приложений из аппстора…
я согласен с вами, что низкоуровневость нужна далеко не всегда, я не согласен с тем, что средства Apple для разработчиков являются такими уж низкоуровнеми или устаревшими. Они не идут ни в какое сравнение с WinAPI или средствами разработки для симбы, которые действительно можно в этом упрекнуть. Если сравнивать с C# или даже С++ и Qt, то да, немного более низкоуровневые, но учитывая, что платформа еще с NeXT ведет историю, это можно простить, тем более не просто так, а получив более легковесную платформу.
Насчет аппселератора, там есть доступ к абсолютно всем возможностям стандартной библиотеки? Как я понимаю нет. На совсем простеньких вещах может и удастся сильно сэкономить. А в серьезном проекте сильно сомневаюсь. Помимо стандартных фреймворков есть вагон и маленькая тележка сторонних на ObjC, C и С++. Может статся, что уткнетесь куда-нибудь в тупик с этим аппселятором и дальше никак (совсем или придется самому дописывать модули). Еще один вопрос — поддержка, вы не найдете того громадного количества информации, готовых решений, ответов на сложные вопросы по аппселятору и любым другим нестандартным средствам.
Или вот еще, рекомендуете Юнити для игр, а по мнению многих разработчиков он не очень то и подходит для 2д игрушек, да и для 3D надо будет еще постараться чтобы ничего не тормозило. Для 2D многие выбирают cocos2d, а это библиотека работающая опять таки со стандартными XCode и ObjC.
Я бы сказал, что смысла в разработке только под iOS на сторонних инструментах совсем нет. Если чистая iOS — это XCode. Даже если нужен MAc+iOS — это тоже XCode (+сторонняя библиотека совместимости).
А вто при кросс-платформенных решениях можно подумать. Чтобы программа делила часть кода между Андроидом и iOS. Чтобы был общий backend модуль с Win/Mac версией и мобильными клиентами. Вот только живьем такого софта я не встречал. Даже Evernote переписали на native-решения .
ИМХО, ниша альтернативных инструментов — для ПРИМИТИВНЫХ кроссплатформенных программ.
Кросс-платформенных (Win/Mac/iOS/Android) решений вообще достаточно мало. Но в случае Аппселератора, к примеру, такое есть — Wunderlist (конечно это не сложнейшее приложение).
Вы говорите про примитивные программы, и тут я впринципе с вами согласен, но суть в том, что таких — больше 90% +)
P.S. А может сейчас рынок мобильных девайсов в таком состоянии, что писать только под iOS становится меньше смысла?
я для себя языком для общего бекэнда выбрал плюсы. На Мас/Win/Linux и iOS с этим языком все отлично. На Android немного через попу, но вроде решаемо. Экзотика типа Bada, MeeGo там С++ вообще родной. Для HP Palm обещают более широкую стыковку (сейчас можно только отдельно или JS для приложений или С++ для игр). Симба уже не актуальна, но там тоже был С++ родным. Вот только с WP7 пока никак, но возможно еще прикрутят, хотя-бы на CL.
Ув. Coldfire,
где в моих словах хоть фраза про «средства Apple для разработчиков являются такими уж низкоуровнеми или устаревшими»? +) Опять путаете комментарии.
Насчет Аппселератора поясню: их api покрывает 3000+ стандартных вызовов. Если вдруг этого недостаточно — можно вставить свой код на ObjC или Яве для Андройда прямо внутрь проекта, если и после этого будет недостаточно — то можно обернуть любой сторонний фреймворк и снова использовать его из JS.
По поводу Юнити — опять-таки вы опускаете фразу «для себя я сделал выбор» — сколько разработчиков, столько и мнений, я вам про свое, вы — про «многих разработчиков» +) У Юнити ведь тоже комьюнити немаленькое, и тайтлов выпущенных в свет только под iPhone заявлено около тысячи (против 1500 на бесплатном Кокосе).
Ок, читаем 1) «Apple делает свои продукты исключительно для пользователей, а к разработчикам поворачивается тем местом, что находится пониже поясницы. Другими словами, в фирменных продуктах Apple для девелоперов нет ни нормальной среды разработки, ни вменяемой документации» 2) «сравнивать Xcode и Visual Studio – это все равно, что сравнивать двух динозавров периода неолита.» это и далее, был ваш комментарий от человека «Александр»? Если не ваш, то сорри. Но в принципе и пункта 1, хватает для несогласия с вами. Поясните тогда, что же не так с документацией, XCode и ObjC. Тот другой Александр пояснил именно так как я понял (передовое человечество использует Яву, XCode динозавр). Про документацию правда так никто ничего не сказал.
По поводу Юнити как раз никаких возражений. Да и в целом обзор интересный, о многих средствах я например не знал. Просто необосновую критика + далее «Поэтому я расскажу обо всех альтернативах, » можно расценить как то, что у Apple все настолько ужасно со стандартным SDK и туда смотреть даже и не стоит. Если бы ограничились «Для того, чтобы отвернуться от традиционных Objective-C и Cocoa Touch, может быть много причин – кросс-платформенность, существующие наработки, опыт, команда, или просто предпочтения.» то тут возражений никаких нет, на вкус и цвет.
Комментарий этот был не мой (мои — с аватаркой), а имя у меня достаточно распространенное +)
С документацией моя позиция простая: msdn.microsoft.com мне кажется обширнее, понятнее и удобнее чем developer.apple.com, а F1 в VS функциональнее чем Opt+Cmd+? в Xcode.
А мискомьюникейшн наш возникает от того, что вы выдераете слишком маленький контекст, я немного расширю вашу цитату: «[...] не буду скрывать: лично мне Objective-C не нравится, Почему? Да потому что [...] Поэтому я расскажу обо всех альтернативах [...]» — вот оно и идет, личное предпочтение +)