Несколько недель уже вожусь с программирование под iPhone. Почему-то складывается настойчивое желание купить билет на самолет и прийти в офис Appl’а с бейсбольной битой.
Из того, что наболело
— Управление памятью в Objective C какой-то странный изврат. С одной стороны вроде reference counter, а с другой стороны извольте ручками добавлять, убавлять, прописывать правильные атрибуты пропертям.
— XCode 3 расчитан на чертовых ниндзь. Кучу наиболее часто используемой функциональности (а-ля запуск программы или build) висит на комбинации из трех кнопок, вместо одной (или максимум двух). Постоянно приходится мудры какие-то руками выделывать.
— XCode 4 гораздо лучше в использовании клавиш, но он явная beta и крешится на любой чих и при отладке частенько теряет стрелочку, что же мы сейчас отлаживаем.
— Куча системных API возвращает, что операция не удалась, но не возвращает ошибки (и как я понимаю, нету эквивалента GetLastError)
— Куча API крешится при передаче каких-то не совсем подходящих значений. Блин, а слабо входные параметры проверять и не крешиться? Особенно радует, когда это происходит при передаче
параметров только что полученных из другой системной функции.
— API растасовано так, что черт ногу сломит. Естественно чтение из файла и URL нужно запихнуть в NSString. Божественно… может запихнем в NSString вообще все функции, которые возвращают строки?
— Security framework с которым мне надо работать урезан по самое нехочу. При том, что я четко знаю, что API эти в библиотеки есть и пользуются внутренними программами.
Уххх… Поубивал бы.
М-да… Просто какая-то истерика… По-моему вы, батенька, староваты уже стали для подобных «новых ощущений» и расписываетесь, таким образом, в собственном бессилии 😉
А не спам ли это часом?
Вы все критические каменты будете называть «спамом»? Они тут включены только для того, чтобы можно было хвалить и успокаивать? Я понимаю, что информации там было мало — одни эмоции. И это нормально для человека, который уже много лет успешно и *с удовольствием* занимается Cocoa-разработкой. Просто очень много букв надо потратить, чтобы дать пояснения по всем пунктам. А кое-где пояснения и не нужны… Вот пример такого перла: «Куча API крешится при передаче каких-то не совсем подходящих значений». Блин, а слабо не передавать «неподходящие» значения? Это же исключительная ситуация как-никак!
ЗЫ: Да, пока Xcode 4 == УГ
Уж где-где а в функциях экспортируемых в API нужно проверять входные значения на корректность.
По мне так сами по себе факты весьма любопытные, и без всяких пояснений. А если лень тратить буквы, то лучше вообще комменты не писать, а продолжать *с удовольствием* заниматься чем-то другим 🙂
Ок, и то правда… 🙂
Я называю «спамом», комментарии которые можно написать фактически в к любой пост без изменения. Перечитайте еще раз ваш комментарий.
Теперь по фактам.
>Вот пример такого перла: “Куча API крешится при передаче каких-то не совсем подходящих >значений”. Блин, а слабо не передавать “неподходящие” значения? Это же исключительная >ситуация как-никак!
Мое понимание следующее
а) Код реализующий API — один, кода вызывающий API куча. Если бы вы писали например SDK и программу его использующую, где бы вы поставили проверку параметров идущих в API и где бы вы поставили проверку значений возвращаемых из API
б) Windows и Java как пример API таки проверяют входящие параметры и кидают exception или возвращают error code
в) Зачастую, чтобы проверить правильность ВСЕХ параметров, нужно полностью знать implementation API. Если для того, чтобы проверить параметры, нужно знать внутренности API, то на корню убивается независимость interface и implementation.
Ага, т.е. у Вас есть собственное определение слова «спам». Хорошо.
а) Если Вы называете «проверкой» брошенный exception, то см. пункт «б», это есть.
б) А в Objective-C это типа происходит как-то по-другому, верно? 😉
в) Really? Т.е. хедеров и документации с четко описанными сигнатурами селекторов Вам недостаточно?! Недостаточно знать, данные такого типа должны передаваться в качестве параметра, так?
В Java как пример, для каждого API есть список exception’ов, которое оно может кинуть (checked exceptions) (эквивалент списка ошибок, которые возвращаются).
Я не видел такого списка для iPhone API.
Возвращаясь к той же Java. Там есть и exception, которые могут быть кинуты, но при этом они не прописаны для API — unchecked exception’ы. Именно они похожи на unhandled exception и signals для iPhone.
(http://java.sun.com/docs/books/jls/second_edition/html/exceptions.doc.html)
Одно из ключевых отличий (насколько я понимаю, так как в этом я не слишком силен), что обработка signal’s гораздо сложнее чем обработка exception — сложнее организовать множество уровней по разному обрабатывающие ошибки, сложнее тем, что это требует всегда отдельного handler’а и не может быть втавлена прямо в код где произошло что-то.
(http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html)
По поводу в). Мне необходимо знать, что конкретно я сделал не так при вызове API — передал не тот параметр, не туда, система в неправильном состоянии, что-то не инициализированно и т.п.
Причин почему API решило упасть может быть море. Если мне API каким либо вразумительным методом возвращает ошибку я ее могу исправить за считанные минуты.
Если оно просто падает с фразой «oh… shit happened», у меня может занять куча времени найти причину.
Что самое интересное, фанаты яблочной продукции как правило ничего не могут сказать по существу
Как я и написал. Вероятнее всего это таки спам, так как подобную фразу можно вставить буквально на любой пост.
Кстати, iPhone и iPad мне очень даже нравяться. MacBoox нравиться корпус.
MacOS очень непривычная, но тоже что-то в ней есть.
А вот именно программирование, явно мне не пошло винтом.
Ходят слухи, что наиболее перспективна сейчас разработка под Android: и по удобству, и по деньгам.
Это просто слухи. На самом деле, сейчас это не так. Во всяком случае — пока.
В плане разработки на заказ под андроид сейчас денег ИМХО действительно больше. В том числе за счет различных планшетов которые сейчас активно ваяется. Денег в за час платят больше. Особенно тем кто может совмещать java и c++.
Специалистов меньше.
В плане продаж своих продуктов — то раз в 10 меньше, если брать среднию температуру по больнице.
С удобством все же напряжно — т.е. до определенного этапа все гораздо проще и легче. Но в какой то момент, если лезть в глубину начинаются проблемы — приходится лезть читать исходники, и удивлятся сколько же там кривого.
Плюс есть ряд принципиальных проблем которые не решены и не решаются в принципе — типа ограничения на количество памяти на процесс, типа потери open gl context при suspend/resume, отсутсвие возможности разделить ресурсы для различных устройст — что например делает крайне затруднительным разработку игр.
Дык, уж не первый год занимаемся и тем и другим. Я знаю, о чем говорю. Специалистов не может быть меньше хотя бы потому, что порог вхождения намного ниже для случая с Андроидом. Любой нормальный джавист уделив пару дней изучению основ сможет что-то начать писать под Андроид. Тут не надо изучения несколько изощренного синтаксиса Objective-C, не надо иметь достаточно дорогой техники для разработки. Видимо поэтому мне, как работодателю, намного проще найти джависта под Андроид, чем программера под айфон.
Да, ладно. Джавист из энтерпрайз приложений (а другие есть в достаточном количестве?) сможет начать писать под андроид — не смешите меня. Насмотрелся я код который они генерят. Мозги у них не так заточены чтобы под мобильные платформы писать — проще взять j2me-ника, хотя это и ява только по синтаксису.
Да и objectC тоже под айфон не особо сдался — если просто по продажам судить, то проекты под айфон в которых objectC дай бог 2% кода и тот copy/paste — супротив проектов на чистом objectC, денег заработали я думаю на порядок больше.
Но не суть. Тоже не первый год пишу по обе платформы, и тоже ослеживаю все предложения и стараюсь ослеживать резюме — айфон программисты дешевле. Хотя бы потому что по моим оценкам их раза в 3 больше просто.
Ну, о квалификации таких кадров я ничего (хорошего) и не говорю. Это сейчас общая проблема отрасли, не глядя на конкретные технологии. Но факт остается фактом — могут ведь.
Вот я примерно то же самое читал/слышал («Зарплата программистов под Android удваивается каждый год»).
А насчет удобства тоже все понятно: с одной стороны есть вообще App Inventor, а с другой — мучения авторов Angry Birds, которым до сих пор не удается добиться оптимизации под все устройства.
Попробуйте MonoTouch, может будет лучше 😉
Спасибо — гляну.
Давайте не будем пытаться оценивать одну платформу в терминах другой…
> В Java как пример, для каждого API есть список exception’ов, которое оно может кинуть (checked exceptions) (эквивалент списка ошибок, которые возвращаются).
> Я не видел такого списка для iPhone API.
А он есть. Взгляните, например на -[NSArray objectAtIndex:] и т.д. Но это даже неважно, потому что… (см. ниже)
Если для той же Java обработка exception-ов является обычной практикой, то для Cocoa это скорее исключение (хе-хе, сорри за тавтологию). В случае мобильных платформ с unmanaged environment, обработка исключительных ситуаций является, как правило, довольно дорогим удовольствием. Да и зачем, например, пытаться отловить NSRangeException если можно просто проверить «index < [array count]", или NSInvalidArgumentException если можно просто проверить аргумент на "!= nil"? Кроме того есть и прямая рекомендация от Apple: "Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications."
Обработка signals в практической каждодневной разработке не применяется вовсе. Так что, давайте даже не будем это обсуждать. Например, если вы попытались получить доступ к "не своей" области памяти, значит у вас существует грубая ошибка в логике приложения. Это по поводу “oh… shit happened” (EXC_BAD_ACCESS и т.д.). Значит у Вас просто пока еще проблемы с memory management. Тут надо не обрабатывать, а найти и обезвредить. А на это Вам всегда в помощь стектрейс и техники, типа NSZombieEnabled.
Оценивать в терминах — действительно бессмысленно.
Но осмысленно сравнивать сложность решения одной и той же проблемы в двух платформах.
Условно говоря, если мне скажут, что в Java проблем с memory management на порядок меньше, чем в C/C++, я вполне с этим соглашусь.
Аналогично, я привожу примеры, что iPhone не так устойчив и хуже рапортует проблемы с передачей параметров в API.
> Apple: «Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the >recommended way to communicate expected errors in Cocoa applications.»
Алилуя… Об этом я и говорю. Я хочу получить NSError, если что-то пошло не так, а не crash. Только вот куча API не возвращает его и нету (или я ее тупо не нашел) system wide функции getl last error.
Ну вот мы уже наконец и отшли от первоначального «программирование под iPhone — УГ», верно? 😉
А… Так претензии были к заглавию, а не к содержанию 🙂
Ну ладно… Не УГ…. Но приятным времяпровождение назвать это тяжело.
И дело тут не в том, что это для меня новое (я как раз люблю возиться с новым). Скорее дело в том, что уж очень много грабель лежит на пути к программированию под iPhone. Ясно, что пару лет потанцевав вокруг грабель, уже знаешь, что одни лежат тут, а другие тут и решения этих грабель уже тоже наработаны. Но, когда только начинаешь копаться, то количество грабель просто зашкаливает.
Посетите, пожалуйста, группу: http://groups.google.com/group/iphonedevcampua Там есть ссылка на скайп-чат, посвященный вопросам разработки под айфон и Cocoa в целом. Думаю, там вам с удовольствием помогут обойти некоторое количество первичных грабель в интерактивном режиме. 🙂
Спасибо.
Упс, не туда ответилось… Но сам отредактировать вроде не могу.
Статья — бред)))
По своему опыту, обычно все дело не в средствах программирования, а в руках программиста. Если у Вас ручки кривоваты, не надо во всем Apple винить)