Перейти к содержимому

Когда Android-разработчик начинает делать приложения для iOS

Дисклеймер: Этот пост был написан для блога GSPD

Android Logo

Введение

У меня довольно большой опыт в Android-разработке, я делаю приложения для ОС Google уже пять лет и думаю на Java уже семь лет. Но этим летом мне пришлось самому вытянуть iOS-проект, хотя у меня не было опыта продакшн-разработки в мире Apple. Так что вот мое скромное и довольно спорное мнение. У меня были курсы по iOS-разработке пару лет назад, с тех пор работаю в окружении iOS-разработчиков, так что не должно было быть ничего удивительного. Но...

Мысли

Гайдлайны и документация

У Apple хорошие гайдлайны, хорошая экосистема, их устройства просты в использовании для домохозяек и бизнесменов. Так что должно быть легко создавать всё по этим гайдлайнам. Но в реальном мире клиенты хотят, чтобы были реализованы вещи, которые они придумали. Им всё равно на гайдлайны. И здесь у вас проблема с SDK. Вам не нужно ничего, что вы не можете сделать — эта идеология Apple работает везде в их продуктах. Более того, я помню некоторые ложные утверждения в документации. Например это, orientation - "Returns the physical orientation of the device". Теперь представьте, что ваше приложение работает только в портретном режиме, и попробуйте получить это значение, когда устройство в ландшафте со строкой состояния открытой. Вы получите UIDeviceOrientationPortrait. "физическая", ага.

Objective-C

Главное, что шокирует iOS-новичков с опытом в других языках. Это не так ужасно, как выглядит. Можно писать код несмотря на Java-бэкграунд. Но на дворе сентябрь 2015, мы можем ожидать большего. Swift и Kotlin могут улучшить наш опыт в будущем, но только когда сама Apple начнёт писать весь свой софт на Swift, а Google признает Kotlin языком разработки для Android.

Xcode

У Apple странная черта изобретать колесо как очень сложную вещь. Им не особо важно, чтобы колесо было круглым и крутилось. Они лучше сделают колесо, которое может сварить вам чашку кофе. Вот на что похож Xcode. Вы можете делать всё — писать код, подписывать приложение и даже публиковать его в AppStore. А что касается кодинга, Xcode — это слегка улучшенный блокнот. Нельзя ожидать, что все будут писать хорошо отформатированный код с его помощью. Лучше ожидать наоборот. Рефакторинг, слышали о таком? AppCode от Jetbrains далеко впереди в плане кодинга. Не похоже, что кто-то в Apple вообще думал о разработчиках, когда делал Xcode, главное, что Xcode удовлетворяет их бизнес-целям. Я помню, когда Eclipse был официальной IDE для Android-разработки не так давно. Что ж, могу сказать, что работа с кодом и структурой проекта была намного лучше, чем в Xcode сейчас. У Xcode также есть ностальгическая фича Eclipse — исправлять проблемы перезапуском IDE. Я почти забыл это чувство :).

UI / Xib / Storyboard

Apple — думай иначе. Какого чёрта они всегда делают новые форматы файлов, которые можно редактировать только через Xcode, и которые обычно плохо работают с системами контроля версий. Это ещё хуже из-за плохого Interface Builder, в котором нельзя сделать всё, что нужно. Просто смиритесь с этим. Это приводит к тому, что некоторые разработчики предпочитают писать всё в коде вместо использования IB. 2015 год, да? Разработчики вынуждены двигать мышкой влево и вправо, чтобы делать что-то в Xcode. Это печально. Вы даже не можете редактировать эти XML вручную. Constraints как действительно плохо реализованный RelativeLayout из Android реально вас достанут, это позор.

Ресурсы и околокодовые вещи

Так вот здесь ад, дно ада. Если вы были в мире Google, вы знаете, что ресурсы хранятся в специальных местах, изображения в drawables, строки, размеры в соответствующих xml-файлах. Вы можете использовать их из кода как R.string.hello, R.color.accent, R.dimen.avatar_size. Apple попыталась сделать что-то подобное со строками, они сделали "Localizable.strings", мда. Вы даже не можете использовать их из файлов Interface Builder. Спасибо, Apple. Ваше лучшее решение здесь — написать код, чтобы установить локализованные строки из кода в каждый Label, Button и так далее. Зачем тогда использовать Interface Builder? Хотите создать класс View, который загружает свой UI из Xib, чтобы использовать его много раз в других xib? Лучше не надо. Не так просто, как мы ожидаем после Android. Хотите убрать отступы из UILabel. Забудьте об этом и просто примите это.

Комьюнити / Хипстеры?

Где они? Где супер-библиотеки, фреймворки? Окей, я знаю, что они здесь... Но попробуйте задать не самый стандартный вопрос на Stackoverflow. Скорее всего, вы получите 0 ответов. Теперь попробуйте найти какую-нибудь хорошую реализацию PageViewController, потому что реализация от Apple — полное дерьмо. Ага, и это один из самых популярных контролов на мобильных устройствах в наши дни. И, говорю это как Android-разработчик, просто представьте точку зрения любого веб-фронтендера.

Android такой фрагментированный, говорили они

Ага, но Android был готов к фрагментации 8 лет назад. С фрагментацией iOS гораздо сложнее иметь дело. Просто попробуйте добавить поддержку планшета для Android-приложения, а затем поддержку iPad для iPhone-приложения. Для Android гораздо проще поддерживать фрагментацию. Что нам делать с поддержкой iOS 6/7 и так далее? Какого чёрта нам нужно устанавливать старые версии IDE, чтобы получить старую версию SDK? Android SDK Manager может скачать любую версию SDK отдельно, без скачивания полной IDE, конечно.

Инициативная Apple

С одной стороны, Obj-C — это язык немного более низкого уровня, чем Java, и вам приходится делать многие вещи вручную, с другой стороны, Apple делает вещи за вас сама, даже если вы этого не хотите. Например: drag'n'drop в TableView установит прозрачный фон для всех subviews ячейки. Вы этого ожидаете по умолчанию? Не думаю. И это первый пример, который я вспомнил, таких много.

То, что вы видите, не то, что вы получите

Забудьте о WYSIWYG, если вы Apple-разработчик. Interface Builder — главный пример этого утверждения. Вы никогда не получите на экране устройства что-то похожее на прототип из Interface Builder. Структура проекта Xcode — следующий пример — вы видите папки в структуре проекта, кликаете правой кнопкой, чтобы показать в finder, и видите все файлы в одной директории. Хорошо.

Положительные моменты

Приложению как-то удалось заработать. WTF в минуту зашкаливает за 9000, но всё равно оно в какой-то момент начинает работать. Идеология сообщений Objective-C делает крэши с исключениями типа "NPE" действительно редкими. Положительное с одной стороны — отрицательное с другой. Вам придётся помучиться с отладкой. Всё выглядит так, будто работает хорошо, и логи это подтверждают, кроме логики. Удачи в отладке. Apple заставляет вас писать говнокод, правда.

Заключение

Моё мнение сейчас в том, что iOS-разработчики существуют исключительно из-за пользователей и денег в мире Apple. Теперь я не поверю никому с опытом в чём-то другом, кто говорит, что ему нравится быть iOS-разработчиком. И люди всё ещё говорят, что разработка Android-версии приложения занимает больше времени, чем iOS-версии, потому что Android — более проблемная платформа. У меня что, другие iOS и Android в этом мире?