У меня старая Nokia на Symbian, хотя я с 2009 года iOS-разработчик :) А iPhone 4 — однопроцессорный, и как только вышла iOS, которая была переписана под 2 core — она сама начал тормозить на одноядерном iPhone 4. Ну и iOS 8 же не вышло для iPhone 4, так что лучше купить новый телефон…
За всех не скажу, а в бизнес-приложениях хватает и джаво-андроидной производительности; игры же в основном пишут на кросс-платформенных движках, где особенности что Obj-c, что Java, что Swift до лампочки. Не могу даже придумать пример, скажем, обработки больших массивов нативными средствами на iOS. А на дорогие стандартные операции типа конвертации видео и т.п. мы все равно вызываем библиотечные методы…
В общем, преимущества строгой типизации над нестрогой + еще пара фокусов, 99.999% не заметят быстроты swift. Я бы не на этом акцентировал внимание (пользователям вообще пофиг, на чем написана их любимая игра — хоть на Javascript в WebView), а на более лаконичном синтаксисе что, возможно, ускорит разработку ПО (а вот это уже очень важно заказчикам).
Не поддерживаю Артемия Лебедева, но у него в студии делают так — сначала человек работает пару месяцев на стационаре, а потом работает хоть на Бали, когда ему уже доверяют. Я считаю такой способ более продвинутым, чем чистая удаленка — а на западе и в Японии кстати очень ценят личное знакомство.
и сейчас применяются как синие экраны, так и зеленые — в зависимости от расцветки персонажей. С технологией съемки это никак не связано. Например, в первом спайдермене одновременный полет паука и гоблина снимали сразу на фоне двух цветов — паука на зеленом, а гоблина на синем по понятным причинам.
Вот так вот работаешь всю неделю, и не видишь ничего кроме кода и проекта. А прочитаешь статью, посмотришь на мрачно-прекрасное небо и такой чушью все это кажется… вот бы увидеть без симуляций, своими глазами, что там творится!
Думается, NSString и NSURL никуда не исчезли с переходом на swift, равно как и проблемы SDK. Тут как ни обратись, обращаешься к одним и тем же библиотекам, просто в вашем случае — примеры на Obj-C, который еще ой как нескоро перестанет быть актуальным.
Вопрос из разряда «Почему денди-мэны гоняются по всему миру за оригинальными картриждами первого выпуска teenage ninja turtles: manhattan project, у меня на симуляторе все идет».
Но когда приехал к другу, у него живая денди, и взял в руки джойстик, и пострелял в уток на теплом ЭЛТ-телевизоре — это совсем не те ощущения!
Давно пора отменить диктовку. Я закончил университет не так давно, в 2010 году — и на 80% наших лекций препод просто диктовал конспект студентам. Как будто сейчас на дворе средневековье, смешно.
Но отбери у преподов время для начитки конспекта — они же не будут знать, что делать на лекциях!
Согласен. В общем, так себе инструмент, старые-добрые ксибы никто не отменял, и лучше чем кодом писать переходы ничего нет. Segue сами по себе тоже не такая уж крутая штука.
Во-первых не дело вкуса, а дело задачи. В вашей же статье человек пишет, что ни в коем случае нельзя использовать сториборды на больших проектах (т.е. верстать UI в сторибордах) — о том и я пишу.
А вырывать из контекста и освещать какой-либо Hello world-style элемент разработки, и не писать ничего более — ничтожная польза. Либо пишите нормальный, объемный туториал для новичков в виде цикла статей, либо пишите короткую статью про тонкости для профессионалов.
— не надо грузить в loadView, если в сториборде в контроллере удалить вьюшку — она будет грузиться автоматом из ксиба с тем же именем, что и класс контроллера. Это описано в доках Эппла. Просто контроллер создаешь сразу с ксибом, и никаких проблем.
— ксибы целесообразнее использовать по ряду причин:
1) И самая главная — одновременная разработка под iPhone и iPad. Если делать все в сториборде, то выйдет так — сделал UI в iPhone_storyboard, проверил, застестил, сделал UI в iPad_storyboard, проверил, застестил. В случае с ксибом одного ксиба на афон и айпад хватит, а если айпадный должен чем-то незначительно отличаться — ксиб можно просто скопировать (попробуйте безглючно и без потери constraint-ов скопировать вьюху из одного сториборда в другой);
2) В больших и серьезных проектах сториборды со множеством UI-элементов тормозят даже на SSD, я молчу про относительно новые iMac и Macbook pro 2010-2011 гг. с HDD, там вообще тихий ужас.
3) Карта пустых контроллеров вполне себе помогает ориентироваться в навигации ничуть не хуже, чем карта с элементами. Все равно ксибы не похожи на то, что вы видите после запуска приложения, разве что если вы используете только стандартные контролы.
4) Ну и наконец, если делать некоторые вьюшки ксибами, их можно переиспользовать просто как вьюшки. Сторибордовый же контроллер намертво прикреплен к своему месту. Особенно это касается табличных и коллекшновых ячеек.
UI верстается прямо в сториборде — дальше можно не читать. В любом проекте с >= 10 вьюх UI нужно выносить в ксибы, а сториборды оставлять только как карту навигации.
Ну и пользы от таких туториалов немного. Начинающему после его прочтения некуда пойти (это не цикл статей, нет ни более элементарных, ни менее элементарных вещей), а для опытного разработчика, которого интересуют неочевидные тонкости, здесь информации ноль.
Можно написать короче: бумажный компьютер реализует простейшую архитектуру фон-Неймана. Все остальные подробности — для тех, кому еще предстоит понять асм. Статья отличная (наверное? только для кого?), но многабукаф.
Кстати, в вышеупомянутой книжке про фортрана тоже было что-то подобное, что нужно было вырезать и идти по блок-схеме. Я как раз благодаря той схемке открыл для себя в 8 лет, что такое алгоритм.
и сейчас применяются как синие экраны, так и зеленые — в зависимости от расцветки персонажей. С технологией съемки это никак не связано. Например, в первом спайдермене одновременный полет паука и гоблина снимали сразу на фоне двух цветов — паука на зеленом, а гоблина на синем по понятным причинам.
Но когда приехал к другу, у него живая денди, и взял в руки джойстик, и пострелял в уток на теплом ЭЛТ-телевизоре — это совсем не те ощущения!
Но отбери у преподов время для начитки конспекта — они же не будут знать, что делать на лекциях!
А вырывать из контекста и освещать какой-либо Hello world-style элемент разработки, и не писать ничего более — ничтожная польза. Либо пишите нормальный, объемный туториал для новичков в виде цикла статей, либо пишите короткую статью про тонкости для профессионалов.
— ксибы целесообразнее использовать по ряду причин:
1) И самая главная — одновременная разработка под iPhone и iPad. Если делать все в сториборде, то выйдет так — сделал UI в iPhone_storyboard, проверил, застестил, сделал UI в iPad_storyboard, проверил, застестил. В случае с ксибом одного ксиба на афон и айпад хватит, а если айпадный должен чем-то незначительно отличаться — ксиб можно просто скопировать (попробуйте безглючно и без потери constraint-ов скопировать вьюху из одного сториборда в другой);
2) В больших и серьезных проектах сториборды со множеством UI-элементов тормозят даже на SSD, я молчу про относительно новые iMac и Macbook pro 2010-2011 гг. с HDD, там вообще тихий ужас.
3) Карта пустых контроллеров вполне себе помогает ориентироваться в навигации ничуть не хуже, чем карта с элементами. Все равно ксибы не похожи на то, что вы видите после запуска приложения, разве что если вы используете только стандартные контролы.
4) Ну и наконец, если делать некоторые вьюшки ксибами, их можно переиспользовать просто как вьюшки. Сторибордовый же контроллер намертво прикреплен к своему месту. Особенно это касается табличных и коллекшновых ячеек.
Ну и пользы от таких туториалов немного. Начинающему после его прочтения некуда пойти (это не цикл статей, нет ни более элементарных, ни менее элементарных вещей), а для опытного разработчика, которого интересуют неочевидные тонкости, здесь информации ноль.
Кстати, в вышеупомянутой книжке про фортрана тоже было что-то подобное, что нужно было вырезать и идти по блок-схеме. Я как раз благодаря той схемке открыл для себя в 8 лет, что такое алгоритм.