Środowisko pracy — Visual Studio, .NET MAUI i emulatory

Po co się tego uczymy?

To najważniejsza różnica względem działu WPF: w .NET MAUI NIE MA wizualnego projektanta z przeciąganiem kontrolek na podgląd okna. Piszesz XAML ręcznie, a efekt sprawdzasz przez Hot Reload i emulator urządzenia mobilnego. Zanim napiszesz jakikolwiek kod, musisz sprawnie poruszać się po tym innym, "słabiej graficznym" warsztacie pracy — inaczej każda kolejna lekcja będzie frustrująca.

Teoria

Trzy możliwe środowiska — i dlaczego wybieramy Visual Studio

Środowisko	Platforma docelowa	Język
Android Studio	tylko Android	Kotlin / Java
Xcode	tylko iOS / macOS	Swift / Objective-C
Visual Studio + .NET MAUI	Android, iOS, Windows, macOS — z JEDNEGO kodu	C# i XAML

W tym dziale korzystamy wyłącznie z Visual Studio, bo pozwala wykorzystać znajomość C# z wcześniejszych działów (konsola, WPF) i jednym projektem obsłużyć kilka platform naraz.

Instalacja — obciążenie ".NET Multi-platform App UI development"

W Visual Studio Installer trzeba zaznaczyć obciążenie ".NET Multi-platform App UI development" (Programowanie wieloplatformowych aplikacji .NET). Instalator pobiera wtedy dodatkowo: szablony projektów MAUI, Android SDK (zestaw narzędzi do budowania i uruchamiania aplikacji na Androida) oraz obrazy emulatora Androida. To duża instalacja (kilka GB) — zaplanuj na nią czas i miejsce na dysku.

Kluczowa różnica względem WPF: brak projektanta wizualnego

W WPF przeciągałeś kontrolki z Toolboxa na podgląd okna, a Visual Studio dopisywał XAML za Ciebie. W .NET MAUI ten podgląd typu "przeciągnij i upuść" jest znacznie bardziej ograniczony i w praktyce prawie nieużywany — XAML pisze się ręcznie, a Visual Studio wspiera Cię przez:

IntelliSense — podpowiedzi nazw kontrolek i właściwości podczas pisania XAML (dokładnie jak w C#);
XAML Hot Reload — zmieniasz kod XAML, zapisujesz plik, a aplikacja NA URUCHOMIONYM emulatorze/urządzeniu aktualizuje wygląd BEZ ponownego budowania i restartu. To absolutnie kluczowe narzędzie w tym dziale — znacznie przyspiesza pracę, bo pełne budowanie aplikacji mobilnej trwa dłużej niż WPF;
XAML Live Preview (zakładka podglądu przy edytorze) — przybliżony podgląd wyglądu strony bez uruchamiania całej aplikacji, choć bywa mniej dokładny niż faktyczne uruchomienie.

Dlatego w tym dziale dużo bardziej niż w WPF liczy się umiejętność CZYTANIA i pisania XAML wprost z klawiatury — a nie klikania w gotowe elementy.

Emulator Androida — jak go skonfigurować

Testowanie aplikacji mobilnej wymaga albo emulatora (wirtualne urządzenie na komputerze), albo prawdziwego telefonu podłączonego kablem USB z włączonym trybem debugowania (Ustawienia → Opcje programistyczne → Debugowanie USB, w Androidzie).

Emulator konfigurujesz w Visual Studio przez Android Device Manager (Narzędzia → Android → Android Device Manager): tworzysz nowe wirtualne urządzenie, wybierając model telefonu i wersję Androida (API Level), a następnie pobierasz odpowiedni obraz systemu. Im nowszy emulator, tym więcej zasobów komputera zużywa — na słabszych komputerach uruchamianie emulatora bywa zauważalnie wolne.

Wybór platformy docelowej przed uruchomieniem

Na pasku narzędzi Visual Studio, obok przycisku uruchamiania, znajduje się rozwijana lista z docelową platformą (np. konkretny emulator Androida, "Windows Machine" do uruchomienia jako aplikacja Windows, albo "Mac Catalyst"). Trzeba jawnie wybrać, na czym aplikacja ma się uruchomić — inaczej dostaniesz błąd braku urządzenia docelowego.

Schemat

Roznica: WPF vs .NET MAUI - jak sprawdzasz wyglad interfejsu

WPF:
  Toolbox -> przeciagnij kontrolke -> od razu widac w Designerze
  (podglad na biezaco, w oknie edytora, bez uruchamiania appki)

.NET MAUI:
  Pisz XAML recznie (IntelliSense pomaga) -> zapisz plik
       -> Hot Reload odswieza WYGLAD na URUCHOMIONYM emulatorze
       (musisz miec wczesniej odpalona appke na emulatorze/telefonie)

Przykład z życia

To trochę jak różnica między edytowaniem strony internetowej w edytorze WYSIWYG (widzisz od razu efekt) a pisaniem czystego kodu HTML/CSS z podglądem na żywo w przeglądarce po zapisaniu pliku — musisz umieć "wyobrazić sobie" efekt, patrząc na sam kod, i weryfikować go po zapisaniu, a nie klikając gotowe elementy z palety.

PierwszaAplikacjaMaui.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net9.0-android;net9.0-ios;net9.0-maccatalyst</TargetFrameworks>
    <TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows'))">$(TargetFrameworks);net9.0-windows10.0.19041.0</TargetFrameworks>
    <OutputType>Exe</OutputType>
    <RootNamespace>PierwszaAplikacjaMaui</RootNamespace>
    <UseMaui>true</UseMaui>
    <SingleProject>true</SingleProject>
    <ApplicationTitle>PierwszaAplikacjaMaui</ApplicationTitle>
    <ApplicationId>com.uczen.pierwszaaplikacjamaui</ApplicationId>
  </PropertyGroup>

</Project>

Komentarz i wyjaśnienie kodu

To fragment pliku .csproj projektu MAUI — od razu widać kluczową różnicę względem WPF: TargetFrameworks (liczba mnoga!) wymienia WIELE platform naraz oddzielonych średnikiem (net9.0-android, net9.0-ios, net9.0-maccatalyst, warunkowo net9.0-windows... tylko gdy budujesz na Windows). To właśnie ta jedna linijka sprawia, że ten sam projekt kompiluje się na kilka zupełnie różnych systemów.

UseMaui>true</UseMaui> — włącza obsługę MAUI (analogicznie do UseWPF w WPF);
SingleProject>true</SingleProject> — to nowoczesne podejście MAUI: JEDEN projekt zamiast osobnych projektów dla każdej platformy (starszy Xamarin.Forms wymagał osobnego projektu na Androida, osobnego na iOS itd.);
ApplicationId — unikalny identyfikator aplikacji w formacie odwróconej domeny (com.firma.nazwaaplikacji) — to on trafi później do Google Play przy publikacji.

Ćwiczenie samodzielne

Zainstaluj Visual Studio 2022 z obciążeniem ".NET Multi-platform App UI development" (jeśli jeszcze nie masz). Otwórz Android Device Manager i utwórz jedno wirtualne urządzenie (np. Pixel 5, najnowsze dostępne API). Uruchom emulator (może to potrwać kilka minut przy pierwszym starcie) i zostaw go włączonego — przyda się w kolejnej lekcji.

Zadania do pracy własnej

Wypisz trzy różnice między pracą w WPF a pracą w .NET MAUI, o których była mowa w tej lekcji.
Sprawdź w swoim Visual Studio (lub w dokumentacji Microsoft Learn), jakie wersje Androida (API Level) są dostępne do wyboru przy tworzeniu nowego wirtualnego urządzenia w Android Device Manager. Zapisz 3 najnowsze.
Utwórz DWA wirtualne urządzenia o różnych rozmiarach ekranu (np. telefon i tablet) w Android Device Manager. Uruchom oba jednocześnie (jeśli komputer to udźwignie) i zanotuj, ile czasu zajęło uruchomienie każdego z nich — to praktyczna lekcja o tym, dlaczego programiści MAUI cenią sobie Hot Reload zamiast ciągłego restartowania emulatora.

Typowe błędy

Brak zaznaczonego obciążenia MAUI podczas instalacji — bez niego szablony projektów .NET MAUI w ogóle się nie pojawią w Visual Studio.

Oczekiwanie na wizualny projektant jak w WPF — początkujący często szukają Toolboxa do przeciągania kontrolek i się zniechęcają, gdy go nie znajdują. W MAUI trzeba przestawić się na pisanie XAML ręcznie.

Zbyt "ciężki" emulator na słabszym komputerze — wybranie najnowszego, najbardziej zasobożernego obrazu systemu może sprawić, że emulator ledwo się uruchamia. Na starszym sprzęcie lepiej wybrać starszy, lżejszy obraz Androida.

Zapominanie o wyborze platformy docelowej — jeśli na pasku narzędzi nie jest wybrany żaden emulator/urządzenie, przycisk uruchamiania będzie nieaktywny albo zgłosi błąd.

Nawiązanie do egzaminu zawodowego

To realizacja INF.04.6.1 — "wykorzystuje środowisko programistyczne dla aplikacji mobilnych". Sprawne poruszanie się po Visual Studio + .NET MAUI, w tym konfiguracja emulatora i korzystanie z Hot Reload zamiast wizualnego projektanta, jest niezbędne do wykonania każdego kolejnego zadania w tym dziale — również na egzaminie praktycznym.