Files
ogs-site/en/news/ios-tutorial.html

158 lines
6.5 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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="../../en/news/index.html">News</a>
<a href="../../en/page/games.html">Games</a>
<a href="../../en/page/about.html">About</a>
<div id="lang">
<a href="ios-tutorial.html">EN</a>
<a href="../../ru/news/ios-tutorial.html">RU</a>
</div>
</div>
<h1>In the news</h1>
<div class="news_item">
<h2 class="news_item_title">
<a href="ios-tutorial.html">iOS tutorial</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="Earth and a rocket" /><figcaption>Earth and a rocket</figcaption>
</figure>
<p>This article describes problems we faced during the creation of iOS tutorial in May 2017.</p>
<p><a href="https://twitter.com/OpenGameStudio/status/826816343433498627">This February</a> we managed to get simple model rendered under iOS in just a few days. We expected to finish iOS tutorial in no time. However, the reality reminded us: its easy to come up with a hackish demo that works for one person, but its hard to create a concise example that works for everyone.</p>
<p><strong>Native library</strong></p>
<p>The first question we had to answer was: should the sample application be part of Xcode project or be a separately built library?</p>
<p>We had to consider the following facts:</p>
<ol type="1">
<li>Xcode project can use C++ directly (thanks to Objective-C++) without stuff like JNI
<ul>
<li>Theres no need for a separate library (+ application)</li>
<li>Creating a separate library is an additional work (- library)</li>
</ul></li>
<li>OpenSceneGraph builds libraries
<ul>
<li>Its easier to use standard build process (+ library)</li>
<li>Its harder to create custom build process just for a single platform (- application)</li>
</ul></li>
<li>OpenSceneGraph uses CMake build system, which is not supported by Xcode
<ul>
<li>Xcode project cant include CMake files (- application)</li>
<li>Its easy to create custom CMake file that includes OpenSceneGraph CMake file to build a single library (+ library)</li>
</ul></li>
<li>CMake can generate Xcode project
<ul>
<li>Its possible to create a CMake file that builds both OpenSceneGraph and the sample application (+ application)</li>
<li>Xcode is the de-facto tool to create Xcode projects; its easier to use standard build process (+ library)</li>
</ul></li>
</ol>
<p>After evaluating the pros and cons of each approach, we decided to turn the sample application into a library and include it in Xcode project. The downside of this approach is that simulator and real device builds need separate library builds.</p>
<p><strong>Refactoring</strong></p>
<p>The second question we had to answer was: should there be a single source code base for all platforms or several ones, one for each platform?</p>
<p>While doing Android tutorial we used single source code base because it worked fine for desktop and Android. As we started to work through iOS tutorial, it became apparent that particular features may or may not work on some platforms. For example, one feature may work on desktop and iOS, but not Android. Another feature may work on iOS and Android, but not desktop. Since we didnt want to pollute the code with #ifdefs, we started to put each platform combination into a separate file. The number of files grew rapidly. The files were reusable, but it became extremely hard to see the whole picture.</p>
<p>At this point, we realized theres the second question. We reminded ourselves that the main purpose of the sample source code is to teach how to do basic OpenSceneGraph things, not create a reusable library with API that is stable across several years.</p>
<p>Thats when our home grown feature tool came into play. With its help, we separated the code into several parts, which in the end produce just two files for each platform:</p>
<ol type="1">
<li>functions.h - contains reusable classless functions</li>
<li>main.h - contains the rest of the sample application code</li>
</ol>
<p>Their contents differ slightly for each platform, but its easy to see the whole picture now.</p>
<p>Thats it for describing problems we faced during the creation of iOS tutorial in May 2017.</p>
</div>
</div>
</center>
</body>
</html>