Udostępnij za pośrednictwem


Cykl życia tworzenia oprogramowania dla urządzeń przenośnych

Tworzenie aplikacji mobilnych może być tak proste, jak otwieranie programu Visual Studio, zgłaszanie czegoś razem, przeprowadzanie szybkiego testowania i przesyłanie do sklepu App Store — wszystko to odbywa się po południu. Może to być bardzo zaangażowany proces, który obejmuje rygorystyczny projekt z góry, testowanie użyteczności, testowanie jakości na tysiącach urządzeń, pełny cykl życia beta, a następnie wdrażanie na wiele różnych sposobów.

W tym dokumencie przejdziemy gruntowną analizę wprowadzającą do tworzenia aplikacji mobilnych, w tym:

  1. Proces — proces tworzenia oprogramowania jest nazywany cyklem życia tworzenia oprogramowania (SDLC). Przeanalizujemy wszystkie fazy sdLC w odniesieniu do tworzenia aplikacji mobilnych, w tym: Inception, Design, Development, Stabilization, Deployment i Maintenance.
  2. Zagadnienia — podczas tworzenia aplikacji mobilnych należy wziąć pod uwagę wiele zagadnień, szczególnie w przeciwieństwie do tradycyjnych aplikacji internetowych lub klasycznych. Przyjrzymy się tym zagadnieniom i sposobom ich wpływu na opracowywanie aplikacji mobilnych.

Ten dokument ma odpowiadać na podstawowe pytania dotyczące tworzenia aplikacji mobilnych, zarówno dla nowych, jak i doświadczonych deweloperów aplikacji. Wymaga to dość kompleksowego podejścia do wprowadzenia większości pojęć, które zostaną wprowadzone podczas całego cyklu życia tworzenia oprogramowania (SDLC). Jednak ten dokument może nie być dla wszystkich, jeśli swędzisz się po prostu rozpocząć tworzenie aplikacji, zalecamy przejście do przewodnika Wprowadzenie do tworzenia aplikacji mobilnych , a następnie powrót do tego dokumentu później.

Cykl życia oprogramowania do tworzenia aplikacji mobilnych

Cykl życia tworzenia aplikacji mobilnych nie różni się w dużej mierze od standardu SDLC dla aplikacji internetowych lub klasycznych. Podobnie jak w przypadku tych, zwykle istnieje 5 głównych części procesu:

  1. Inception — wszystkie aplikacje zaczynają się od pomysłu. Ten pomysł jest zwykle uściśliony w solidne podstawy dla aplikacji.
  2. Projektowanie — faza projektowania składa się z definiowania środowiska użytkownika (UX) aplikacji, takiego jak ogólny układ, jego działanie itp., a także przekształcenie tego środowiska użytkownika w odpowiedni projekt interfejsu użytkownika, zwykle za pomocą projektanta graficznego.
  3. Programowanie — zazwyczaj najbardziej intensywnie obciążana faza, jest to rzeczywista kompilacja aplikacji.
  4. Stabilizacja — gdy programowanie jest wystarczająco daleko, kontrola jakości zwykle zaczyna testować aplikację i naprawiane są błędy. Często aplikacja przechodzi do ograniczonej fazy beta, w której szersza grupa użytkowników ma szansę na korzystanie z niej i przekazać opinię i poinformować o zmianach.
  5. Wdrożenie

Często wiele z tych elementów nakłada się na siebie, na przykład często zdarza się, że programowanie trwa, gdy interfejs użytkownika jest finalizowany, a nawet może poinformować projekt interfejsu użytkownika. Ponadto aplikacja może przejść do fazy stabilizacji w taki sam sposób, że nowe funkcje są dodawane do nowej wersji.

Ponadto te fazy mogą być używane w dowolnej liczbie metodologii SDLC, takich jak Agile, Spiral, Waterfall itp.

Każda z tych faz zostanie szczegółowo wyjaśniona w poniższych sekcjach.

Powstania

Wszechobecność i poziom interakcji osób z urządzeniami przenośnymi oznacza, że prawie każdy ma pomysł na aplikację mobilną. Urządzenia przenośne otwierają zupełnie nowy sposób interakcji z obliczeniami, internetem, a nawet infrastrukturą firmową.

Etap tworzenia polega na zdefiniowaniu i udoskonaleniu pomysłu dla aplikacji. Aby utworzyć pomyślną aplikację, należy zadać kilka podstawowych pytań. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę przed opublikowaniem aplikacji w jednym z publicznych sklepów App Store:

  • Przewaga konkurencyjna — czy istnieją już podobne aplikacje? Jeśli tak, jak ta aplikacja różni się od innych?

W przypadku aplikacji, które będą dystrybuowane w przedsiębiorstwie:

  • Integracja infrastruktury — jaka istniejąca infrastruktura zostanie zintegrowana z lub rozszerzona?

Ponadto aplikacje powinny być oceniane w kontekście formularza mobilnego:

  • Wartość — jaka wartość zapewnia użytkownikom ta aplikacja? Jak będą z niej korzystać?
  • Formularz/Mobilność — w jaki sposób ta aplikacja będzie działać w postaci mobilnej? Jak mogę dodać wartość przy użyciu technologii mobilnych, takich jak rozpoznawanie lokalizacji, aparat itp.?

Aby ułatwić projektowanie funkcji aplikacji, może być przydatne zdefiniowanie aktorów i przypadków użycia. Aktorzy są rolami w aplikacji i często są użytkownikami. Przypadki użycia to zazwyczaj akcje lub intencje.

Na przykład aplikacja do śledzenia zadań może mieć dwa aktorzy: użytkownik i znajomy. Użytkownik może utworzyć zadanie i udostępnić zadanie znajomemu. W takim przypadku utworzenie zadania i udostępnienie zadania to dwa odrębne przypadki użycia, które w połączeniu z aktorami będą informować o ekranach potrzebnych do skompilowania, a także o tym, jakie jednostki biznesowe i logika będą musiały zostać opracowane.

Po przechwyceniu odpowiedniej liczby przypadków użycia i aktorów znacznie łatwiej jest rozpocząć projektowanie aplikacji. Programowanie może następnie skupić się na sposobie tworzenia aplikacji, a nie na tym, czym jest lub powinna robić aplikacja.

Projektowanie aplikacji mobilnych

Po ustaleniu funkcji i funkcjonalności aplikacji następnym krokiem jest próba rozwiązania środowiska użytkownika lub środowiska użytkownika.

Projektowanie środowiska użytkownika

Środowisko użytkownika jest zwykle wykonywane za pośrednictwem szkieletów lub makietów przy użyciu jednego z wielu zestawów narzędzi projektowych. Makiety środowiska użytkownika umożliwiają projektowanie środowiska użytkownika bez konieczności martwienia się o rzeczywisty projekt interfejsu użytkownika:

UX is usually done via wireframes or mockups using tools such as Balsamiq

Podczas tworzenia makiety środowiska użytkownika ważne jest, aby wziąć pod uwagę wytyczne dotyczące interfejsu dla różnych platform, które będą przeznaczone dla aplikacji. Aplikacja powinna "czuć się w domu" na każdej platformie. Oficjalne wytyczne dotyczące projektowania dla każdej platformy to:

  1. Wytyczne dotyczące interfejsu człowieka firmy Apple -
  2. Androidwytyczne dotyczące projektowania
  3. UWPpodstawy projektowania platformy UNIWERSALNEJ systemu Windows

Na przykład każda aplikacja ma metaforę przełączania między sekcjami w aplikacji. System iOS używa paska tabulatora w dolnej części ekranu, system Android używa paska tabulatora w górnej części ekranu, a platforma UWP używa widoku przestawnego lub karty .

Ponadto sam sprzęt decyduje również o decyzjach dotyczących środowiska użytkownika. Na przykład urządzenia z systemem iOS nie mają fizycznego przycisku Wstecz i w związku z tym wprowadzono metaforę kontrolera nawigacji:

iOS devices have no physical back button, and therefore introduce the Navigation Controller metaphor

Ponadto współczynnik formularzy wpływa również na decyzje dotyczące środowiska użytkownika. Tablet ma o wiele więcej nieruchomości, a więc może wyświetlić więcej informacji. Często to, co wymaga wielu ekranów na telefonie, jest skompresowane do jednego dla tabletu:

Often what needs multiple screens on a phone is compressed into one for a tablet

A ze względu na niezliczone czynniki formy tam, często istnieją średniej wielkości formy (gdzieś między telefonem a tabletem), które mogą być również celowane.

Projekt interfejsu użytkownika

Po ustaleniu środowiska użytkownika następnym krokiem jest utworzenie projektu interfejsu użytkownika. Chociaż środowisko użytkownika jest zwykle tylko czarno-białe makiety, faza projektowania interfejsu użytkownika polega na tym, że kolory, grafika itp., są wprowadzane i finalizowane. Poświęcanie czasu na dobry projekt interfejsu użytkownika jest ważne i ogólnie rzecz biorąc, najpopularniejsze aplikacje mają profesjonalny projekt.

Podobnie jak w przypadku środowiska użytkownika, ważne jest, aby zrozumieć, że każda platforma ma własny język projektowania, więc dobrze zaprojektowana aplikacja może nadal wyglądać inaczej na każdej platformie:

A well-designed application may still look different on each platform

Opracowywanie zawartości

Faza rozwoju zwykle rozpoczyna się bardzo wcześnie. W rzeczywistości, gdy pomysł ma pewne nasycenie w fazie koncepcyjnej/inspiracji, często tworzony jest działający prototyp, który weryfikuje funkcjonalność, założenia i pomaga zrozumieć zakres pracy.

W pozostałej części samouczków skupimy się głównie na fazie opracowywania.

Stabilizacja

Stabilizacja to proces wypracowania usterek w aplikacji. Nie tylko z punktu widzenia funkcjonalności, np. "Ulega awarii, gdy kliknę ten przycisk", ale także użyteczność i wydajność. Najlepiej jest rozpocząć stabilizację bardzo wcześnie w procesie rozwoju, aby korekty kursu mogły wystąpić, zanim staną się kosztowne. Zazwyczaj aplikacje przechodzą na etapy Prototyp, Alfa, Beta i Release Candidate . Różne osoby definiują je inaczej, ale zazwyczaj są zgodne z następującym wzorcem:

  1. Prototyp — aplikacja jest nadal w fazie weryfikacji koncepcji i działa tylko podstawowe funkcje lub konkretne części aplikacji. Występują główne usterki.
  2. Alpha — podstawowe funkcje są ogólnie ukończone w kodzie (kompilowane, ale nie w pełni przetestowane). Główne usterki są nadal obecne, funkcje outlying mogą nadal nie być obecne.
  3. Beta — większość funkcji jest teraz kompletna i miała co najmniej testy lekkie i naprawianie usterek. Główne znane problemy mogą być nadal obecne.
  4. Release Candidate — wszystkie funkcje są kompletne i przetestowane. Zakazu nowych usterek aplikacja jest kandydatem do wydania na środowisko dzikie.

Nigdy nie jest za wcześnie, aby rozpocząć testowanie aplikacji. Jeśli na przykład na etapie prototypu zostanie znaleziony poważny problem, środowisko użytkownika aplikacji może być nadal modyfikowane, aby go pomieścić. Jeśli problem z wydajnością zostanie znaleziony na etapie alfa, jest wystarczająco wcześnie, aby zmodyfikować architekturę, zanim wiele kodu zostało utworzonych na podstawie fałszywych założeń.

Zazwyczaj w miarę jak aplikacja przechodzi dalej w cyklu życia, jest otwarta dla większej liczby osób, aby wypróbować ją, przetestować, przekazać opinię itp. Na przykład prototypowe aplikacje mogą być wyświetlane lub udostępniane kluczowym uczestnikom projektu, natomiast aplikacje kandydatów do wydania mogą być dystrybuowane do klientów, którzy rejestrują się w celu uzyskania wczesnego dostępu.

W przypadku wczesnego testowania i wdrażania na stosunkowo niewielu urządzeniach zwykle wystarczy wdrożenie bezpośrednio z maszyny dewelopera. Jednak w miarę rozszerzania publiczności może to szybko stać się kłopotliwe. W związku z tym istnieje wiele opcji wdrażania testowego, które znacznie ułatwiają ten proces, umożliwiając zapraszanie osób do puli testów, kompilacje wydań za pośrednictwem Internetu i udostępniają narzędzia, które umożliwiają przesyłanie opinii użytkowników.

Do testowania i wdrażania można używać centrum aplikacji do ciągłego kompilowania, testowania, wydawania i monitorowania aplikacji.

Dystrybucja

Gdy aplikacja zostanie ustabilizowana, nadszedł czas, aby wydostać się na wolność. Istnieje wiele różnych opcji dystrybucji, w zależności od platformy.

iOS

Platforma Xamarin.iOS i Objective-C aplikacje są dystrybuowane w dokładnie taki sam sposób:

  1. Apple App Store — sklep App Store firmy Apple to globalnie dostępne repozytorium aplikacji online wbudowane w system Mac OS X za pośrednictwem programu iTunes. Jest to zdecydowanie najbardziej popularna metoda dystrybucji dla aplikacji i umożliwia deweloperom wprowadzanie na rynek i rozpowszechnianie swoich aplikacji online przy bardzo niewielkim wysiłku.
  2. Wdrożenie wewnętrzne — wdrożenie wewnętrzne jest przeznaczone do wewnętrznej dystrybucji aplikacji firmowych, które nie są dostępne publicznie za pośrednictwem sklepu App Store.
  3. Wdrożenie ad hoc — wdrożenie ad hoc jest przeznaczone głównie do programowania i testowania i umożliwia wdrażanie na ograniczonej liczbie prawidłowo aprowizowania urządzeń. Podczas wdrażania na urządzeniu za pośrednictwem środowiska Xcode lub Visual Studio dla komputerów Mac jest on nazywany wdrożeniem ad hoc.

Android

Wszystkie aplikacje systemu Android muszą być podpisane przed dystrybucją. Deweloperzy podpisują swoje aplikacje przy użyciu własnego certyfikatu chronionego przez klucz prywatny. Ten certyfikat może zapewnić łańcuch autentyczności, który wiąże dewelopera aplikacji z aplikacjami utworzonymi i wydanymi przez dewelopera. Należy zauważyć, że podczas gdy certyfikat dewelopera dla systemu Android może być podpisany przez uznany urząd certyfikacji, większość deweloperów nie decyduje się na korzystanie z tych usług i samodzielne podpisywanie certyfikatów. Głównym celem certyfikatów jest rozróżnienie między różnymi deweloperami i aplikacjami. System Android używa tych informacji, aby pomóc w wymuszaniu delegowania uprawnień między aplikacjami i składnikami działającymi w systemie operacyjnym Android.

W przeciwieństwie do innych popularnych platform mobilnych system Android ma bardzo otwarte podejście do dystrybucji aplikacji. Urządzenia nie są zablokowane w jednym, zatwierdzonym sklepie z aplikacjami. Zamiast tego każda osoba może utworzyć sklep z aplikacjami, a większość telefonów z systemem Android zezwala na instalowanie aplikacji z tych sklepów innych firm.

Umożliwia to deweloperom potencjalnie większy jeszcze bardziej złożony kanał dystrybucji dla swoich aplikacji. Google Play to oficjalny sklep z aplikacjami Google, ale istnieje wiele innych. Oto kilka popularnych:

  1. AppBrain
  2. Amazon App Store dla systemu Android
  3. Handango
  4. GetJar

Platforma UWP

Aplikacje platformy UNIWERSALNEJ systemu Windows są dystrybuowane do użytkowników za pośrednictwem sklepu Microsoft Store. Deweloperzy przesyłają swoje aplikacje do zatwierdzenia, po czym pojawiają się w Sklepie. Aby uzyskać więcej informacji na temat publikowania aplikacji systemu Windows, zobacz dokumentację publikowania platformy UWP.

Zagadnienia dotyczące tworzenia aplikacji mobilnych

Podczas tworzenia aplikacji mobilnych nie różni się zasadniczo od tradycyjnego tworzenia aplikacji internetowych/klasycznych pod względem procesu lub architektury, należy pamiętać o pewnych zagadnieniach.

Typowe zagadnienia

Wielozadaniowość

Istnieją dwa istotne wyzwania związane z wielozadaniowością (posiadanie wielu aplikacji uruchomionych jednocześnie) na urządzeniu przenośnym. Po pierwsze, biorąc pod uwagę ograniczoną nieruchomość ekranu, trudno jest wyświetlić wiele aplikacji jednocześnie. W związku z tym na urządzeniach przenośnych tylko jedna aplikacja może znajdować się na pierwszym planie jednocześnie. Po drugie, otwieranie wielu aplikacji i wykonywanie zadań może szybko korzystać z zasilania baterii.

Każda platforma obsługuje wiele pytań w inny sposób, co zajmiemy się nieco.

Faktor

Urządzenia przenośne zazwyczaj należą do dwóch kategorii, telefonów i tabletów, z kilkoma urządzeniami krzyżowymi między nimi. Opracowywanie dla tych czynników formularzy jest na ogół bardzo podobne, jednak projektowanie aplikacji dla nich może być bardzo różne. Telefon mają bardzo ograniczoną ilość miejsca na ekranie, a tablety, choć większe, są nadal urządzeniami przenośnymi o mniejszej ilości miejsca na ekranie niż nawet większość laptopów. W związku z tym kontrolki interfejsu użytkownika platformy mobilnej zostały zaprojektowane specjalnie tak, aby były skuteczne na mniejszych czynnikach.

Fragmentacja urządzenia i systemu operacyjnego

Ważne jest, aby uwzględnić różne urządzenia w całym cyklu życia tworzenia oprogramowania:

  1. Koncepcja i planowanie — należy pamiętać, że sprzęt i funkcje różnią się w zależności od urządzenia, aplikacja, która opiera się na niektórych funkcjach, może nie działać prawidłowo na niektórych urządzeniach. Na przykład nie wszystkie urządzenia mają kamery, więc jeśli tworzysz aplikację do obsługi komunikatów wideo, niektóre urządzenia mogą być w stanie odtwarzać filmy wideo, ale nie zabierać ich.
  2. Projektowanie — podczas projektowania środowiska użytkownika aplikacji zwróć uwagę na różne proporcje ekranu i rozmiary na różnych urządzeniach. Ponadto podczas projektowania interfejsu użytkownika aplikacji należy rozważyć różne rozdzielczości ekranu.
  3. Programowanie — w przypadku korzystania z funkcji z kodu obecność tej funkcji powinna być zawsze testowana jako pierwsza. Na przykład przed użyciem funkcji urządzenia, takiej jak aparat fotograficzny, zawsze należy najpierw wysłać zapytanie do systemu operacyjnego o obecność tej funkcji. Następnie podczas inicjowania funkcji/urządzenia upewnij się, że zażądaj obecnie obsługi z systemu operacyjnego o tym urządzeniu, a następnie użyj tych ustawień konfiguracji.
  4. Testowanie — bardzo ważne jest, aby wcześnie i często testować aplikację na rzeczywistych urządzeniach. Nawet urządzenia z tymi samymi specyfikacjami sprzętowymi mogą się znacznie różnić w ich zachowaniu.

Ograniczone zasoby

Urządzenia przenośne są coraz bardziej wydajne przez cały czas, ale nadal są urządzeniami przenośnymi, które mają ograniczone możliwości w porównaniu z komputerami stacjonarnymi lub notesowymi. Na przykład deweloperzy klasyczni zazwyczaj nie martwią się o pojemności pamięci; są one używane do posiadania zarówno pamięci fizycznej, jak i wirtualnej w dużych ilościach, podczas gdy na urządzeniach przenośnych można szybko wykorzystać całą dostępną pamięć tylko przez załadowanie kilku obrazów wysokiej jakości.

Ponadto aplikacje intensywnie korzystające z procesora, takie jak gry lub rozpoznawanie tekstu, mogą naprawdę podatkować procesor mobilny i negatywnie wpływać na wydajność urządzeń.

Ze względu na takie zagadnienia ważne jest, aby inteligentnie kodować i wdrażać wczesne i często na rzeczywistych urządzeniach w celu zweryfikowania czasu reakcji.

Zagadnienia dotyczące systemu iOS

Wielozadaniowość

Wielozadaniowość jest bardzo ściśle kontrolowana w systemie iOS i istnieje wiele reguł i zachowań, które aplikacja musi być zgodna, gdy inna aplikacja przychodzi na pierwszy plan, w przeciwnym razie aplikacja zostanie zakończona przez system iOS.

Zasoby specyficzne dla urządzenia

W ramach określonego współczynnika form sprzęt może się znacznie różnić między różnymi modelami. Na przykład niektóre urządzenia mają tylny aparat fotograficzny, niektóre mają również przedni aparat fotograficzny, a niektóre nie mają żadnego.

Niektóre starsze urządzenia (i Telefon 3G i starsze) nawet nie zezwalają na wielozadaniowość.

Ze względu na te różnice między modelami urządzeń ważne jest sprawdzenie obecności funkcji przed podjęciem próby jej użycia.

Ograniczenia specyficzne dla systemu operacyjnego

Aby upewnić się, że aplikacje reagują i zabezpieczają, system iOS wymusza szereg reguł, które aplikacje muszą przestrzegać. Oprócz reguł dotyczących wielozadaniowości istnieje wiele metod zdarzeń, z których aplikacja musi zwrócić w określonym czasie, w przeciwnym razie zostanie ona zakończona przez system iOS.

Warto również zauważyć, że aplikacje działają w środowisku znanym jako piaskownica, które wymusza ograniczenia zabezpieczeń ograniczające dostęp do aplikacji. Na przykład aplikacja może odczytywać i zapisywać we własnym katalogu, ale jeśli próbuje zapisać w innym katalogu aplikacji, zostanie ona zakończona.

Zagadnienia dotyczące systemu Android

Wielozadaniowość

Wielozadaniowość w systemie Android ma dwa składniki; pierwszy to cykl życia działania. Każdy ekran w aplikacji systemu Android jest reprezentowany przez działanie i istnieje określony zestaw zdarzeń, które występują, gdy aplikacja zostanie umieszczona w tle lub pojawi się na pierwszym planie. Aplikacje muszą być zgodne z tym cyklem życia, aby tworzyć dynamiczne, dobrze zachowywane aplikacje. Aby uzyskać więcej informacji, zobacz Przewodnik cyklu życia działania.

Drugim składnikiem wielozadaniowości w systemie Android jest korzystanie z usług. Usługi to długotrwałe procesy, które istnieją niezależnie od aplikacji i są używane do wykonywania procesów, gdy aplikacja znajduje się w tle. Aby uzyskać więcej informacji, zobacz Przewodnik Dotyczący tworzenia usług .

Wiele urządzeń i wiele czynników form

Firma Google nie nakłada żadnych ograniczeń, na których urządzenia mogą uruchamiać system operacyjny Android. Ten otwarty paradygmat powoduje, że środowisko produktu wypełniane przez niezliczoną liczbę różnych urządzeń z zupełnie różnymi urządzeniami, rozdzielczościami ekranu i współczynnikami, funkcjami urządzeń i możliwościami.

Ze względu na skrajne rozdrobnienie urządzeń z systemem Android większość osób wybiera najpopularniejsze urządzenia z 5 lub 6 do projektowania i testowania i określania priorytetów.

Zagadnienia dotyczące zabezpieczeń

Aplikacje w systemie operacyjnym Android wszystkie działają w ramach odrębnej, izolowanej tożsamości z ograniczonymi uprawnieniami. Domyślnie aplikacje mogą robić bardzo mało. Na przykład bez specjalnych uprawnień aplikacja nie może wysłać wiadomości SMS, określić stan telefonu, a nawet uzyskać dostęp do Internetu! Aby uzyskać dostęp do tych funkcji, aplikacje muszą określić w pliku manifestu aplikacji, które mają uprawnienia i kiedy są instalowane; System operacyjny odczytuje te uprawnienia, powiadamia użytkownika, że aplikacja żąda tych uprawnień, a następnie umożliwia użytkownikowi kontynuowanie lub anulowanie instalacji. Jest to niezbędny krok w modelu dystrybucji systemu Android ze względu na model otwartego sklepu z aplikacjami, ponieważ aplikacje nie są wyselekcjonowane w taki sposób, w jaki są dla systemu iOS, na przykład. Listę uprawnień aplikacji można znaleźć w artykule Dotyczącym uprawnień manifestu w dokumentacji systemu Android.

Zagadnienia dotyczące systemu Windows

Wielozadaniowość

Wielozadaniowość w systemie UWP ma dwie części: cykl życia stron i aplikacji oraz procesy w tle. Każdy ekran w aplikacji jest wystąpieniem klasy Page, która ma zdarzenia związane z aktywowaniem lub nieaktywnym (ze specjalnymi regułami obsługi stanu nieaktywnego lub "nagrobkiem").

Druga część to dostarczanie agentów w tle do przetwarzania zadań, nawet jeśli aplikacja nie jest uruchomiona na pierwszym planie.

Możliwości urządzenia

Mimo że sprzęt platformy UWP jest dość jednorodny, nadal istnieją składniki, które są opcjonalne i dlatego wymagają specjalnej analizy podczas kodowania. Opcjonalne możliwości sprzętowe obejmują kamerę, kompas i żyroskop. Istnieje również specjalna klasa o niskiej ilości pamięci (256 MB), która wymaga szczególnej uwagi, lub deweloperzy mogą zrezygnować z obsługi małej ilości pamięci.

Zagadnienia dotyczące zabezpieczeń

Aby uzyskać informacje na temat ważnych zagadnień dotyczących zabezpieczeń w systemie UWP, zapoznaj się z dokumentacją dotyczącą zabezpieczeń .

Podsumowanie

Ten przewodnik przedstawił wprowadzenie do sdLC, ponieważ dotyczy opracowywania aplikacji mobilnych. Wprowadzono ogólne zagadnienia dotyczące tworzenia aplikacji mobilnych i przeanalizowano szereg zagadnień specyficznych dla platformy, takich jak projektowanie, testowanie i wdrażanie.

Następne kroki