Powrót do strony głównej

Rozwój aplikacji Android bez doświadczenia: case z AI | 2500+ znaków

Praktyczny case tworzenia aplikacji Android do generowania znaczników UTM bez doświadczenia programowania. Szczegółowy rozbiór etapów technicznych, błędów przy pracy z AI i lifehacków do publikacji w Google Play. Rekomendacje dla deweloperów średniego i wyższego poziomu.

Jak stworzyć aplikację mobilną bez wiedzy programistycznej: rzeczywisty case
Advertisement 728x90

# Od znaczników UTM do Google Play: Jak nieprogramista stworzył aplikację na Androida za pomocą AI

Tworzenie aplikacji mobilnej bez doświadczenia w programowaniu — zadanie, które dziś stało się realne dzięki nowoczesnym narzędziom AI. Filolog, który opanował rozwój poprzez GPT, dzieli się kluczowymi lekcjami i technicznymi niuansami procesu. Te wskazówki pomogą nawet doświadczonym deweloperom uniknąć typowych pułapek przy pracy z LLM.

Od pomysłu do pierwszego prototypu: jak AI zastępuje wiedzę o składni

Projekt wystartował od prostego zapytania: automatyzacja generowania znaczników UTM dla kanałów Telegram. Zamiast szukać usług internetowych przez Google, użytkownik postanowił stworzyć własną aplikację na Androida, mimo braku doświadczenia w programowaniu. Pierwszym krokiem była analiza konkurencji w Google Play — wyniki pokazały brak specjalistycznych rozwiązań, co potwierdziło hipotezę o niskim jawnym zapotrzebowaniu, ale wysokim ukrytym bólu marketerów.

Prace rozpoczęły się od instalacji VS Code i podstawowej interakcji z GPT. System generował fragmenty kodu z instrukcjami, gdzie je umieścić w strukturze projektu. Na tym etapie wyszła krytyczna problem: AI często odwoływało się do nieistniejących plików lub folderów, wymagając ich ręcznego utworzenia. Na przykład, przy zapytaniu o ekran generowania znaczników model zwracał:

Google AdInline article slot
// MainActivity.java
public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        
        Button generateBtn = findViewById(R.id.generate_btn);
        generateBtn.setOnClickListener(v -> {
            String utmSource = ((EditText)findViewById(R.id.source_input)).getText().toString();
            // Logic generation UTM
        });
    }
}

Jednak plik activity_main.xml nie istniał w projekcie, co powodowało błędy kompilacji. Takie sytuacje powtarzały się, dopóki nie wdrożono systematycznego podejścia do weryfikacji każdego kroku.

Dlaczego LLM to nie panaceum: krytyczne myślenie jako podstawa wibkodowania

Główny wniosek z projektu: asystenci AI wymagają ciągłej kontroli ze strony człowieka. Nawet po wprowadzeniu trybu „Thinking” w modelach GPT pojawiały się sytuacje, gdy system ignorował podstawowe zasady rozwoju na Androida. Na przykład, przy generowaniu manifestu proponował przestarzałe uprawnienia:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

Zamiast aktualnego android.permission.QUERY_ALL_PACKAGES, co doprowadziło do odrzucenia publikacji w Google Play. Rozwiązanie przyszło po ręcznej sprawdzeniu dokumentacji Android 13.

Google AdInline article slot

Kluczowe okazały się trzy praktyki:

  • Sprawdzanie każdego pliku przed wprowadzeniem zmian — używanie git status do śledzenia struktury projektu
  • Testowanie w Expo Go — szybka iteracja bez budowania APK
  • Regularny audyt zależności — analiza package.json pod kątem przestarzałych pakietów

Te kroki zmniejszyły liczbę błędów o 70% po pierwszych dwóch tygodniach pracy. Szczególnie efektywna okazała się metoda archiwizacji całego projektu i przekazania go AI do analizy — takie podejście pozwoliło systemowi uwzględnić kontekst całej bazy kodu.

Droga przez Google Play Console: triki na przejście zamkniętego testowania

Publikacja w sklepie była drugim najtrudniejszym etapem. Google Play Console wymagało:

Google AdInline article slot
  • Opłaty 25 USD za konto dewelopera
  • Obowiązkowego zamkniętego testowania (14 dni, minimum 12 aktywnych testerów)
  • Polityki prywatności z publicznym URL

Kluczowy problem — znalezienie testerów z urządzeniami Android wśród znajomych. Rozwiązanie znalazło się na Reddit w subreddicie r/AndroidClosedTesting. Skuteczna strategia obejmuje:

  • Jednoczesną publikację własnego posta i udział w cudzych testach
  • Wymaganie codziennego używania aplikacji (Google sprawdza aktywność przez Firebase)
  • Zwiększenie liczby testerów do 30+ dla rekompensaty 50% nieaktywnych uczestników

Pierwsza odmowa od Google przyszła z powodu niskiej aktywności testerów. Analiza logów Firebase pokazała, że 60% uczestników otworzyło aplikację tylko raz w ciągu 14 dni. Po ponownym uruchomieniu z większą liczbą testerów i przypomnieniami przez bota Telegram proces zakończył się sukcesem.

Co zostaje po premierze: techniczne wskazówki dla początkujących deweloperów

Ostatni etap obejmował dopracowanie polityk i lokalizacji. Największa niespodzianka — stworzenie polityki prywatności. Google wymaga publicznego dokumentu, ale rozwiązanie okazało się proste:

  • Rejestracja domeny w stylu appname-privacy.info
  • Stworzenie strony przez Google Sites z szablonem
  • Integracja przez konto Gmail dewelopera

Ten proces zajął mniej niż 30 minut zamiast oczekiwanych dni na pełny site. Wyłoniono też ukryte niuanse:

  • Ikona aplikacji musi odpowiadać wytycznym Material You (dynamiczne kolory)
  • Wymagane obsługa safe zones dla nowoczesnych smartfonów
  • Obowiązkowe wsparcie dynamicznej lokalizacji przez strings.xml

Co ważne

  • Asystenci AI wymagają ciągłej weryfikacji kodu przez ręczny audyt
  • Zamknięte testowanie w Google Play działa efektywnie tylko przy aktywnym udziale testerów
  • Expo Go kluczowo przyspiesza rozwój cross-platform na React Native
  • Polityka prywatności jest obowiązkowa nawet dla aplikacji bez zbierania danych
  • Generatory UTM wymagają obsługi edge cases (znaki specjalne, długie parametry)

Projekt udowodnił, że stworzenie aplikacji mobilnej bez doświadczenia jest możliwe, ale wymaga systematycznego podejścia. Kluczowy wniosek: AI to nie zastępstwo dewelopera, lecz narzędzie wzmacniające jego kompetencje. Dla tych gotowych na eksperymenty, nowoczesne LLM otwierają drogę do MVP w 2-3 miesiące zamiast pół roku tradycyjnego rozwoju.

— Editorial Team

Advertisement 728x90

Czytaj dalej