Думаю, у каждого разработчика рано или поздно возникают в голове мысли о том, что код нужно писать определенным образом. Почему фреймворк этого автора так прост в использовании, и погружение в него проходит так быстро? Почему данный кусок кода кажется мне ужасным? В этот момент происходит важный виток в развитии разработчика как профессионала. Он не только начинает задумываться о том, как ему реализовать конкретную задачу, но и том, как оформить свое решение. В голове начинают зарождаться мысли об определенном структурировании кода и красивом его оформлении. Кто-то начинает создавать для себя некий эмпирический набор правил по оформлению кода, кто-то приходит к помощи литературы или совету более опытных товарищей. В любом из этих сценариев код начинает рассматриваться не просто как безусловное решение проблемы. Появляются мысли о том, что некоторая часть кода сделана некрасиво, а вот здесь получилось круто и элегантно. Но кто определяет эти критерии красоты относительно кода и что в них закладывается? Однозначно ли все в вопросах кодового этикета и красоты?

Disclaimer: эта статья ставит перед собой целью поделиться мыслями, возникшими в процессе попытки осмыслить понятие красивого кода. Приведенные мысли не претендуют быть истиной в последней инстанции. Надеюсь лишь на то, что эти мысли, размышления и доводы, возможно, помогут кому-то взглянуть на сам процесс написания кода немного с другой стороны. Далее не следует ни одного формального правила вида «Пишите код так, и будет вам счастье». По данной тематике уже написан большой объем литературы от гораздо более уважаемых авторов.

Всех заинтересованных в рассуждениях на тему, что такое красота кода, в чем она может выражаться, почему все известные практики не в силах закрыть раз и навсегда этот вопрос, прошу под кат.

Думаю, многим в ходе разработке игры для iOS приходилось сталкиваться с тем, что возникает необходимость использовать тот или иной нативный функционал. Касаемо Unity3D, в данном вопросе может возникать очень много проблем: для того, чтобы внедрить какую-то фичу, приходится смотреть в сторону нативных плагинов, написанных на Objective-C. Кто-то в этот момент сразу отчаивается и забрасывает идею. Кто-то ищет готовые решения в AssetStore или на форумах, надеясь на то, что готовое решение уже существует. Если же готовых решений не существует, то самые стойкие из нас не видят другого выхода, кроме как погрузиться в пучину iOS программирования и взаимодействия Unity3D с Objective-C кодом.

Тех, кто выбирает последний путь (хотя, думаю, они и сами знают), ожидает множество проблем на этом нелегком и тернистом пути:

• iOS — абсолютно незнакомая и обособленная экосистема, развивающаяся своим путем. Как минимум придется потратить довольно много времени, чтобы понять как можно подобраться к приложению, и где в недрах автоматически сгенерированного XCode проекта находится код взаимодействия Unity3D движка c нативной составляющей приложения.
• Objective-C — довольно обособленный и мало на что похожий язык программирования. А когда речь заходит о взаимодействии с C++ кодом Unity3D приложения, то на сцену выходит «диалект» этого языка, под названием Objective-C++. Информации о нем совсем немного, большая ее часть древняя и архивная.
• Сам протокол взаимодействия Unity3D с iOS приложением довольно скудно описан. Расчитывать стоит исключительно на туториалы энтузиастов в сети, которые пишут как разработать простейший нативный плагин. Мало кто при этом затрагивает более глубокие вопросы и проблемы, возникающие при потребности сделать что-то сложное.

Тех, кто хочет узнать о механизмах взаимодействия Unity3D с iOS приложением, прошу под кат.

Откуда же начинаются опасности? Допустим вы твердо решили, что будете разрабатывать проект, придерживаясь определенной концепции или подхода. В нашей ситуации это DI, хотя на его месте также может оказаться, например, Реактивное Программирование. Вполне логично, что для реализации вашей цели, вы обратитесь к готовым решениям (в нашем примере — контейнер DI Zenject). Вы ознакомитесь с документацией и начнете строить каркас приложения, используя основной функционал. Если на первых порах использования решения у вас не возникнет неприятных ощущений, то скорее всего, оно задержится на вашем проекте на всю его жизнь. По мере работы с базовыми функциями решения (контейнера) у вас могут возникать вопросы или желания сделать некоторый функционал более красивым или эффективным способом. Наверняка, в первую очередь вы обратитесь за этим к более продвинутым «фичам» решения (контейнера). И на этом этапе может возникнуть следующая ситуация: вы уже неплохо знаете и доверяете выбранному решению, в силу чего многие могут не задуматься насколько идеологически правильным может быть использование того или иного функционала в решении, или переход к другому решению уже является достаточно дорогим и нецелесообразным (например приближается deadline). Вот на этом этапе и может возникнуть самая опасная ситуация — функционал решения применяется с малой осторожностью, или в редких случаях просто на автомате (бездумно).

Scene View в Unity3D является одним из самых необходимых элементов интерфейса. Каждый, кто хоть раз запускал Unity3D пользовался Scene View для визуальной расстановки объектов на сцене, а также для их настройки. Расширение функционала Scene View может понадобиться для создания собственного редактора уровней, редактирования mesh’а, создания собственных gizmos и много другого. Стоит заметить, что при использовании Terrain в вашем проекте, его редактирование (рисование текстур, изменение высот, а также посадка деревьев и растительности) осуществляется при помощи Scene View.

Для того, чтобы иметь возможность писать скрипты работающие в Scene view в первую очередь класс с которым вы работаете должен быть унаследован от Editor или EditorWindow, что подразумевает подключение namespace UnityEditor. Это дает доступ к нескольким «магическим» методам Unity3D, таким как OnGUI() и OnSceneGUI(). Метод OnSceneGUI дает возможность Editor'у управлять событиями Scene View.

В данной статье описаны некоторое типичные проблемы, возникающие при сборке/запуске на устройстве/выкладке в App Store проекта XCode для iOS, сгенерированного через Unity3D, а также их причины и решения. По личному опыту данные проблемы возникают довольно часто и не только у меня. В большей части статья может помочь тем, кто не очень знаком с нативной разработкой на iOS.

На момент написания статьи использовались Unity3d версии 5.1.2f и XCode 7.0.1. При использовании Unity3D версий 5.2 и выше, проблемы, перечисленные далее в статье также будут повторяться. Некоторые из проблем связаны с нововведениями в iOS 9.0. Внимание под катом много графики.

В Unity3d существует возможность подключения нативных плагинов к приложению. На официальном сайте Unity3d есть документация по взаимодействию с нативным кодом на iOS. Данная документация ограничивается описанием того, как вызвать ту или иную функцию из плагина, который вы собрали сами и как сделать обратный вызов. В документации описано каким правилам должна соответствовать описываемая функция и немного о том, как передать в нее параметры. В конце статьи с документацией есть ссылка, по которой можно скачать пример под названием Bonjour.

К сожалению в документации не описано, что делать в случае если вашему плагину необходимо перехватить событие о том, что пользователь подписался на Push Notification или приложение перешло в бэкграунд (AppDidEnterBackgound), тогда как доступ к этим событием бывает необходим для некоторых плагинов, которые вы возможно захотите написать.