OGS-Main
/
ogs-site

<!DOCTYPE html>
<html>
    <meta charset="utf-8">
    <head>
        <style>
            #header
            {
                background: #2BA6E3;
                padding: 0.7em;
                text-align: left;
            }
            
            #header a
            {
                color: white;
                text-decoration: none;
                padding: 0.5em 1em 0.5em 1em;
            }
            .news_item
            {
                background: #FFFFFF;
                width: 720px;
                padding: 1em;
                margin-top: 2em;
                margin-bottom: 2em;
                border: 1px solid #E0E0E0;
                text-align: left;
            }
            .news_item_contents
            {
                color: #444;
                line-height: 1.5em;
            }
            .news_item_date
            {
                margin-bottom: 2em;
                color: #aaa;
            }
            body
            {
                background: #FAFAFA;
            }
            code, pre
            {
                font-family: monospace, serif;
                font-size: 1em;
                color: #7f0a0c;
            }
            figure
            {
                margin: 0px;
                padding: 0px;
            }
            img
            {
                width: 720px;
            }
            html
            {
                font-family: sans-serif;
            }
            a
            {
                color: #3A91CB;
                text-decoration: none;
            }
            #lang
            {
                float: right;
            }
            figcaption
            {
                color: #aaa;
            }
            
            table
            {
                border-collapse: collapse;
            }
            
            table, th, td
            {
                border: 1px solid #aaa;
                padding: 0.5em;
                margin-top: 0.5em;
                margin-bottom: 0.5em;
            }
        </style>
    </head>
    <body>
        <center>
        <div id="header">
            <a href="../../ru/news/index.html">Новости</a>
            <a href="../../ru/page/games.html">Игры</a>
            <a href="../../ru/page/about.html">О нас</a>
            <div id="lang">
                <a href="../../en/news/ios-tutorial.html">EN</a>
                <a href="ios-tutorial.html">RU</a>
            </div>
        </div>
        <h1>В новостях</h1>
                <div class="news_item">
                    <h2 class="news_item_title">
                        <a href="ios-tutorial.html">Самоучитель iOS</a>
                    </h2>
                    <p class="news_item_date">
                        2017-06-08 10:00
                    </p>
                    <div class="news_item_contents">
        <figure>
<img src="../../images/2017-06-08-ios-refactoring.png" alt="Земля и ракета" /><figcaption>Земля и ракета</figcaption>
</figure>
<p>Эта статья описывает проблемы, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.</p>
<p><a href="https://twitter.com/OpenGameStudio/status/826816343433498627">В феврале</a> мы сумели отобразить простую модель под iOS за считанные дни. Это дало нам уверенность, что самоучитель для iOS мы сделаем столь же быстро. Тем не менее, реальность напомнила нам о простой вещи: быстро сделать можно лишь поделку на коленке, работающую только у самого разработчика; над логически связанным примером, работающим у всех, придётся попотеть.</p>
<p><strong>Нативная библиотека</strong></p>
<p>Прежде всего нам необходимо было ответить на следующий вопрос: “должен ли пример приложения быть частью проекта Xcode или отдельной библиотекой?”</p>
<p>Для принятия решения мы использовали следующие факты:</p>
<ol type="1">
<li>Проект Xcode может напрямую использовать C++ (благодаря Objective-C++) без прослоек вроде JNI
<ul>
<li>Отдельная библиотека не нужна (+ приложение)</li>
<li>Создание отдельной библиотеки - это дополнительная работа (- библиотека)</li>
</ul></li>
<li>OpenSceneGraph собирается в библиотеки
<ul>
<li>Легче использовать стандартный процесс сборки (+ библиотека)</li>
<li>Создавать свой процесс сборки лишь для одной платформы сложно (- приложение)</li>
</ul></li>
<li>OpenSceneGraph использует систему сборки CMake, которая не поддерживается Xcode
<ul>
<li>Проект Xcode не может включать файлы CMake (- приложение)</li>
<li>Свой файл CMake может с лёгкостью включить файл OpenSceneGraph CMake для сборки единой библиотеки (+ библиотека)</li>
</ul></li>
<li>CMake может генерировать проект Xcode
<ul>
<li>Можно создать файл CMake, который будет собирать как OpenSceneGraph, так и пример приложения (+ приложение)</li>
<li>Xcode - это де-факто инструмент для создания проектов Xcode; легче использовать стандартный процесс сборки (+ библиотека)</li>
</ul></li>
</ol>
<p>Оценив плюсы и минусы обоих подходов, мы решили сделать библиотеку, которую можно включать в проект Xcode. Минусом данного подхода является то, что сборки приложения для симулятора и реального устройства используют разные сборки библиотеки.</p>
<p><strong>Рефакторинг</strong></p>
<p>Также нам пришлось ответить на ещё один вопрос: “использовать ли единую кодовую базу для всех платформ или несколько под каждую платформу?”</p>
<p>При создании самоучителя для Android мы использовали единую кодовую базу, т.к. она отлично работала для десктопа и Android. Когда мы начали работу над самоучителем iOS, стало ясно, что часть функционала либо работает, либо не работает на некоторых платформах. Например, один функционал может работать на десктопе и iOS, но не работать на Android. Другой функционал может работать на iOS и Android, но не работать на десктопе. Т.к. мы не хотели загрязнять код кучей #ifdef, мы решили помещать функционал, специфичный для конкретной платформы или нескольких платформ, в разные файлы. Это привело к резкому увеличению количества файлов. Такой подход хорошо подходил для повторного использования, но совершенно не годился для понимания общей картины.</p>
<p>В этот момент мы осознали необходимость ответа на второй вопрос. Мы напомнили себе, что главная цель примера приложения состоит в том, чтобы обучить базовым вещам OpenSceneGraph, а не создать повторно используемую библиотеку с API, который будет жить без изменений десятилетиями.</p>
<p>Для ответа на этот вопрос нам помог наш внутренний инструмент feature tool. С его помощью мы разделили код на несколько частей, который в итоге собирается ровно в два файла для каждой платформы:</p>
<ol type="1">
<li>functions.h - содержит повторно используемые бесклассовые функции</li>
<li>main.h - содержит остальной код приложения</li>
</ol>
<p>Их содержимое несколько отличается для каждой из платформ, но наличие всего двух файлов позволяет увидеть общую картину.</p>
<p>На этом мы заканчиваем описание проблем, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.</p>

                    </div>
                </div>
        </center>
    </body>
</html>