Inhaltsverzeichnis
Hallo, Android: Ausführliche Erläuterungen
Artikel
09/21/2022
17 Minuten Lesedauer
7 Mitwirkende Feedback
In diesem Artikel
In diesem zweiteiligen Leitfaden erstellen Sie Ihre erste Xamarin.Android-Anwendung. Außerdem entwickeln Sie ein Verständnis für die grundlegenden Aspekte der Entwicklung von Android-Anwendungen mit Xamarin. Währenddessen werden Ihnen die Tools, Konzepte und Schritte vorgestellt, die zum Erstellen und Bereitstellen einer Xamarin.Android-Anwendung erforderlich sind.
Im Artikel Hello, Android Quickstart (Hallo, Android: Schnellstart) haben Sie Ihre erste Xamarin.Android-Anwendung erstellt und ausgeführt. Nun ist es an der Zeit, ein tieferes Verständnis für die Funktionsweise von Android-Anwendungen zu entwickeln, sodass Sie komplexere Programme erstellen können. In diesem Leitfaden werden die Schritte überprüft, die Sie in der exemplarischen Vorgehensweise zu „Hallo, Android“ vorgenommen haben, sodass Sie ein Verständnis für die bisher ausgeführten Schritte und grundlegende Kenntnisse über die Entwicklung von Android-Anwendungen entwickeln können.
Dieser Leitfaden befasst sich mit folgenden Themen:
Einführung in Visual Studio – Einführung in Visual Studio und Erstellen einer neuen Xamarin.Android-Anwendung.
Anatomie einer Xamarin.Android-Anwendung – Tour der wesentlichen Teile einer Xamarin.Android-Anwendung .
Grundlagen der App-Grundlagen und Architektur – Einführung in Aktivitäten, das Android-Manifest und den allgemeinen Geschmack der Android-Entwicklung.
Benutzeroberfläche (Benutzeroberfläche) – Erstellen von Benutzeroberflächen mit dem Android Designer.
Aktivitäten und der Aktivitätslebenszyklus – Eine Einführung in den Aktivitätslebenszyklus und die Verkabelung der Benutzeroberfläche im Code.
Testen, Bereitstellen und Beenden von Toucheingaben – Schließen Sie Ihre Anwendung mit Beratung zum Testen, Bereitstellen, Generieren von Kunstwerken und vieles mehr ab.
Einführung in Visual Studio für Mac – Einführung in Visual Studio für Mac und Erstellen einer neuen Xamarin.Android-Anwendung.
Anatomie einer Xamarin.Android-Anwendung – Tour der wesentlichen Teile einer Xamarin.Android-Anwendung .
Grundlagen der App-Grundlagen und Architektur – Einführung in Aktivitäten, das Android-Manifest und den allgemeinen Geschmack der Android-Entwicklung.
Benutzeroberfläche (Benutzeroberfläche) – Erstellen von Benutzeroberflächen mit dem Android Designer.
Aktivitäten und der Aktivitätslebenszyklus – Eine Einführung in den Aktivitätslebenszyklus und die Verkabelung der Benutzeroberfläche im Code.
Testen, Bereitstellen und Beenden von Toucheingaben – Schließen Sie Ihre Anwendung mit Beratung zum Testen, Bereitstellen, Generieren von Kunstwerken und vieles mehr ab.
Dieser Leitfaden unterstützt Sie dabei, die Fertigkeiten und Kenntnisse zu entwickeln, die zum Erstellen einer Android-Anwendung für einen Bildschirm erforderlich sind. Nachdem Sie diesen durchgearbeitet haben, sollten Sie die verschiedenen Bestandteile einer Xamarin.Android-Anwendung und deren Zusammenwirken verstehen können.
Einführung in Visual Studio Visual Studio ist eine leistungsstarke IDE von Microsoft. Sie enthält z.B. einen vollständig integrierten visuellen Designer, einen Text-Editor mit Refactoringtools, einen Assembly-Browser und Quellcodeintegration. In diesem Leitfaden erfahren Sie mehr über die Verwendung einiger grundlegender Funktionen von Visual Studio mit dem Xamarin-Plug-In. In Visual Studio wird Code in Projektmappen und Projekten organisiert. Eine Projektmappe ist ein Container, der mindestens ein Projekt enthält. Ein Projekt kann beispielsweise eine Anwendung (z.B. für iOS oder Android), eine unterstützende Bibliothek oder eine Testanwendung sein. In der App Phoneword haben Sie mithilfe der Vorlage Android Application ein neues Android-Projekt zur Phoneword-Projektmappe hinzugefügt, die im Leitfaden Hello, Android (Hallo, Android) erstellt wurde.
Einführung in Visual Studio für Mac Visual Studio für Mac ist eine kostenlose Open-Source-IDE, die Visual Studio ähnelt. Sie enthält z.B. einen vollständig integrierten visuellen Designer, einen Text-Editor mit Refactoringtools, einen Assembly-Browser und Quellcodeintegration. In diesem Handbuch erfahren Sie mehr über die Verwendung einiger grundlegender Funktionen von Visual Studio für Mac. Wenn Sie mit Visual Studio für Mac noch nicht vertraut sind, sollten Sie für weitere Informationen die Einführung in Visual Studio für Mac aufrufen. Die Codeorganisation in Visual Studio für Mac baut auf Visual Studio auf und gliedert sich in Projektmappen und Projekte. Eine Projektmappe ist ein Container, der mindestens ein Projekt enthält. Ein Projekt kann beispielsweise eine Anwendung (z.B. für iOS oder Android), eine unterstützende Bibliothek oder eine Testanwendung sein. In der App Phoneword haben Sie mithilfe der Vorlage Android Application ein neues Android-Projekt zur Phoneword-Projektmappe hinzugefügt, die im Leitfaden Hello, Android (Hallo, Android) erstellt wurde.
Aufbau einer Xamarin.Android-Anwendung
Der folgende Screenshot listet die Inhalte der Projektmappe auf. Dies ist der Projektmappen-Explorer, der die Verzeichnisstruktur und alle Dateien enthält, die der Projektmappe zugeordnet sind:
Der folgende Screenshot listet die Inhalte der Projektmappe auf. Dies ist das Lösungspad, das die Verzeichnisstruktur und alle Dateien enthält, die der Projektmappe zugeordnet sind:
Eine Projektmappe namens Phoneword wurde erstellt. In dieser wurde das Android-Projekt Phoneword platziert.
Betrachten Sie die Elemente innerhalb des Projekts, um jeden Ordner und seinen Zweck zu sehen:
Eigenschaften – Enthält die AndroidManifest.xml Datei, die alle Anforderungen für die Xamarin.Android-Anwendung beschreibt, einschließlich Name, Versionsnummer und Berechtigungen. Der Ordner Eigenschaften enthält ebenfalls eine Metadatendatei der .NET-Assembly. Es wird empfohlen, diese Datei mit grundlegenden Informationen zu Ihrer Anwendung zu füllen.
Verweise – Enthält die Assemblys, die zum Erstellen und Ausführen der Anwendung erforderlich sind. Wenn Sie das Verzeichnis „Verweise“ erweitern, werden Ihnen die Verweise zu .NET-Assemblys angezeigt, z.B. System, System.Core und System.xml, sowie ein Verweis zur Mono.Android-Assembly von Xamarin.
Ressourcen – Enthält die Dateien, die die Anwendung ausführen muss, einschließlich Schriftarten, lokalen Datendateien und Textdateien. Auf die hier enthaltenen Dateien kann über die generierte Assets -Klasse zugegriffen werden. Weitere Informationen zu Android-Objekten finden Sie im Xamarin-LeitfadenUsing Android Assets (Verwenden von Android-Objekten).
Ressourcen – Enthält Anwendungsressourcen wie Zeichenfolgen, Bilder und Layouts. Sie können auf diese Ressourcen im Code über die generierte Resource -Klasse zugreifen. Der Leitfaden Android Resources (Android-Ressourcen) enthält weitere Informationen über das Verzeichnis Ressourcen. Die Anwendungsvorlage enthält ebenfalls einen kurzen Leitfaden zu Ressourcen in der Datei
Ressourcen
Das Verzeichnis Ressourcen enthält drei Ordner namens drawable, layout, mipmap und values sowie eine Datei namens
Diese Elemente werden in der folgenden Tabelle zusammengefasst:
zeichnend – Die zeichnungsfähigen Verzeichnisse haus zeichnende Ressourcen wie Bilder und Bitmaps.
mipmap – Das mipmap-Verzeichnis enthält gezeichnete Dateien für unterschiedliche Startfeldsymboldichten. In der Standardvorlage enthält das Verzeichnis „drawable“ die Anwendungssymboldatei, Icon.png.
layout – Das Layoutverzeichnis enthält Android-Designerdateien (.axml), die die Benutzeroberfläche für jeden Bildschirm oder jede Aktivität definieren. Die Vorlage erstellt ein Standardlayout namens activity_main.axml.
layout – Das Layoutverzeichnis enthält Android-Designerdateien (.axml), die die Benutzeroberfläche für jeden Bildschirm oder jede Aktivität definieren. Die Vorlage erstellt ein Standardlayout namens Main.axml.
werte – Dieses Verzeichnis enthält XML-Dateien, die einfache Werte wie Zeichenfolgen, ganze Zahlen und Farben speichern. Die Vorlage erstellt eine Datei namens Strings.xml , um Zeichenfolgenwerte zu speichern.
– Auch als Klasse bezeichnet Resource , ist diese Datei eine Teilklasse, die die eindeutigen IDs enthält, die jeder Ressource zugewiesen sind. Diese wird automatisch von den Xamarin.Android-Tools erstellt und kann bei Bedarf erneut generiert werden. Diese Datei sollte nicht manuell bearbeitet werden, da Xamarin.Android alle manuellen Änderungen überschreibt.
Grundlagen zu Apps und Architektur
Android-Anwendungen verfügen nicht über einen einzigen Einstiegspunkt. Das bedeutet, dass es keine einzelne Codezeile in der Anwendung gibt, die das Betriebssystem aufruft, um die Anwendung zu starten. Stattdessen startet eine Anwendung, wenn Android eine ihrer Klassen instanziiert. Während dieses Zeitraums lädt Android den gesamten Prozess der Anwendung in den Arbeitsspeicher.
Diese einzigartige Funktion von Android kann äußerst hilfreich beim Entwerfen von komplizierten Anwendungen oder beim Interagieren mit dem Android-Betriebssystem sein. Diese Optionen machen Android jedoch im Umgang mit einem grundlegenden Szenario wie der Anwendung Phoneword komplex. Aus diesem Grund ist die Erläuterung der Android-Architektur in zwei Teile aufgeteilt. Dieser Leitfaden analysiert eine Anwendung, die den häufigsten Einstiegspunkt für eine Android-App verwendet: den ersten Bildschirm. In Hello, Android Multiscreen („Hallo, Android“-Multiscreen) wird die gesamte Komplexität der Android-Architektur erläutert, da verschiedene Möglichkeiten behandelt werden, eine Anwendung zu starten.
Phoneword-Szenario: Starten mit einer Aktivität
Wenn Sie die Anwendung Phoneword zum ersten Mal in einem Emulator oder auf einem Gerät starten, erstellt das Betriebssystem die erste Aktivität. Eine Aktivität ist eine spezielle Android-Klasse, die einem einzelnen Anwendungsbildschirm entspricht und für das Zeichnen und Steuern der Benutzeroberfläche zuständig ist. Wenn Android die erste Aktivität einer Anwendung erstellt, wird die gesamte Anwendung geladen:
Da es keinen linearen Ablauf in einer Android-Anwendung gibt (Sie können die Anwendung von mehreren Punkten aus starten), bietet Android eine einzigartige Methode, um zu verfolgen, aus welchen Klassen und Dateien sich eine Anwendung zusammensetzt. Im Beispiel Phoneword sind alle Teile, die die Anwendung bilden, mit einer speziellen XML-Datei registriert, die als Android-Manifest bezeichnet wird. Die Rolle des Android-Manifests ist das Verfolgen der Inhalte, Eigenschaften und Berechtigungen einer Anwendung und das Offenlegen derselben für das Android-Betriebssystem. Sie können sich die Anwendung Phoneword wie im folgenden Diagramm dargestellt als einzelne Aktivität (Bildschirm) und Sammlung von Ressourcen und Hilfsprogrammdateien vorstellen, die von der Android-Manifestdatei miteinander verknüpft werden:
In den nächsten Abschnitten werden die Beziehungen zwischen den verschiedenen Teilen der Anwendung Phoneword erläutert. Dadurch sollten Sie das oben stehende Diagramm besser nachvollziehen können. Zunächst werden die Benutzeroberfläche sowie die Android Designer- und Layoutdateien erläutert.
Benutzeroberfläche
Tipp Neuere Releases von Visual Studio unterstützen das Öffnen von XML-Dateien in Android Designer. Sowohl AXML- als auch XML-Dateien werden in Android Designer unterstützt.
activity_main.axml ist die Layoutdatei der Benutzeroberfläche für den ersten Bildschirm in der Anwendung. Die Endung „.axml“ gibt an, dass es sich dabei um eine Android Designer-Datei handelt (AXML steht für Android XML). Der Name Main ist aus der Sicht von Android beliebig – die Layoutdatei könnte etwas anderes benannt worden sein. Wenn Sie activity_main.axml in der IDE öffnen, wird der visuelle Editor (Android Designer) für Android-Layoutdateien aufgerufen: In der App Phoneword ist die ID von TranslateButton auf @+id/TranslateButton festgelegt:
Main.axml ist die Layoutdatei der Benutzeroberfläche für den ersten Bildschirm in der Anwendung. Die Endung „.axml“ gibt an, dass es sich dabei um eine Android Designer-Datei handelt (AXML steht für Android XML). Der Name Main ist aus der Sicht von Android beliebig – die Layoutdatei könnte etwas anderes benannt worden sein. Wenn Sie Main.axml in der IDE öffnen, wird der visuelle Editor (Android Designer) für Android-Layoutdateien aufgerufen: In der App Phoneword ist die ID von TranslateButton auf @+id/TranslateButton festgelegt:
Wenn Sie die Eigenschaft id von TranslateButton festlegen, ordnet der Android Designer das Steuerelement TranslateButton der Resource -Klasse zu und weist diesem eine Ressourcen-ID von TranslateButton zu. Diese Zuordnung des visuellen Steuerelements zu einer Klasse ermöglicht es, TranslateButton und andere Steuerelemente im App-Code zu finden und zu verwenden. Weitere Informationen dazu erhalten Sie, wenn Sie den Code teilen, der die Steuerelemente steuert. Aktuell müssen Sie nur wissen, dass die Codedarstellung eines Steuerelements im Designer über die id -Eigenschaft mit der visuellen Darstellung des Steuerelements verknüpft ist.
Quellansicht
Alles, was auf der Entwurfsoberfläche definiert ist, wird für Xamarin.Android in XML übersetzt. Der Android Designer stellt eine Quellansicht bereit, die die XML-Datei enthält, die mit dem virtuellen Designer generiert wurde. Sie können diese XML-Datei anzeigen, indem Sie wie im folgenden Screenshot dargestellt zum Bereich Quelle unten links in der Designeransicht wechseln:
Dieser XML-Quellcode sollte vier Steuerelemente enthalten: zwei TextView-Elemente, ein EditText-Element und ein Button-Element. Weitere Informationen zum Android Designer finden Sie im Xamarin Android-Leitfaden Designer Overview (Übersicht über den Designer).
Die Tools und Konzepte hinter dem visuellen Teil der Benutzeroberfläche sind nun abgedeckt. Nun ist es an der Zeit, sich den Code anzusehen, der die Benutzeroberfläche steuert, während die Aktivitäten und der Aktivitätslebenszyklus erläutert werden.
Aktivitäten und Aktivitätslebenszyklus
Die Activity -Klasse enthält den Code, der die Benutzeroberfläche steuert. Die Aktivität ist dafür zuständig, auf Benutzerinteraktionen zu reagieren und eine dynamische Benutzeroberfläche zu erstellen. In diesem Abschnitt wird die Activity -Klasse eingeführt, der Aktivitätslebenszyklus erläutert und der Code analysiert, der die Benutzeroberfläche in der Anwendung Phoneword steuert.
Aktivitätsklasse
Die Anwendung Phoneword besitzt nur einen Bildschirm (Aktivität). Die MainActivity -Klasse steuert den Bildschirm und befindet sich in der Datei Der Name hat keine besondere Bedeutung in Android – obwohl die Konvention die erste Aktivität in einer Anwendung MainActivity benennen MainActivity soll, kümmert sich Android nicht darum, wenn es etwas anderes benannt wird.
Wenn Sie öffnen, können Sie sehen, dass die MainActivity -Klasse eine Unterklasse der Activity -Klasse ist und dass die Aktivität mit dem Attribut Activity versehen ist:
[Activity (Label = "Phone Word", MainLauncher = true)] public class MainActivity : Activity { ... }
Das Activity -Attribut registriert die Aktivität mit dem Android-Manifest. Dadurch weiß Android, dass diese Klasse Teil der Anwendung Phoneword ist, die von diesem Manifest verwaltet wird. Die Label -Eigenschaft legt den Text fest, der am oberen Rand des Bildschirms angezeigt wird.
Die MainLauncher -Eigenschaft teilt Android mit, diese Aktivität anzuzeigen, wenn die Anwendung gestartet wird. Diese Eigenschaft ist wichtig, wenn Sie wie im Leitfaden Hello, Android Multiscreen („Hallo, Android“-Multiscreen) beschrieben weitere Aktivitäten (Bildschirme) zur Anwendung hinzufügen.
Nachdem die Grundlagen von MainActivity behandelt wurden, ist es Zeit für tiefere Einblicke in den Aktivitätscode durch die Einführung des Aktivitätslebenszyklus.
Aktivitätslebenszyklus
In Android durchlaufen Aktivitäten abhängig von ihren Interaktionen mit dem Benutzer verschiedene Phasen eines Lebenszyklus. Aktivitäten können z.B. erstellt, gestartet und angehalten, fortgesetzt und gelöscht werden. Die Activity -Klasse enthält Methoden, die das System an bestimmten Punkten im Lebenszyklus des Bildschirms aufruft. Das folgende Diagramm stellt den typischen Lebenszyklus einer Aktivität sowie einige der entsprechenden Lebenszyklusmethoden dar:
Indem Sie die Activity -Lebenszyklusmethoden überschreiben, können Sie steuern, wie die Aktivität lädt, wie sie auf den Benutzer reagiert und sogar was passiert, nachdem diese auf dem Gerätebildschirm geschlossen wird. Sie können beispielsweise die Lebenszyklusmethoden im oben stehenden Diagramm überschreiben, um einige wichtige Aufgaben auszuführen:
OnCreate – Erstellt Ansichten, initialisiert Variablen und führt andere Vorarbeiten aus, die ausgeführt werden müssen, bevor der Benutzer die Aktivität sieht. Diese Methode wird nur einmal aufgerufen, wenn die Aktivität in den Arbeitsspeicher geladen wird.
OnResume – Führt alle Aufgaben aus, die jedes Mal auftreten müssen, wenn die Aktivität auf den Gerätebildschirm zurückgibt.
OnPause – Führt alle Aufgaben aus, die jedes Mal auftreten müssen, wenn die Aktivität den Gerätebildschirm verlässt.
Wenn Sie benutzerdefinierten Code zu einer Lebenszyklusmethode in der Activity hinzufügen, überschreiben Sie dadurch die Basisimplementierung dieser Lebenszyklusmethode. Navigieren Sie zur bestehenden Lebenszyklusmethode (der bereits Code angefügt wurde), und erweitern Sie diese Methode mit Ihrem eigenen Code. Rufen Sie die Basisimplementierung innerhalb Ihrer Methode auf, um sicherzustellen, dass der ursprüngliche Code vor Ihrem neuen Code ausgeführt wird. Ein Beispiel dafür wird im nächsten Abschnitt dargestellt.
Der Aktivitätslebenszyklus ist ein wichtiger und komplexer Teil von Android. Wenn Sie nach dem Abschluss der Reihe Erste Schritte mehr über Aktivitäten erfahren möchten, finden Sie weitere Informationen im Leitfaden Activity Lifecycle (Aktivitätslebenszyklus). In diesem Leitfaden liegt der nächste Schwerpunkt auf der ersten Phase des Aktivitätslebenszyklus, OnCreate .
OnCreate
Android ruft die OnCreate -Methode von Activity auf, wenn die Aktivität erstellt wird (bevor der Bildschirm dem Benutzer angezeigt wird). Sie können die OnCreate -Lebenszyklusmethode überschreiben, um Ansichten zu erstellen und Ihre Aktivität auf den Benutzer vorzubereiten:
protected override void OnCreate (Bundle bundle) { base.OnCreate (bundle); // Set our view from the "main" layout resource SetContentView (Resource.Layout.Main); // Additional setup code will go here }
In der Phoneword-App sollte in OnCreate zuerst die Benutzeroberfläche geladen werden, die im Android Designer erstellt wurde. Rufen Sie zum Laden der Benutzeroberfläche SetContentView auf, und übergeben Sie den Ressourcenlayoutnamen für die Layoutdatei: activity_main.axml. Das Layout befindet sich unter Resource.Layout.activity_main : SetContentView (Resource.Layout.activity_main); Wenn MainActivity gestartet wird, wird eine Ansicht basierend auf den Inhalten der Datei activity_main.axml erstellt.
In der Phoneword-App sollte in OnCreate zuerst die Benutzeroberfläche geladen werden, die im Android Designer erstellt wurde. Rufen Sie zum Laden der Benutzeroberfläche SetContentView auf, und übergeben Sie den Ressourcenlayoutnamen für die Layoutdatei: Main.axml. Das Layout befindet sich unter Resource.Layout.Main : SetContentView (Resource.Layout.Main); Wenn MainActivity gestartet wird, wird eine Ansicht basierend auf den Inhalten der Datei Main.axml erstellt. Beachten Sie, dass der Layoutdateiname dem Namen "Aktivität" entspricht – Main.axml ist das Layout für MainActivity. Dies ist aus der Sicht von Android nicht erforderlich. Wenn Sie jedoch weitere Bildschirme zur Anwendung hinzufügen, werden Sie feststellen, dass diese Namenskonvention die Zuordnung der Codedatei zur Layoutdatei erleichtert.
Nachdem die Layoutdatei vorbereitet ist, können Sie die Steuerelemente suchen. Rufen Sie zum Suchen eines Steuerelements FindViewById auf, und übergeben Sie die Ressourcen-ID des Steuerelements:
EditText phoneNumberText = FindViewById
Da nun Verweise zu den Steuerelementen in der Layoutdatei vorhanden sind, können Sie diese für die Reaktion auf Benutzerinteraktionen programmieren.
Reagieren auf eine Benutzerinteraktion
In Android wartet das Click -Ereignis auf die Toucheingabe des Benutzers. In dieser App wird das Click -Ereignis mit einem Lambdaausdruck behandelt, stattdessen könnte jedoch auch ein Delegat oder ein benannter Ereignishandler verwendet werden. Der endgültige Code für TranslateButton ähnelt Folgendem:
translateButton.Click += (sender, e) => { // Translate user's alphanumeric phone number to numeric translatedNumber = PhonewordTranslator.ToNumber(phoneNumberText.Text); if (string.IsNullOrWhiteSpace(translatedNumber)) { translatedPhoneWord.Text = string.Empty; } else { translatedPhoneWord.Text = translatedNumber; } };
Tests, Bereitstellung und Vollendung
Visual Studio für Mac und Visual Studio stellen beide viele Optionen zum Testen und Bereitstellen einer Anwendung bereit. In diesem Abschnitt werden Debugoptionen behandelt, das Testen von Anwendungen auf einem Gerät veranschaulicht und Tools für das Erstellen von benutzerdefinierten App-Symbolen für verschiedene Bildschirmdichten vorgestellt.
Probleme im Anwendungscode können schwer zu diagnostizieren sein. Für die Diagnose von komplexen Codeproblemen können Sie einen Breakpoint festlegen, Code schrittweise durchlaufen oder Informationen an das Protokollfenster ausgeben.
Bereitstellen für ein Gerät
Der Emulator ist für das Bereitstellen und das Testen einer Anwendung gut geeignet, jedoch wird die endgültige App vom Benutzer nicht in einem Emulator verwendet. Es wird empfohlen, Anwendungen frühzeitig und oft auf einem echten Gerät zu testen.
Bevor ein Android-Gerät für das Testen von Anwendungen verwendet werden kann, muss es für die Entwicklung konfiguriert werden. Der Leitfaden Set Up Device for Development (Einrichten eines Geräts für die Entwicklung) enthält umfassende Anweisungen, um ein Gerät für die Entwicklung vorzubereiten.
Nachdem das Gerät konfiguriert ist, können Sie auf dieses bereitstellen, indem Sie es anschließen, dieses aus dem Dialogfeld Gerät auswählen auswählen und die Anwendung starten:
Nachdem das Gerät konfiguriert ist, können Sie auf dieses bereitstellen, indem Sie es anschließen, auf Start (Play) (Start (Wiedergabe)) drücken, dieses aus dem Dialogfeld Gerät auswählen auswählen und auf OK drücken:
Dadurch wird die Anwendung auf dem Gerät gestartet:
Festlegen von Symbolen für verschiedene Bildschirmdichten
Bei Android-Geräten gibt es verschiedene Bildschirmgrößen und -auflösungen, sodass nicht alle Bilder auf allen Bildschirmen gut aussehen. Auf dem Screenshot sehen Sie beispielsweise ein Symbol mit geringer Dichte auf einem Nexus 5 mit hoher Dichte. Beachten Sie, wie unscharf dieses im Vergleich zu den umgebenden Symbolen ist:
Es wird empfohlen, dies zu berücksichtigen, indem Sie Symbole mit verschiedenen Auflösungen im Ordner Ressourcen hinzufügen. Android bietet verschiedene Versionen des Ordners mipmap, um Startprogrammsymbole mit verschiedenen Dichten zu verarbeiten: mdpi für mittlere Dichte, hdpi für hohe und xhdpi, xxhdpi und xxxhdpi für Bildschirme mit sehr hoher Dichte. Symbole mit unterschiedlicher Größe werden in den entsprechenden mipmap-Ordnern gespeichert:
Android wählt das Symbol mit der geeigneten Dichte aus:
Generieren von benutzerdefinierten Symbolen
Nicht jedem steht ein Designer zur Verfügung, der benutzerdefinierte Symbole und Startbilder erstellt, die eine App benötigt, um herauszustechen. Hier finden Sie einige alternative Ansätze, um benutzerdefinierte App-Grafiken zu generieren:
Android Asset Studio – Ein webbasierter, in Browser-Generator für alle Arten von Android-Symbolen, mit Links zu anderen nützlichen Communitytools. Dieser funktioniert am besten in Google Chrome.
Visual Studio: Sie können dies verwenden, um einfache Symbole für Ihre App direkt in der IDE zu erstellen.
Fiverr: Wählen Sie aus einer Vielzahl von Designern aus, die ab 5 Dollar Symbole für Sie erstellen. Obwohl das Ergebnis nicht immer zuverlässig ist, ist dies eine gute Ressource, falls Sie schnell Symbole benötigen.
Android Asset Studio – Ein webbasierter, in Browser-Generator für alle Arten von Android-Symbolen, mit Links zu anderen nützlichen Communitytools. Dieser funktioniert am besten in Google Chrome.
Pixelmator: Eine vielseitige Mac-App für das Bearbeiten von Bildern, die ungefähr 30 Dollar kostet.
Fiverr: Wählen Sie aus einer Vielzahl von Designern aus, die ab 5 Dollar Symbole für Sie erstellen. Obwohl das Ergebnis nicht immer zuverlässig ist, ist dies eine gute Ressource, falls Sie schnell Symbole benötigen.
Weitere Informationen zu Symbolgrößen und Anforderungen finden Sie im Leitfaden Android Resources (Android-Ressourcen).
Hinzufügen von Google Play Services-Paketen Google Play Services ist eine Reihe von Add-On-Bibliotheken, die es Android-Entwicklern ermöglichen, von den neuesten Funktionen von Google zu profitieren, z.B. von Google Maps, Google Cloud Messaging und der In-App-Abrechnung. Zuvor wurden Bindungen an alle Google Play Services-Bibliotheken von Xamarin in Form eines einzelnen Pakets bereitgestellt – beginnend mit Visual Studio für Mac, ist ein neues Projektdialogfeld verfügbar, um auszuwählen, welche Google Play Services-Pakete in Ihre App aufgenommen werden sollen. Klicken Sie mit der rechten Maustaste auf den Knoten Pakete in Ihrer Projektstruktur, und klicken Sie auf Google Play-Dienst hinzufügen...: Wenn das Dialogfeld Google Play-Dienste hinzufügen angezeigt wird, wählen Sie die Pakete (NuGets) aus, die Sie Ihrem Projekt hinzufügen möchten: Wenn Sie einen Dienst auswählen und auf Paket hinzufügen klicken, lädt Visual Studio für Mac das ausgewählte Paket sowie alle erforderlichen abhängigen Google Play Services-Pakete herunter und installiert diese. In manchen Fällen wird Ihnen ein Dialogfeld Zustimmung zur Lizenz angezeigt, in dem Sie auf Annehmen klicken müssen, bevor die Pakete installiert werden:
Zusammenfassung
Herzlichen Glückwunsch! Sie sollten nun mit den Komponenten einer Xamarin.Android-Anwendung und mit den Tools, die für die Erstellung benötigt werden, vertraut sein.
Im nächsten Tutorial der Reihe Erste Schritte erweitern Sie Ihre Anwendung, um mehrere Bildschirme zu verarbeiten, während Sie erweiterte Android-Architekturen und -Konzepte kennenlernen.
Inhalt
ABKÜRZUNGSVERZEICHNIS
ABBILDUNGSVERZEICHNIS
1 EINLEITUNG
1.1 PROBLEMSTELLUNG
1.2 AUFBAU DER ARBEIT
2 ENTWICKLUNG VON PROGRAMMIERSPRACHEN
2.1 ERSTE GENERATION
2.2 ZWEITE GENERATION
2.3 DRITTE GENERATION
2.4 VIERTE GENERATION
2.5 FÜNFTE GENERATION
2.6 VISUELLE PROGRAMMIERSPRACHEN
2.6.1 Diagrammbasierte visuelle Programmiersprachen
2.6.2 Icon basierte visuelle Programmiersprachen
2.6.3 Formbasierte visuelle Programmiersprachen
2.6.4 Nachteile
3 APP INVENTOR
3.1 ENTSTEHUNG DES „APP INVENTORS“
3.2 HINTER DEN KULISSEN DES „APP INVENTORS“
3.3 KONZEPTDIAGRAMM
3.4 VERWENDUNG AN SCHULEN UND UNIVERSITÄTEN
3.5 AGILE SOFTWAREENTWICKLUNG
3.6 SYSTEMVORAUSSETZUNGEN
4 APP INVENTOR ENTWICKLUNGSUMGEBUNG
4.1 APP INVENTOR DESIGNER
4.2 APP INVENTOR BLOCK EDITOR
5 AUSGANGSSITUATION
5.1 PROBLEMBESCHREIBUNG
5.2 ABGRENZUNG
6 UMSETZUNG
6.1 LÖSUNGSANSATZ
6.2 DATENSPEICHERUNG MIT GOOGLE‘S „FUSION TABLES“
6.3 GESTALTEN DER BENUTZEROBERFLÄCHE
6.3.1 Suchen nach einem Artikel
6.3.2 Bearbeiten von Artikeln
6.3.3 Buchen von Artikeln
6.4 VISUELLE PROGRAMMIERUNG IM APP INVENTOR
6.4.1 Abrufen von Informationen aus Google Fusion Tables
6.4.2 Anzeigen von Informationen
6.4.3 Speichern von Informationen in Google ’ s Fusion Tables
6.4.4 Buchung eines Artikels
7 FAZIT
8 LITERATURVERZEICHNIS
ANHANG
DARSTELLUNG DER FUNKTION „EMPTYRESULT“
SPEICHERN EINES ARTIKELS
FUNKTIONSÜBERSICHT BEI ARTIKEL BUCHEN
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abbildung 1: Inhaltliche Struktur der Arbeit (selbst erstellte Grafik)
Abbildung 2: Konzeptdiagramm der App Inventor Anwendung (Quelle: Open Source)
Abbildung 3: Agile Softwareentwicklung (selbst erstellte Grafik)
Abbildung 4: App Inventor Designer (selbst erstellte Grafik)
Abbildung 5: App Inventor Block Editor (selbst erstellte Grafik)
Abbildung 6 Beispielfunktion (selbsterstellte Grafik)
Abbildung 7: Schematische Darstellung des Datenbankmodells (selbst erstellte Grafik)
Abbildung 8: Artikelsuche (selbst erstellte Grafik)
Abbildung 9: Artikel bearbeiten-/-anlegen (selbst erstellte Grafik)
Abbildung 10: Artikel buchen (selbst erstellte Grafik)
Abbildung 11: Suche nach einem Artikel starten (selbst erstelle Grafik)
Abbildung 12: Suchergebnis nach einem Artikel anzeigen lassen (selbst erstellte Grafik)
Abbildung 13: Zuordnen eines Ortes zu einem Artikel (selbsterstellte Grafik)
Abbildung 14 Funktion "emptyresult" (selbst erstellte Grafik)
Abbildung 15 Speichern eines Artikels (selbst erstellte Grafik)
Abbildung 16 Funktionsübersicht bei dem Bildschirm Artikel Buchen (selbst erstellte Grafik)
1 Einleitung
1.1 Problemstellung
In einer Firma wird der Inventarisierungsprozess einmal im Jahr durchgeführt, um die im Warenwirtschaftssystem hinterlegten Informationen mit dem tatsächlichen Bestand abzugleichen. Das Erfassen der Artikel erfolgt manuell auf Listen, die anschließend am Computer in das System übertragen werden. Dieses Verfahren bindet wertvolle betriebliche Ressourcen in Form von Arbeitsstunden und produziert eine nicht zu vernachlässigende Fehlerquote. Die Arbeit widmet sich der Frage, wie man dieses Problem mit neuartigen mobilen Endgeräten und einer Anwendung, die in einer visuellen Programmiersprache entwickelt wird, lösen kann.
1.2 Aufbau der Arbeit
Es wird zunächst auf die Entwicklung der verschiedenen Generationen von Programmiersprachen eingegangen. Dabei wird auch das Konzept der grafischen Programmierung erläutert, sowie Vor- und Nachteile genannt. Anschließend wird die Entwicklung von Google's App Inventor beschrieben sowie eine kurze Darstellung seiner Funktionsweise gegeben. Des Weiteren wird die wachsende Bedeutung von grafischen Programmierumgebungen anhand des „App Inventors“ für Schulen und Universitäten aufgezeigt. Das folgende Kapitel behandelt die Entwicklungsumgebung, bestehend aus dem Designer und Block Editor. In dem Praxisteil wird auf ein aktuelles Problem eingegangen, das mit den Möglichkeiten des App Inventors gelöst wird. Dabei werden die Umsetzung der Anwendung dargelegt und visuelle Programmierblöcke erläutert. (Siehe Abbildung 1)
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Inhaltliche Struktur der Arbeit (selbst erstellte Grafik)
2 Entwicklung von Programmiersprachen
Die Entwicklung der Programmiersprachen wird in verschiedene Generationen eingeteilt.
2.1 Erste Generation
Zu der ersten Generation der Programmierung wird die direkte binäre Verarbeitung von Befehlen und Informationen gezählt. Es existieren nur zwei Zustände: „An“ und „Aus“ die entsprechend mit „0“ und „1“ dargestellt werden. Dieser Binärcode gilt als unmittelbare Maschinensprache (Sanda, 2001).
2.2 Zweite Generation
Da die Programmiersprache der ersten Generation aufgrund ihrer Abstraktheit für den Menschen schwer zu lesen und zu verstehen war, wurde an einer Lösung gearbeitet, die für den Benutzer besser lesbare Zeichenketten in Maschinencode umsetzt. Diese erste Abstrahierung zur Maschinensprache wurde mit der Assemblersprache umgesetzt. Diese Sprache enthält erste Zeichenketten, die für den Menschen lesbar waren (Sanda, 2001).
2.3 Dritte Generation
In der nächsten Generation fand eine weitere Abstrahierung statt. In diesen höher entwickelten Programmiersprachen wie FORTRAN, COBOL BASIC und C wurden Textbausteine der englischen Sprache eingebaut, so dass Entwickler die Programmiersprachen leichter erlernen und verwenden konnten (Sanda, 2001).
2.4 Vierte Generation
Die vierte Generation vereint eine höhere maschinensprachliche Abstraktion und die häufigere Verwendung englischsprachiger Begriffe. Auf dieser Ebene wird von der Sprache beschrieben, was die Anweisung erfüllen und nicht wie sie vom Computer umgesetzt werden soll. Zu einer Sprache der vierten Generation (4GPL) zählt zum Beispiel die Structured Query Language (SQL). Mit dieser können Datensätze aus einer Datenbank abgefragt werden, jedoch bildet SQL nicht ab, auf welche Art und Weise die Umsetzung erfolgen soll (Sanda, 2001).
2.5 Fünfte Generation
Die neueste Generation befindet sich noch in einem experimentellen Stadium. Sie ist der englischen Sprache näher, als einer abstrakt textuell bestimmten Programmiersprache. Sie ermöglicht es, in der Interaktion zwischen Mensch und Maschine die gleiche Sprache zu verwenden, die auch bei der zwischenmenschlichen Kommunikation genutzt wird (Sanda, 2001).
2.6 Visuelle Programmiersprachen
Das Erlernen einer Programmiersprache ist eine langwierige und komplexe Aufgabe, die mit einem hohen Zeitaufwand verbunden ist. Visuelle Programmiersprachen stellen sich dieser Herausforderung und dienen als revolutionärer Ansatz, um Computerfunktionalität an Nicht- Programmierer zu vermitteln. Dieser Ansatz basiert hauptsächlich darauf, dass Bilder mehrere Bedeutungen in einer konzentrierten Form vermitteln. Dazu zählt auch, dass Grafiken besser genutzt werden können, um Verständnis zu vermitteln und es leichter ist, sich an Darstellungen zu erinnern. Durch das Verwenden von Bildern wird das Programmieren außerdem interessanter und Bilder können unabhängig von der Sprache des Benutzers verstanden werden (Shu, 1999). Beim Verwenden einer Grafischen Programmiersprache können Lexikalische, Syntaktische und Semantische Fehler nur schwer begangen werden (Leimbach & Trella, 2011). Wie von Shu schon Ende der 1990er Jahre festgestellt wurde, gibt es verschiedene Kategorisierungen visueller Programmierung. Nach seiner Festlegung bieten visuelle Programmiersprachen dem Benutzer die Programmierung mit grafischen Ausdrücken. Bei der Gestaltung wird keine Definition der Variablen als Text, Zahl, Datum oder Ähnliches getroffen. Des Weiteren sind die visuellen Programmiersprachen in drei Bereiche aufgeteilt. Es gibt diagrammbasierte, iconbasierte und formbasierte Umsetzungen (Shu, 1999).
2.6.1 Diagrammbasierte visuelle Programmiersprachen
Der Quellcode eines textbasierten Programmiersprache, wird meist in einem Diagramm basierend auf dem Modell von Nassi und Shneiderman Dokumentiert. Ein Ansatz von diagrammbasierten Programmiersprachen ist es, dieses Modell in ein ausführbares Programm umzusetzen. Dies würde zudem unterbinden, das Dokumentation und programmverhalten auseinanderwachsen.
2.6.2 Icon basierte visuelle Programmiersprachen
Icon basierte Systeme verwenden Piktogramme um Objekte und Aktionen darzustellen. Dies ist analog zu den alltäglichen Icons in Benutzerprogrammen zu sehen. (Shu, 1999)
2.6.3 Formbasierte visuelle Programmiersprachen
Formular basierte Programmiersprachen finden meistens in Datenbanken und Tabellen Verwendung. Die Eingabemasken können direkt zur Datenmanipulation verwendet werden und ermöglichen es somit, einfache Datenbankmodelle zu entwerfen (Shu, 1999).
2.6.4 Nachteile
Zwar sind visuelle Programmiersprachen schneller zu erfassen, jedoch steigt die Übersichtlichkeit mit der Komplexität der Programmierung (siehe Abbildung 16 im Anhang II) (Schaefer, 2011). Des Weiteren gab es über die Jahre eine vielzahl an von Ansätzen, von denen sich keiner im Allgemeinen durchsetzen konnte. Visuelle Programmiersprachen bleiben meist Insellösungen für einen spezifischen Anwendungsbereich (Schaefer, 2011).
3 App Inventor
3.1 Entstehung des „App Inventors“
Die Anwendung „App Inventor“ ist von Google-Mitarbeitern entwickelt worden. Es galt zunächst als experimentelles Lehr- und Lernwerkzeug und wurde im Juli 2009 an ausgewählten amerikanischen Hochschulen vorgestellt (Kloss, 2011). Ziel dabei war es, Studierenden den Einstieg in die allgemeine Programmierung zu erleichtern. Im Juli 2010 wurde das Projekt der Öffentlichkeit vorgestellt, jedoch wurde der Zugang als „Closed-Beta“ eingeschränkt (Kloss, 2011). Am 15. Dezember 2010 wurde die Zugangsbeschränkung aufgehoben und war damit für alle Benutzer verfügbar. „App Inventor“ wurde von „Google Labs“ betrieben. Bei „Google Labs“ handelte es sich um eine Sammlung von Diensten, die von Google betrieben und nach erfolgreichen Tests in die Produktlinie übernommen wurden. Die „Google Labs“ wurden am 17. Oktober 2011 geschlossen. Google beendete den Support von „App Inventor“ und stellte den Service zum 31.12.2011 ein. Um das Weiterbestehen der Anwendung zu sichern, wurde in Kooperation mit dem „Massachusetts Institute of Technology“ (MIT) ein „Center for Mobile Learning“ ins Leben gerufen. Dieses wird den Service weiter ausbauen und der Öffentlichkeit wieder zur Verfügung stellen.1 Des Weiteren wurde am 20. Januar 2012 der Quellcode des App Inventor als „Open Source“ der Öffentlichkeit zur Verfügung gestellt.2
3.2 Hinter den Kulissen des „App Inventors“
App Inventor ist das Ergebnis von Weiterentwicklungen im Bereich der grafischen Programmiersprachen. Weitere Beispiele dafür sind Scratch und StarLogoTNG, mit denen es möglich ist, Anwendungen anstelle von Textcode mit Hilfe von grafischen Bausteinen zu erstellen (Magnuson, 2010). Scratch ist eine weitere, blockbasierte visuelle Programmiersprache, die einfache Befehle unterstützt und Kinder motivieren soll, erste Anwendungen umzusetzen Eine Besonderheit des App Inventors liegt darin, dass es als Zielplattform auf mobile Endgeräte abgestimmt ist. Der Block Editor, der in der Anwendung zur Modellierung der Programmlogik verwendet wird, basiert auf einer Modifikation der OpenBLocks Bibliothek (Roque, 2007). Das OpenBlock Framework ist eine allgemeingültige grafische Block-Sprache, die nach eigenen Bedürfnissen angepasst werden kann.3 Beim Kompilieren wird das Programm zunächst in die Sprache YAIL übersetzt, die S-Expression verwendet und ein Scheme Programm definiert. Mit Hilfe des Kawa Frameworks wird anschließend Java VM byte code generiert. Somit wird, entgegen möglichen Erwartungen, kein Java Quellcode erzeugt (Magnuson, 2010).
3.3 Konzeptdiagramm
Der App Inventor ist ein Web Service der auf Google’s App Engine Plattform läuft. Von dort aus kann der Designer im Browser aufgerufen werden. Der Blocks Editor wird nach dem Laden der Block Datei lokal auf dem Computer mit Java ausgeführt. Vom Block Editor kann die Anwendung in einem Emulator gestartet oder auf ein angeschlossenes mobiels Endgerät gespielt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Konzeptdiagramm der App Inventor Anwendung (Quelle: Open Source)4
3.4 Verwendung an Schulen und Universitäten
Da die Vorgaben des Programms recht übersichtlich sind und der Benutzer zu einem großen Teil bei der Entwicklung geführt wird, eignet es sich im Besonderen für den Einsatz an Schulen und Universitäten. Hauptsächlich geht es darum, Schülern sowie Studierenden erste Einblicke in die Programmierlogik zu ermöglichen und das Thema auf eine ansprechende Weise nahezubringen. Meistens richten sich die Kurse an Anfänger, die noch keine Programmiererfahrung besitzen. Wie von Reichelt und Boom dargestellt wird der App Inventor in der neunten Klasse eines Gymnasiums verwendet, um neben mobilen Anwendungen auch Lego Mindstorm Roboter zu programmieren (Leimbach & Trella, 2011). Durch die steigende Popularität von mobilen Endgeräten ist das Interesse von Schülern an der Programmierung für Anwendungen stark gestiegen. (Reichelt & Van de Boom, 2011). Mit Hilfe des App Inventors kann das computerbasierte Denken an Schüler gut weitergegeben werden (Morelli, Lanerolle, Lake, Limardo, Tamotsu, & Uche, 2011). Neben der Programmierung werden auch agile Programmiertechniken vermittelt. Eine weitere Stärke ist, dass mehr Fokus auf das Lösen von Problemen in Programmieraufgaben gelegt werden kann, anstelle der Beachtung der Sprachsyntax, wie es bei klassischen Programmiersprachen der Fall ist (Morelli, Lanerolle, Lake, Limardo, Tamotsu, & Uche, 2011). „Scratch“ ist eine weitere visuelle Programmiersprache, die an Programmieranfänger gerichtet ist. Mit dieser können recht einfache Programme entwickelt werden, die in einer künstlichen Umgebung angesiedelt sind (Introduction to Computer Science with Scratch and App Inventor, 2011).
3.5 Agile Softwareentwicklung
Durch die Verwendung des AppInventor kann agile Softwareentwicklung auf eine veranschaulichte Art und Weise vermittelt werden (siehe Abbildung 3). So wird zunächst das Problem erörtert, welches mit der Anwendung gelöst werden soll. Anschließend wird ein Design als Ablaufplan entworfen. Nun beginnt der Entwicklungsprozess. Zunächst wird das Interface mit dem App Designer entworfen. Daraufhin wird mit dem Block Editor das Coding vorgenommen. Im Folgenden wird die so entstandene Umsetzung getestet und debugged. Wenn nötig werden weitere Veränderungen und Verbesserungen durchgeführt und somit schließt sich der
Kreis. Werden beim Testen und Debuggen keine Fehler mehr festgestellt, so wird die Software freigegeben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Agile Softwareentwicklung (selbst erstellte Grafik)
3.6 Systemvoraussetzungen
Da der „App Inventor“ eine webbasierte Anwendung ist, ist es möglich, diese auf so gut wie jedem Computer zu verwenden. „App Inventor“ ist betriebssystem- und browserunabhängig. Um Zugriff auf die Anwendung zu erhalten, wird ein Google-Konto benötigt. Für das Ausführen wird zudem mindestens Java 6 benötigt.
Mindestvoraussetzungen:
Computer Plattformen:
- Windows : Windows XP, Windows Vista, Windows 7
- Apple : Mac OS X 10.5, 10.6, 10.7
- GNU/Linux : Ubuntu 8+, Debian 5+
Browser:
- Mozilla Firefox 3.6 oder höher
- Apple Safari 5.0 und höher
- Google Chrome 4.0 und höher
- Microsoft Internet Explorer 6 und höher
[...]
1 Siehe abgerufen am 20.Januar 2012
2 Siehe abgerufen am 20.Januar 2012
3 Siehe abgerufen am 14. Januar 2012
4 Siehe source Code abgerufen am 20.Januar 2012
In diesem Einsteigerkurs, der keine Vorkenntnisse erfordert, lernen Sie, wie Sie schnell und einfach Ihre erste Android-App entwickeln. Sie starten mit den Grundlagen des Betriebssystems Android, installieren und konfigurieren die Entwicklungsumgebung Android Studio und programmieren Schritt für Schritt eine voll funktionsfähige App mit der Programmiersprache Kotlin. Die praktische Anwendung wird unter anderem in der Lage sein, Daten von anderen Apps zu empfangen und diese zu interpretieren.
Mehr anzeigen
Weniger anzeigen
Leave a Comment