Konfiguracja libGDX w IntelliJ IDEA

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ą.


Opublikowano

w

przez

Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *