The demo application – how the projects work together
In Chapter 1, Introduction to LibGDX and Project Setup, we successfully created our demo application, but we did not look at how all the Eclipse projects work together. Take a look at the following figure to understand and familiarize yourself with the configuration pattern that all your LibGDX applications will have in common:
What you see here is a compact view of four projects. The demo project to the very left contains the shared code that is referenced (added to the build path) by all other platform-specific projects. The main class of the demo application is MyDemo.java. However, there is a different main class where an application gets started by the operating system, which will be referred to as starter classes from now on. Notice that LibGDX uses the term starter class to distinguish between these two types of main classes in order to avoid confusion. We will cover everything related to the topic of starter classes later.
While taking a closer look at all these directories in the preceding figure, you might have spotted that there are two assets folders: one in the demo-desktop project and another in the demo-android project. This brings us to the question, where should we put all the application's assets? The demo-android project plays a special role in this case. In the preceding screenshot, you can see a subfolder called data, which contains an image named libgdx.png. This image also appears in the demo-desktop project in the same place.
Note
Just remember to always put all your assets into the assets folder under the demo-android project. The reason behind this is that the Android build process requires direct access to the application's assets folder. During its build process, a Java source file, R.java, will be automatically generated under the gen folder. It contains special information for Android about the available assets. It will be the usual way to access assets through the Java code if you were explicitly writing an Android application. However, in LibGDX, you will want to stay independent of the platform as much as possible and access any resource such as assets only through the methods provided by LibGDX. You will learn more about accessing resources in the last section of this chapter.
You might wonder how other platform-specific projects will be able to access the very same assets without having to maintain several copies per project. Needless to say this would require you to keep all copies manually synchronized each time the assets change.
Luckily, this problem has already been taken care of by the generator. The demo-desktop project uses a linked resource—a feature by Eclipse—to add existing files or folders to other places in a workspace. You can check this out by right-clicking on the demo-desktop project, navigating to Properties | Resource | Linked Resources, and then clicking on the Linked Resources tab.
The demo-html project requires another approach as Google Web Toolkit (GWT) has a different build process compared to other projects. There is a special file called GwtDefinition.gwt.xml that allows you to set the asset path by setting the gdx.assetpath configuration property to the assets folder of the Android project. Notice that it is good practice to use relative paths such as ../ android/assets so that the reference does not get broken if the workspace is moved from its original location. Take this advice as a precaution to protect you and your fellow developers from wasting precious time on something that can be easily avoided by using the right setup, right from the beginning.
The following is the code listing for GwtDefinition.gwt.xml from demo-html:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit trunk//EN" "http://google-web-toolkit.googlecode.com/svn/trunk/distro-source/core/src/gwt-module.dtd">
<module>
<inherits name='com.badlogic.gdx.backends.gdx_backends_gwt' />
<inherits name='MyDemo' />
<entry-pointclass='com.packtpub.libgdx.demo.client.GwtLauncher' />
<set-configuration-property name="gdx.assetpath" value="../ android/assets" />
</module>
Similar to the demo-html project, the demo-robovm project has a special file called robovm.xml that saves the path to the assets folder in demo-android. Notice the <directory> key under <resources>, where the relative path to the assets folder is set. However, this is not the end of resource setting for demo-robovm. In iOS projects, there will be some resources specific to iOS, such as icons and default splash images. You don't want to put this in your Android assets folder. So, put this in the folder named data in your demo-robovm project. The path of the folder is also linked in the robovm.xml file under <resources>.
Note
Unlike Android, iOS version needs specific names for icons to show in respective devices. For example, Icon-72.png is the name for the app icon on iPad. You can find specifics of the icon name and size at https://developer.apple.com/library/iOs/qa/qa1686/_index.html.
The following code snippet is taken from robovm.xml in our demo-robovm project:
<config>
<executableName>${app.executable}</executableName>
<mainClass>${app.mainclass}</mainClass>
<os>ios</os>
<arch>thumbv7</arch>
<target>ios</target>
<iosInfoPList>Info.plist.xml</iosInfoPList>
<resources>
<resource>
<directory>../android/assets</directory>
<includes>
<include>**</include>
</includes>
<skipPngCrush>true</skipPngCrush>
</resource>
<resource>
<directory>data</directory>
</resource>
</resources>
<forceLinkClasses>
<pattern>com.badlogic.gdx.scenes.scene2d.ui.*</pattern>
</forceLinkClasses>
<libs>
<lib>libs/ios/libgdx.a</lib>
<lib>libs/ios/libObjectAL.a</lib>
</libs>
<frameworks>
<framework>UIKit</framework>
<framework>OpenGLES</framework>
<framework>QuartzCore</framework>
<framework>CoreGraphics</framework>
<framework>OpenAL</framework>
<framework>AudioToolbox</framework>
<framework>AVFoundation</framework>
</frameworks>
</config>