Comments 91
Obj-C простой язык?
Я вот C# не зная могу читать спокойно, а что значит ЭТО из одного туториала???
— (id)initWithTitle:(NSString*)title rating:(float)rating thumbImage:(UIImage *)thumbImage fullImage:(UIImage *)fullImage;
Я вот C# не зная могу читать спокойно, а что значит ЭТО из одного туториала???
— (id)initWithTitle:(NSString*)title rating:(float)rating thumbImage:(UIImage *)thumbImage fullImage:(UIImage *)fullImage;
Что тут не понятно, это же практически plain English перед вами.
Например
Читается прмерно так
Ну-ка откройте тот самый очень понятный код на C# и прочтите его в таком же духе :) Нет, я не спорю, читать C# или C тоже легко если есть опыт, но Objective-C в каком-то смысле ближе к обычной (английской) речи, чем C или C#. Привыкание к синтаксису — дело двух недель, не больше.
Например
[app initWithTitle:@"Cool App"
rating:5.0f
thumbImage:[UIImage imageNamed:@"thumbImage.png"]
fullImage:[UIImage imageNamed:@"fullImage.png"]];
Читается прмерно так
init app with title «Cool Object», rating 5.0f, thumb image named «thumbimage.png» and full image named «fullImage.png».
Ну-ка откройте тот самый очень понятный код на C# и прочтите его в таком же духе :) Нет, я не спорю, читать C# или C тоже легко если есть опыт, но Objective-C в каком-то смысле ближе к обычной (английской) речи, чем C или C#. Привыкание к синтаксису — дело двух недель, не больше.
Эмм… Чем это ближе к английскому и проще?
В это кусочке близость к английскому достигает только именованием. Называть параметр глаголом — вообще говнокод.
или то же самое
«new app with title «Cool Object», rating 5.0f, thumb image named «thumbimage.png» and full image named «fullImage.png»»
В чем принципиальная разница?
В это кусочке близость к английскому достигает только именованием. Называть параметр глаголом — вообще говнокод.
var app = new App(withTitle: "Cool App",
rating: 5.0f,
thumbImage: new Image(named: "thumbImage.png"),
fullImage: new Image(named: "fullImage.png"));
или то же самое
«new app with title «Cool Object», rating 5.0f, thumb image named «thumbimage.png» and full image named «fullImage.png»»
В чем принципиальная разница?
Разница в парадигме вызова методов.
Если в C# в следующем вызове метода его название EndsWith
То в ObjC название метода будет isEndedWithString withIgnoreCase andCultureInfo.
То есть в ObjC в названии метода уже присутствуют его аргументы.
И согласись, что строка isEndedWithString withIgnoreCase andCultureInfo к английскому несколько ближе, чем кастрированное EndsWith?
Если в C# в следующем вызове метода его название EndsWith
someString.EndsWith(anotherString, true, someCulture);
То в ObjC название метода будет isEndedWithString withIgnoreCase andCultureInfo.
[someString isEndedWithString:anotherString withIgnoreCase:YES andCultureInfo:someCulture];
То есть в ObjC в названии метода уже присутствуют его аргументы.
И согласись, что строка isEndedWithString withIgnoreCase andCultureInfo к английскому несколько ближе, чем кастрированное EndsWith?
Так а чем это ваш пример отличается от Objective-C по большому счету?
Заменить "()" на "[]", убрать запятые, убрать «new» и пожалуйста, практически одно и тоже.
Если уж придираться к синтаксису, то в этом примере получается больше знаков препинания и служебных слов, чем в примере на Objective-C.
О чем вообще разговор? О фломастерах?
Заменить "()" на "[]", убрать запятые, убрать «new» и пожалуйста, практически одно и тоже.
Если уж придираться к синтаксису, то в этом примере получается больше знаков препинания и служебных слов, чем в примере на Objective-C.
О чем вообще разговор? О фломастерах?
Кстати, не понял насчет «назвать параметр глаголом», где вы это увидели?
Все параметры названы существительными: title, rating, thumbImage, fullImage.
«init» — не именует параметр, это как раз глагол, который означает что делает метод.
Все параметры названы существительными: title, rating, thumbImage, fullImage.
«init» — не именует параметр, это как раз глагол, который означает что делает метод.
Почитал доки по инициализаторам в Obj-C, зачем такое именование понял. Вот только есть мнение, что это костыль из-за кривоватой их реализации.
msdn.microsoft.com/en-us/library/vstudio/bb384062.aspx
msdn.microsoft.com/en-us/library/vstudio/bb384062.aspx
Я английскую школу закончил с отличием — что-то не помогло. Для любого языка программирования английский нужен, тока нужен он по минимуму. Во всех языках пытаються компактно красиво уменьшить количество символов, «sugar syntax» и тд. Если ARC используешь он не дает нормальный Singleton Pattern создать а делает autorelease. Давайте немного истории — создатели Java — девелоперы которым надоел Objective-C и они ушли делать свой нормальный язык.
Так может все-таки «syntax sugar» или «syntactic sugar», раз уж с отличием :)
Singleton по последнему слову техники, и ARC вам и GDC, и вообще google и stackoverflow этот ворос решают на ура.
Ну а если мы начнем сейчас рассуждать откуда взялись создатели того или иного языка, так это вообще будет долгий разговор. Вы не поверите, но создатели всех языков (кроме первопроходцев разве) писали до этого на каком-то еще языке, и почти все они делали свой новый и «нормальный» язык, потому что им что-то там надоело или просто захотелось или назрел момент и технологии шагнули вперед. Страуструп, C и C++, к примеру.
Singleton по последнему слову техники, и ARC вам и GDC, и вообще google и stackoverflow этот ворос решают на ура.
#ifndef SINGLETON_GCD
#define SINGLETON_GCD(classname) \
\
+ (classname *)shared##classname { \
\
static dispatch_once_t pred; \
__strong static classname * shared##classname = nil;\
dispatch_once( &pred, ^{ \
shared##classname = [[self alloc] init]; }); \
return shared##classname; \
}
#endif
Ну а если мы начнем сейчас рассуждать откуда взялись создатели того или иного языка, так это вообще будет долгий разговор. Вы не поверите, но создатели всех языков (кроме первопроходцев разве) писали до этого на каком-то еще языке, и почти все они делали свой новый и «нормальный» язык, потому что им что-то там надоело или просто захотелось или назрел момент и технологии шагнули вперед. Страуструп, C и C++, к примеру.
Не так давно в C# появились named arguments, так что можно писать также.
В корне не согласен. Уже сто лет не изучаю новые технологии и языки по книгам. Имхо — все эти книги — это потеря времени и денег.
Если ты знаешь хоть какой-то язык программирования, то новый можно изучить по примерам, паре туториалов, гуглу и стэкексченджу.
Если ты знаешь хоть какой-то язык программирования, то новый можно изучить по примерам, паре туториалов, гуглу и стэкексченджу.
Тоже заметил на своем примере. Изучать Objective-C начал по документации самой Apple, она всегда актуальна, в отличии от книг. Там же UIKit и все остальные фреймворки из SDK.
Так и не довелось полностью прочесть хоть одну книгу именно про зазработку под iOS. Все сведения берутся в первую очередь из документации и примеров Apple, потом помогает Google, а половина поисковых запросов ведет на stackoverflow.com.
Не смотря на все это, книги ни в коем случае не повредят, если есть время и желание их читать.
Так и не довелось полностью прочесть хоть одну книгу именно про зазработку под iOS. Все сведения берутся в первую очередь из документации и примеров Apple, потом помогает Google, а половина поисковых запросов ведет на stackoverflow.com.
Не смотря на все это, книги ни в коем случае не повредят, если есть время и желание их читать.
Плюсую. Имея .NET/C++/JS бэкграунд сел писать приложение под iOS, прочитав 1/3 книги, и то, за полгода до этого, то есть фактически всё познавал с нуля. Вполне нормально разрабатывается, ответы на 90% вопросов быстро находятся на stackoverflow\в гугле именно тогда, когда они нужны. Прочитав же книгу, даже если ответы на эти вопросы и будут в ней, они просто напросто забудутся, и не факт, что вспомнятся, когда будут нужны.
Нужно сразу бросаться с головой в разработку, все эти длительные подготовки в виде чтения кучи литературы — лишь тягание быка за яйца.
Нужно сразу бросаться с головой в разработку, все эти длительные подготовки в виде чтения кучи литературы — лишь тягание быка за яйца.
Если ты знаешь хоть какой-то язык программирования, то новый можно изучить по примерам, паре туториалов, гуглу и стэкексченджу.
Ок. У меня знакомый знал один язык (зато на отлично) — Assembler. Как думаешь, ему по паре туториалов C++ дался?
Это что угодно, но никак не «Путь самурая»…
Кроме того, Objective-C нужен только если вы хотите писать приложения. Если вы хотите писать игры, то изучайте сразу кроссплатформенные решения. Cocos2d-x, Unity, и т.п., а к Obj-C не приближайтесь на расстояние выстрела =)
А если хочется писать игры только под iOS, Cocos2d уже не подходит?
Имхо, есть резон рассмотреть сразу кросс-платформенные фреймверки чтобы писать одновременно для iOS/Android.
Я сейчас на OpenGL ES 2.0 пишу игру под iOS — не легко, но зато много интересного узнал.
Ого! А давайте человека, который не умеет плавать, сразу в Ниагарский водопад бросим? Выплывет — станет олимпийским чемпионом.
Это всё равно, что начинающему разработчику игр для Android сказать «бросай Java! садись сразу за Unity!».
Это всё равно, что начинающему разработчику игр для Android сказать «бросай Java! садись сразу за Unity!».
Еще раз — чтобы писать кроссплатформу на юнити — не нужно знать ни Java, ни Objective-C.
Это как чтобы писать на C/C++ не нужно знать ассемблер.
Это как чтобы писать на C/C++ не нужно знать ассемблер.
А если я хочу написать десктопное приложение для Android или iOS, чем мне Юнити поможет?
И в догонку сразу второй вопрос: кто начинает изучение конкретной платформы сразу с разработки игр?
И в догонку сразу второй вопрос: кто начинает изучение конкретной платформы сразу с разработки игр?
И в догонку сразу второй вопрос: кто начинает изучение конкретной платформы сразу с разработки игр?
Разработчики игр, например :).
Разработчики игр, например :).
Я говорил про игры, а не приложения. Цитата из моего коммента начала этой ветки:
Второй вопрос — для разработки игр отлично можно начать изучение прямо с юнити. «Изучение платформы» сводится только к парочки нюансов типа какое сжатие текстур где можно применять и т.п.
Кроме того, Objective-C нужен только если вы хотите писать приложения. Если вы хотите писать игры, то изучайте сразу кроссплатформенные решения.
Второй вопрос — для разработки игр отлично можно начать изучение прямо с юнити. «Изучение платформы» сводится только к парочки нюансов типа какое сжатие текстур где можно применять и т.п.
Нескромный вопрос: а Вы всегда игры на готовых движках делаете?
Да. Ибо я не собираюсь поддерживать два совершенно разных нативных кода для iOS и Android. Как и абсолютное большинство разработчиков. Найти сейчас игру, написанную не на кроссплатформенном движке — это еще постараться надо!
Я надеюсь, вы понимаете, что под словом «движок» — понимается среда кросс-платформенной разработки (типа Unity), а не набор «собери игру из кубиков не зная языка программирования», коих великое множество и на них ничего серьезного построить нельзя.
Я надеюсь, вы понимаете, что под словом «движок» — понимается среда кросс-платформенной разработки (типа Unity), а не набор «собери игру из кубиков не зная языка программирования», коих великое множество и на них ничего серьезного построить нельзя.
Отличный пример абстракции в программировании!
Чем так, по-вашему, плох Unity? Порог вхождения очень низкий, да и вообще работать с ним явно проще, чем свои велосипеды по книгам писать…
Думаю, судя по его комменту — Armi0000 не очень представляет, как выглядит разработка и программирование на Unity.
Очень даже представляю, можете поверить. Абсолютно ничего ни против юнити, ни против кокоса, ни против юдк не имею. Но лично мне интересно свои движки писать.
Если представляете, то откуда тогда уверенность, что сначала нужно изучить натив, а только потом садиться за юнити? Навыки написания приложения на Obj-C ну вообще никак не помогают в разработке игр на юнити.
А по поводу движков… Многие и в пределах юнити пишут свои движки. Особенно, если игра двухмерная.
А по поводу движков… Многие и в пределах юнити пишут свои движки. Особенно, если игра двухмерная.
Это не уверенность. Это лично моё мнение, которое никак не может быть на 100% верным. На вкус на цвет все фломастера разные :)
Ну, вот могу вас заверить — для разработки игры на Unity — знание нативной платформы «поможет» не больше чем знание ассемблера при разработке на C#. И это действительно очень точная аналогия.
Знать какой-нибудь шейдерный язык — полезно, да. Понимать, как работает OpenGL — тоже неплохо бы. Но именно нативный язык платформы — ну вообще бесполезен на все 100%.
Единственное для чего он может быть полезен — это если вы хотите к юнити какие-то нативные плагины написать. Но в 99% случаев для игр они уже написаны за вас (геймцентр, всякие фейсбуки и т.п.).
Знать какой-нибудь шейдерный язык — полезно, да. Понимать, как работает OpenGL — тоже неплохо бы. Но именно нативный язык платформы — ну вообще бесполезен на все 100%.
Единственное для чего он может быть полезен — это если вы хотите к юнити какие-то нативные плагины написать. Но в 99% случаев для игр они уже написаны за вас (геймцентр, всякие фейсбуки и т.п.).
Да японский бог…
Я не призываю учить нативные языки какой-либо платформы.
Лично мне нравятся языки Ruby, Python, Smalltalk и Objective-C. Поэтому я их учу и читаю всё возможное про них. Мне нравятся шейдеры, полигоны, Maya и OpenGL. Я читаю про них всё возможное.
Никогда не говорил «бросай <подставьте язык сами> и учи именно Objective-C!». Мне это не нужно.
Никогда не говорил «бросай эту херь и учи этот движок!». Мне это не нужно.
Каждый выбирает сам технологию и путь изучения технологии.
В 99% книг обучение разработки под iOS идёт под аккомпанемент Objective-C. Кому нравится — хорошо. Кому не нравится — тоже замечательно.
В названии топика нет и не было слов «кроссплатформенный» и «разработка игр». Намёк понятен, надеюсь?
Вы своё мнение высказали один раз — отлично. Больше одного раза — навязывание своего мнения, ИМХО.
На этом закончим, пожалуй, наш «спор». Вам меня не переубедить. Я вас даже не пытался переубедить. Finita.
Я не призываю учить нативные языки какой-либо платформы.
Лично мне нравятся языки Ruby, Python, Smalltalk и Objective-C. Поэтому я их учу и читаю всё возможное про них. Мне нравятся шейдеры, полигоны, Maya и OpenGL. Я читаю про них всё возможное.
Никогда не говорил «бросай <подставьте язык сами> и учи именно Objective-C!». Мне это не нужно.
Никогда не говорил «бросай эту херь и учи этот движок!». Мне это не нужно.
Каждый выбирает сам технологию и путь изучения технологии.
В 99% книг обучение разработки под iOS идёт под аккомпанемент Objective-C. Кому нравится — хорошо. Кому не нравится — тоже замечательно.
В названии топика нет и не было слов «кроссплатформенный» и «разработка игр». Намёк понятен, надеюсь?
Вы своё мнение высказали один раз — отлично. Больше одного раза — навязывание своего мнения, ИМХО.
На этом закончим, пожалуй, наш «спор». Вам меня не переубедить. Я вас даже не пытался переубедить. Finita.
Я еще слышал о MonoGame. Все хочу попробовать, что это :)
Фраза про ООП надстройку над Си доставила. Автор пиши еще.
В чём не прав?
Смотрим руководство Programming with Objective-C от Apple (надёжный источник, надеюсь?):
Objective-C is the primary programming language you use when writing software for OS X and iOS. It’s a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. It also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime.
Superset = надмножество. Слово «надстройка» так же применима. Objective-C и на грамм не менял C, он только добавляет ООП составляющую.
Смотрим руководство Programming with Objective-C от Apple (надёжный источник, надеюсь?):
Objective-C is the primary programming language you use when writing software for OS X and iOS. It’s a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. It also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime.
Superset = надмножество. Слово «надстройка» так же применима. Objective-C и на грамм не менял C, он только добавляет ООП составляющую.
В результате получается другой язык с сиобразным синтаксисом по сути. Если рассматривать глубже, то в общем-то и у тех же плюсов с базовым си довольно мало общего, как в чисто программном плане, так и в плане философии разработки.
При этом при любой надежности источников нужно понимать, что объектная модель Objective-C лежит ближе к смалтолку, чем опять же к тем же плюсам.
При этом при любой надежности источников нужно понимать, что объектная модель Objective-C лежит ближе к смалтолку, чем опять же к тем же плюсам.
При этом при любой надежности источников нужно понимать, что объектная модель Objective-C лежит ближе к смалтолку, чем опять же к тем же плюсам.
Да кто бы спорил то?
Вот только по истории вопроса надо понимать: разработчики языка взяли чистый ANSI C, и над ним сделали ООП надстройку. Не изменяя самого C. Именно поэтому надстройка — это термин разработчиков языка. Именно так и написано: Objective-C не новый язык программирования, а надмножество языка C со Smalltalk парадигмой ООП.
3 раза удалил написанное, ладно будь по вашему, волга — надмножество бмв.
Опять 25…
Пойдём по простейшему ООП примеру (во всех учебниках по ООП вроде обсасывается):
волга — наследует от автомобиля (четыре колеса, двигатель, руль);
бмв — наследует от автомобиля (четыре колеса, двигатель, руль).
Проще: и волга и бмв имеют в пра-пра-пра-дедушке автомобиль.
Волга не может быть надмножеством бмв (в нормально ситуации), потому что как ни извращайся, а из бмв волги не получишь.
Опять же ООП пример: ObjC — наследует, но не перегружает от C.
Блин, ну что непонятно то?
Пойдём по простейшему ООП примеру (во всех учебниках по ООП вроде обсасывается):
волга — наследует от автомобиля (четыре колеса, двигатель, руль);
бмв — наследует от автомобиля (четыре колеса, двигатель, руль).
Проще: и волга и бмв имеют в пра-пра-пра-дедушке автомобиль.
Волга не может быть надмножеством бмв (в нормально ситуации), потому что как ни извращайся, а из бмв волги не получишь.
Опять же ООП пример: ObjC — наследует, но не перегружает от C.
Блин, ну что непонятно то?
Вы меня не понимаете. То что в волге и бмв используется двигатель об бмв, волгу бмв не делает. Точно так же использование си синтаксиса и элементарных типов не делает ObjC — надмножеством Си. Это по моей логике.
Согласно вашей логике (которую я понял, но не согласен), тот факт что в основе ядра OSX лежит BSD делает ее надстройкой BSD.
Согласно вашей логике (которую я понял, но не согласен), тот факт что в основе ядра OSX лежит BSD делает ее надстройкой BSD.
Согласно вашей логике (которую я понял, но не согласен), тот факт что в основе ядра OSX лежит BSD делает ее надстройкой BSD.
Отнюдь нет. Ядро было капитально переработано под требования Mac OS X. Это уже не изначальное ядро BSD. Это новая операционная система.
А вот сам ANSI C в составе Objective-C не был затронут изменениями вообще никак. Поэтому создатели языка и называют его не новым языком, а именно надмножеством (так ими пишется в спецификации языка в девелоперском разделе сайта Apple). Давайте уважать разработчиков языка — им всё-таки виднее.
У меня в ДНК есть незатронутые гены ящерицы? Я надстройка над ящерицами? В руководстве черным по белому написано, что ObjC это язык программирования соблюдающий стандарты Си для простоты перехода программистов с последнего на указанный. Язык создан в начале 80х годов. За это время притерпел изменения, развивался и прочими доступными методами эволюционировал как мог.
Если вернуться в область языков программирования — был ли Делфи надстройкой Паскаля? Является ли C# надстройкой Си или все же Джавы или это вообще отдельный язык?
Если вернуться в область языков программирования — был ли Делфи надстройкой Паскаля? Является ли C# надстройкой Си или все же Джавы или это вообще отдельный язык?
У вас какой-то зацикленный спор, аргументы начали повторятся. Этак вы сейчас дойдете до того, как определятеся понятие «язык программирования», входит ли туда синтаксис, рантайм и т.д.
Все что я вижу это неудачный перевод «надстройка», все-таки «superset» нужно переводить хотябы как «надмножество». В конце концов почти все языки транслируются в машинный код, так может быть они все «надстройка» над машинным кодом?:)
Все что я вижу это неудачный перевод «надстройка», все-таки «superset» нужно переводить хотябы как «надмножество». В конце концов почти все языки транслируются в машинный код, так может быть они все «надстройка» над машинным кодом?:)
С термином «надмножество» согласен, это более точно отражает суть происходящего. Надстройка в нормах русского языка это когда на крыше дома летний сад развели. А когда мы имеем дело с языком который на протяжении многих лет развивается самостоятельно со своей философией, практиками и всеми остальными нюансами, уместнее говорить про эволюционную ветвь, надмножество, но никак не надстройку.
Мы же не можем сказать что человек — надстройка обезьяны?
Мы же не можем сказать что человек — надстройка обезьяны?
Разве любая программа на C не является валидной программой на ObjC? Если да, то ObjS — superset (надстройка) C в самом прямом смысле этого слова.
А что вы понимаете под валидной программой? Запускается? Работает? Корректно работает? Компилируется?
ЗЫ Ссылка выше на subset, а не на superset
ЗЫ Ссылка выше на subset, а не на superset
Да на все вопросы. В статье в первом абзаце дается определение подмножества и надмножества. Множество программ на C являются подмножеством программ на ObjC, следовательно C подтип ObjC или ObjC надтип (надстройка) C.
Аналогия с человеком и обезъяной не работает, так как не выполняется принцип подстановки Лисков.
Аналогия с человеком и обезъяной не работает, так как не выполняется принцип подстановки Лисков.
Я думаю не меньше 20% от всех приложений в app store написанны (созданые) без использования Objective-C.
А если взять приложения которые зарабатывают 90% дохода, то этот процент дорастет до 90% :)
А если взять приложения которые зарабатывают 90% дохода, то этот процент дорастет до 90% :)
Ок.
Большинство игр на базе Cocos — на JavaScript.
Большинство игр на движке Unity — C# или JavaScript.
Куча игра почти на голом C++.
Однако UI 95% приложений — написаны на Objective-C.
У нас что, заработок приложения влияет на его процент от общего количества приложений вообще?
Большинство игр на базе Cocos — на JavaScript.
Большинство игр на движке Unity — C# или JavaScript.
Куча игра почти на голом C++.
Однако UI 95% приложений — написаны на Objective-C.
А если взять приложения которые зарабатывают 90% дохода, то этот процент дорастет до 90% :)
У нас что, заработок приложения влияет на его процент от общего количества приложений вообще?
Однозначно, большинство кассовых приложений — кроссплатформа.
Спасибо автору
Хех. Почти все книги от издательства Apress.
За подборочку спасибо
За подборочку спасибо
Да, это так. К сожалению, ни O'Reiily ни Wrox не понравились по содержанию. Да и Apress быстрее книги для актуальной версии выпускает. И ещё один плюс от Apress — книги до выхода в электронном виде купить можно, в виде Alpha-версии.
Если, надумаете покупать, то есть код скидки — FBP212 дает -50% от стоимости.
К тому времени, как прочитаешь все это, выйдет iOS 8 и можно будет цикл начинать сначала с новыми книгами) Пишите приложения — от простого к сложному, разбираясь по ходу — толку будет больше.
Отчасти вы правы. Но от версии к версии мало что меняется.
К примеру, я начал читать книги и доки по iOS 6. Сделал аппликуху, но она, практически без проблем, и на iOS 5.x работает.
К примеру, я начал читать книги и доки по iOS 6. Сделал аппликуху, но она, практически без проблем, и на iOS 5.x работает.
Согласен — так и делаю: пишу аппликухи, а книги в качестве самообразования в транспорте читаю (по 2 часа дороги на работу и домой).
А насчёт скорости чтения — всё индивидуально. Я, когда разогнался, на каждую из этих книг по неделе максимум тратил. Да и не обязательно для каждой новой версии операционки книги брать — достаточно change читать и уроки по новым фишкам (типа Storyboard и Arc).
А насчёт скорости чтения — всё индивидуально. Я, когда разогнался, на каждую из этих книг по неделе максимум тратил. Да и не обязательно для каждой новой версии операционки книги брать — достаточно change читать и уроки по новым фишкам (типа Storyboard и Arc).
Спасибо за книжки, почитаю. Добавлю, что можно писать не только на ObjC, но и на C# (MonoTouch), и Ruby (RubyMotion). Сам сейчас играюсь с RubyMotion и очень доволен.
Полностью согласен! Сам сейчас поглядываю в сторону RubyMotion.
Данный обзор не охватывает всё разнообразие программинга под платформу iOS, поэтому сторонние языки не упомянул.
Хотя сам язык Objective-C понравился сильно — в своё время на Smalltalk некоторое время программил, а оттуда в ObjC много взято. Имхо, для меня один из самых красивых ООП языков, наравне с Ruby и Python.
Данный обзор не охватывает всё разнообразие программинга под платформу iOS, поэтому сторонние языки не упомянул.
Хотя сам язык Objective-C понравился сильно — в своё время на Smalltalk некоторое время программил, а оттуда в ObjC много взято. Имхо, для меня один из самых красивых ООП языков, наравне с Ruby и Python.
Ваши предположения сколько времени у Вас уйдет на изучение этих книг по вечерам после работы? Мне кажется после их прочтения, возможно уже не актуально будет устраиваться на Junior`a придет мысль перепрофилироваться еще в кого-нибудь. Сам список возможно хорошо, но как roadmap я считаю слишком долгий старт.
Выше написал. Но подробнее, сколько у меня ушло для получения необходимого минимума:
Learn C on the Mac — где то дней 6-7.
Learn Objective-C on the Mac — 7 дней.
Beginning iOS 5 Development — с выполнением примеров где то 9-10 дней.
После этих 3 книг уже что-то своё писал на уровне junior, и параллельно по дороге на работу-домой (по 2 часа в каждую сторону) остальное читал (и до сих пор что то читаю).
На абсолютное знание не претендую, мастером пока не зовусь :)
Совсем же необязательно всё это читать — это, так сказать, обзор. Каждый выбирает то, чего не хватает. К примеру, если человек C знает — первую книгу читать вообще не обязательно. Если человек знает C++, C# или Java — книгу про Objective-C пробежит по диагонали, и ему этого достаточно будет.
Learn C on the Mac — где то дней 6-7.
Learn Objective-C on the Mac — 7 дней.
Beginning iOS 5 Development — с выполнением примеров где то 9-10 дней.
После этих 3 книг уже что-то своё писал на уровне junior, и параллельно по дороге на работу-домой (по 2 часа в каждую сторону) остальное читал (и до сих пор что то читаю).
На абсолютное знание не претендую, мастером пока не зовусь :)
Совсем же необязательно всё это читать — это, так сказать, обзор. Каждый выбирает то, чего не хватает. К примеру, если человек C знает — первую книгу читать вообще не обязательно. Если человек знает C++, C# или Java — книгу про Objective-C пробежит по диагонали, и ему этого достаточно будет.
Нет. Вам еще понадобится некоторое время что бы разобраться с XCode. Работу c Interface Builder сложно описать текстом, гораздо проще посмотреть на youtube. А вообще я бы по советовал книгу из цикла Head First «Программируем для iPhone и iPad» 2012 г. В книге описан полный цикл разработки приложения ну и как всегда много картинок и все понятно.
XCode — крайне грамотная среда разработки. Необходимые знания для работы с ней приобретаются за час максимум из видеоуроков или книг.
«Программируем для iPhone и iPad» 2012 г. — книга хорошая, спору нет. И перевод хороший. Один минус — расчитана на iOS 4, то есть несколько устаревшая, как минимум, года на полтора. Но базу по ней получить всё равно можно.
«Программируем для iPhone и iPad» 2012 г. — книга хорошая, спору нет. И перевод хороший. Один минус — расчитана на iOS 4, то есть несколько устаревшая, как минимум, года на полтора. Но базу по ней получить всё равно можно.
Sign up to leave a comment.
iOS разработчик: Обзор книг для новичка