Skocz do zawartości

Matthew11

Użytkownicy
  • Zawartość

    20
  • Rejestracja

  • Ostatnio

Reputacja

11 Dobra

O Matthew11

  • Ranga
    2/10

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. W takim razie dla osób, którym ostatecznie nie uda się skonfigurować Qt dla Androida pod Windowsem pozostaje zainstalowanie Qt na Linuxie i tam konfiguracja dla Androida, która powinna być zdecydowanie mniej problematyczna. W moim przypadku korzystałem z Ubuntu 18.04 @sp3uqw korzystał z Debiana 9.9. W linku https://doc.qt.io/qt-5/android-getting-started.html#installing-the-prerequisites znajduje się lista potrzebnych narzędzi. Są to te same co w przypadku Windowsa, z tą różnicą, że zamiast Javy od Oracle można skorzytać z OpenJDK.
  2. Okej, wersja Qt 5.12.4 oraz JDK(1.8.0_211) i NDK(r20) takie samo jak u @sp3uqw. Otrzymałem te same błędy, generalnie związane z androiddeployqt np: ...androiddeployqt.exe" exited with code 14. Następnie sprawdziłem wersje NDK r19c, r18b, r17c - efekt taki sam - błąd budowania. Za każdym razem zmiany wersji narzędzi resetowałem QtCreatora. Następnie wróciłem do wersji NDK 18c. I sprawdziłem na wersji JDK 1.8.0_191 - efekt taki sam - błąd budowania. Następnie przypadkowo sprawdziłem na jaką architekturę faktycznie buduję, był to ARM64v8a (Clang 5.12.4 ...), mój telefon to architektura x86 (aplikacja zbudowana pod ARM64v8a zadziała, ale widać gołym okiem, że nieco topornie), więc zmieniłem build na właściwą architekturę czyli x86. I wtedy... Qt ściągnęło mi Gradle, który buduje nam pliki aplikacji w formacie .apk, które potem wędrują na telefon. Fakt, że Qt ściąga nam Gradle zobaczymy w komunikatach kompilatora (pisałem o tym w jednej z części). Po tym jak Qt ściągnęło i zainstalowało Gradle, proces budowania zakończył się sukcesem. @sp3uqw @Mateuh czy podczas waszych procesów budowania zauważyliście, żeby Qt ściągało Gradle? Myśle, że problemem jest właśnie brak Gradle. Jak już udało mi się zbudować raz, to później wróciłem do NDKr20 i JDK1.8.0_211 czyli de facto najnowszych wersji i również nie miałem żadnych problemów z budowaniem na żadną z trzech architektur. Strzelam, że problem wynikał z braku Gradle, którego Qt automatycznie nie ściągało. Ciężko stwierdzić czy akurat zmiana docelowej architektury build'a spowodowała wywołanie procesu instalacji Gradle, ale może to jest sposób? Tak samo ciężko powiedzieć czy moja kombinacja zmian wersji narzędzi miała wpływ na ostateczny sukces - może ale niekoniecznie. W sytuacji gdy, nie uda się zainicjować instalacji Gradle przez Qt, może pomoże ręczna instalacja. Niestety to jest cena, którą trzeba zapłacić za Qt w wersji Open Source. Jak już raz się uda to więcej problemów konfiguracyjnych później nie ma. Z własnego doświadczenia radzę osobom, które tworzą jakiś projekt w Qt i wiążą się z tym jakieś umowy lub deklaracje to polecam nie zmieniać wersji Qt ani narzędzi w trakcie projektu jeśli nie musimy tego robić. A jak musimy to zachowajmy starą konfigurację.
  3. Komunikat wskazuje, że nadal budujesz na wersji 5.13. Sprawdź dla pewności ustawienia w QtCreatorze.
  4. Przy okazji zmiany wersji, Qt ma do tego specjalne narzędzie Qt Maintenance Tool. Instaluje się razem z Qt.
  5. @sp3uqw Problem może też wynikać z błędów (jeśli takie są) w wersji Qt 5.13 (wyszła gdzieś tydzień temu?) z informacji, które wrzuciłeś widać że korzystasz z tej wersji. W trakcie pisania kursu korzystałem z wersji 5.12.0, jak prosiłem @Treker o sprawdzenie to też korzystał z wersji 5.12.0 przy czym wystąpiły problemy z JDK (które musiało być w wersji 1.8 już niższej). @sp3uqw @Mateuh Niestety nie jest to najszybsze rozwiązanie ale, może instalacja Qt w wersji 5.12.0 lub niższej rozwiąże problem na Windows.
  6. @sp3uqw wysłał mi pełną informacje z konsoli, która zaprowadziła mnie tutaj: https://stackoverflow.com/questions/56621970/clang-error-linker-command-failed-with-exit-code-1-qt-android i tutaj: https://forum.qt.io/topic/103713/error-cannot-find-lc-qt-5-12-android/5 Opcje są dwie: 1. Użyć NDK w wersji NDK r19c https://developer.android.com/ndk/downloads/older_releases 2. Dodać zmiany w qmake (post użytkownika Albertino z drugiego linku u samej góry) Może to też być problem z wersją JDK (zdarzały mi się takie). @Mateuh @sp3uqw dajcie znać czy te informacje pomogły. Dla użytkowników Linuxa: miałem przyjemność konfigurować Qt dla Androida na Ubuntu 18.04 - nie miałem żadnych problemów, wszystko udało się za pierwszym razem w przeciwieństwie do moich poprzednich konfiguracji na Windows gdzie problemy miałem zawsze. Dla zainteresowanych wymagane narzędzia: https://doc.qt.io/qt-5/android-getting-started.html#installing-the-prerequisites. Nie rozwiązuje to problemów użytkowników Windowsa, ale jest to jakaś alternatywa.
  7. Bardzo cenna uwaga (y). Dla czytelników, którzy bedą to czytać - zawsze zwalniajcie poprawnie pamięć w swoich programach niezależne od sytuacji - w tym przykładzie akurat taki memory leak to jeszcze nie jest nic złego. Tworzymy obiekt QSerialPort raz i żyje on sobie do momentu aż proces naszej aplikacji się zakończy, wtedy pamięć po naszym obiekcie powinien zwolnić system (powinien jeśli to obsługuje - dyskusja na stacku). Sprawa przybrałaby bardzo nieprzyjemny obrót gdybyśmy tworzyli nowe obiekty cyklicznie i nie zwalniali po nich pamięci, a nasz program miałby pracować przez długi czas. Więc szanujmy naszą pamięć. Jest tutaj jeszcze jeden wysublimowany problem: gdybyśmy otworzyli port i zamknęli aplikację (wcześniej tego portu nie zamykając) to nie wywoła się destruktor obiektu QSerialPort, który między innymi ten port zamyka gdy jest otwarty. Wtedy przy ponownym uruchomieniu aplikacji moglibyśmy się bardzo zirytować niemogąc otworzyć portu ponownie (kto miał taki problem ten wie). Poprawka powinna się niedługo pojawić na stronie.
  8. O QML i QtQuick tylko wspominam, że takie moduły są i że można zrobić z nimi fajne projekty. Może zrobię kolejną część, w której obsługa komunikacji zostanie w C++ a interfejs zostanie przeniesiony do QML? Zobaczymy jaka będzie popularność na koniec planowanej serii. Zobaczymy (y)
  9. Z mojej strony wszystko jest gotowe, reszta zależy już od @Treker.
  10. To żależy co masz na myśli pisząc "przez neta"? Czy przez WiFi (aplikacja <-> urządzenie) czy przez serwer/chmurę (aplikacja <-> serwer <-> urządzenie). Bo w tym pierwszym przypadku wydaje mi się, że jest to porównywalny nakład pracy co w przypadku portu szeregowego czy BT. Natomiast w tym drugim przypadku nie mam żadnego doświadczenia ale na pewno dochodzą do tego sprawy związane z obsługą serwera. Może ktoś inny miał doświadczenie w tego typu rozwiązaniach i jest w stanie opisać krótko jak to wygląda od kuchni?
  11. Dokładnie takie proste sterowanie pojawi się w kolejnych częściach, najpierw za pomocą aplikacji na desktopie i portu szeregowego a w kolejnej części za pomocą aplikacji w telefonie i BT.
  12. @SOYER Małe sprostowanie - Qt samo w sobie nie zastąpi Ci całej infrastruktury Blynka (mówię tutaj głównie o chmurze), nawet mając aplikację w Qt nadal musisz mieć gdzieś działający serwer, z którym będziesz mógł się połączyć. Ale gdy już będziesz taki posiadał, to za pomocą swojej aplikacji w końcu się z nim dogadasz.
  13. @SOYER Oczywiście że się da, jedyne co Cię ogranicza to zasoby, chęci i własny czas. Warto sprawdzić jaki soft działa zbudowany na Qt np. Google Earth albo Origin od EA (i żeby było śmieszniej to korzystają z licencji open source).
  14. Ja piszę w C++ korzystając z Qt i robi się to całkiem przyjemnie. Pisałem aplikacje korzystające z BT i BLE (Android), widziałem też źródła projektu który wykorzystywał WiFi i UDP w sposób jaki Ty chcesz to wykorzystać. Natomiast nie miałem okazji pracować z iOS, nie mniej Qt zapewnia wsparcie dla iOS 11, iOS 12: https://doc.qt.io/qt-5/ios.html#supported-configurations Jeśli przekona Cię Qt to zainteresuj się koniecznie modułem QtQuick (połączenie QML i JS), w którym będziesz mógł napisać cały frontend w nowoczesny sposób a backend postawić na C++.
×
×
  • Utwórz nowe...