Utworzenie nowego projektu opartego na bibliotece libGDX i wczytanie go do IntelliJ IDEA nie sprawia większych problemów, jednak ze względu na integrację z Gradle oraz fakt, że na początku nie wszystko konfiguruje się automatycznie, należy pamiętać o wykonaniu wszystkich wymaganych kroków.
Poniższy przykład wykorzystuje:
- IntelliJ IDEA w wersji 2017.1.4
- libGDX w wersji 1.9.6
- Android SDK z API 20 oraz Build Tools 23.0.1
- system operacyjny Linux (Ubuntu)
Instalator libGDX
Zaczynamy od pobrania i uruchomienia najnowszej wersji instalatora libGDX ze strony www.
cd ~/Pobrane wget https://libgdx.badlogicgames.com/nightlies/dist/gdx-setup.jar java -jar gdx-setup.jar
Następnie podajemy instalatorowi kilka podstawowych informacji o projekcie:
Name: nazwa aplikacji (zostanie zapisana do pliku build.gradle jako allprojects.ext.appName oraz do android/res/values/strings.xml jako app_name)
Package: unikatowa nazwa pakietu dla aplikacji, zgodna ze standardem Java
Game class: główna klasa aplikacji, która będzie w zależności od platformy uruchamiana przez DesktopLauncher lub AndroidLauncher (zostanie utworzona w katalogu core/nazwa_pakietu)
Destination: docelowy katalog, w którym zostanie utworzony projekt
Android SDK: katalog z zainstalowanym Android SDK
Sub Projects: docelowe platformy, na które będziemy kompilować aplikację (w tym przypadku zostawiamy tylko Desktop i Android)
Extensions: opcjonalne biblioteki, z których będzie dodatkowo korzystać aplikacja (ten przykład nie wykorzystuje żadnej z nich)
Show Third Party Extensions: kolejna lista dodatkowych bibliotek, których na razie nie będziemy używać
Advanced: opcje zaawansowane, możemy zostawić je wyłączone
Przed kliknięciem przycisku Generate, warto się jeszcze upewnić, że mamy zainstalowany Android SDK w odpowiedniej wersji. Minimalne zalecane wersje można znaleźć na stronie libGDX:
Wersje zainstalowane w systemie sprawdzamy przy pomocy skryptu znajdującego się w katalogu Android SDK ($ANDROID_HOME/tools/bin):
$ANDROID_HOME/tools/bin/sdkmanager --list
W moim przypadku:
Installed packages: Path | Version | Description | Location ------- | ------- | ------- | ------- build-tools;23.0.1 | 23.0.1 | Android SDK Build-Tools 23.0.1 | build-tools/23.0.1/ build-tools;25.0.2 | 25.0.2 | Android SDK Build-Tools 25.0.2 | build-tools/25.0.2/ build-tools;26.0.0 | 26.0.0 | Android SDK Build-Tools 26 | build-tools/26.0.0/ emulator | 26.0.3 | Android Emulator | emulator/ extras;android;m2repository | 47.0.0 | Android Support Repository, re... | extras/android/m2repository/ extras;google;m2repository | 54 | Google Repository | extras/google/m2repository/ patcher;v4 | 1 | SDK Patch Applier v4 | patcher/v4/ platform-tools | 26.0.0 | Android SDK Platform-Tools | platform-tools/ platforms;android-20 | 2 | Android SDK Platform 20, rev 2 | platforms/android-20/ platforms;android-25 | 3 | Android SDK Platform 25 | platforms/android-25/ sources;android-20 | 1 | Sources for Android 20 | sources/android-20/ sources;android-25 | 1 | Sources for Android 25 | sources/android-25/ tools | 26.0.2 | Android SDK Tools | tools/
Uruchamiamy generowanie projektu i czekamy na rozwój wydarzeń. Istnieje duże prawdopodobieństwo, że pojawi się nam ostrzeżenie:
Wybranie „No” spowoduje wymuszenie korzystania z narzędzi w wersji 23.0.1.
Analogicznie, kolejne pytanie będzie dotyczyło wersji API:
Wybranie „No” wymusi API 20.
W przypadku, gdy zdecydujemy się później na zmianę tych ustawień, wystarczy poprawić pliki w katalogu projektu:
android/AndroidManifest.xml:
<uses-sdk android:minSdkVersion="9" android:targetSdkVersion="20" />
android/build.gradle:
android { buildToolsVersion "23.0.1" compileSdkVersion 20 [...] defaultConfig { minSdkVersion 9 targetSdkVersion 20
Parametr minSdkVersion oznacza minimalną wersję systemu Android, na którym będzie można uruchomić aplikację. W przypadku libGDX jest to API 9 czyli Android 2.3 GINGERBREAD.
Po chwili projekt powinien być gotowy:
Wczytanie do IntelliJ IDEA
Kierując się podpowiedzią z instalatora, w głównym oknie IntelliJ IDEA wybieramy „Open” i wskazujemy plik build.gradle.
Następnie potwierdzamy, że chcemy go otworzyć jako projekt.
W ustawieniach importu Gradle ważne jest odznaczenie opcji „Create separate module per source set”.
Wszystkie moduły zostawiamy włączone.
Teraz musimy poczekać, aż wszystkie pliki zostaną zindeksowane. Dymkami z informacjami nie musimy się na razie przejmować.
Na liście konfiguracji powinien pojawić się „android”. Cel „desktop” trzeba dodać ręcznie.
W edytorze konfiguracji klikamy zielony plus i wybieramy „Application”.
Jako „Main class” wskazujemy klasę DesktopLauncher.
Katalog „Working directory” jest wspólny dla obu platform i powinien wskazywać na „android/assets”. W „Use classpath of module” wybieramy moduł desktop.
W podobny sposób, możemy sobie dodać skróty do zadań zdefiniowanych w Gradle:
Zadanie „clean” usuwa wszystkie pliki powstałe podczas kompilacji projektu:
Analogicznie możemy dodać android -> assembleRelease tworzące plik APK dla Androida (przed opublikowaniem trzeba go jeszcze podpisać cyfrowo).
Zadanie desktop -> dist tworzy paczkę JAR zawierającą wszystkie elementy potrzebne do uruchomienia projektu na Linux/Windows/MacOS.
Tak ostatecznie wygląda przykładowa lista konfiguracji:
Uwagi
Plugin Gradle dołączany do libGDX nie jest najnowszy, więc prędzej czy później wyświetli się nam komunikat z propozycją aktualizacji. Wystarczy kliknąć Update i poczekać na zakończenie instalacji.
Jeżeli korzystamy z dodatku FindBugs, podczas weryfikowania projektu pojawi się ostrzeżenie o błędach w generowanym automatycznie pliku R.java. Jako, że nie mamy wpływu na jego zawartość, najlepiej dodać go do wyjątków.
Listy wykluczeń są zapisywane w formacie XML a ich położenie można znaleźć w konfiguracji dodatku FindBugs w zakładce Filter.
Przykładowy plik findbugs-android-exclude.xml:
<?xml version="1.0" encoding="UTF-8"?> <FindBugsFilter> <Match> <Or> <Class name="~.*\.R\$.*"/> <Class name="~.*\.Manifest\$.*"/> </Or> </Match> </FindBugsFilter>
To w zasadzie wszystko. Możemy rozpocząć pracę nad naszą aplikacją.
Dodaj komentarz