208 lines
32 KiB
TeX
208 lines
32 KiB
TeX
\chapter{Auswahl mobiler Informatiksysteme für den Unterricht}\label{chpAuswahl}
|
|
|
|
\section{Geräteauswahl}\label{secGerAusw}
|
|
|
|
Im Gegensatz zur Situation vor einigen Jahren, als die Arbeiten von \cite{Carrie2006} und \cite{Heming2009} entstanden, ist es heute relevanter, sich für eine Plattform, als für ein bestimmtes Gerät\footnote{Da sich das Angebot an Geräten sehr schnell ändert und einige Modelle nur für wenige Monate oder sogar nur in einzelnen Aktionen erhältlich sind, ist es nicht sinnvoll, konkrete Modelle anzugeben. Für diese Arbeit wurden die folgenden Modelle getestet, die allesamt die vollständigen Möglichkeiten der jeweiligen Plattform unterstützen. \textit{Android}: Medion Lifetab S9512, Samsung Galaxy Ace, Samsung Galaxy Fit, Samsung Galaxy S, Samsung Galaxy Tab (P1000), Sony Xperia U, Touchlet X4 (mit Einschränkungen bei der \gls{SL4A} und Kivy, außerdem eher träge); \textit{BlackBerry OS}: BlackBerry Curve 8520; \textit{iOS}: iPad 1, iPad 2, iPhone 3GS, iPhone 4, iPhone 4S, iPod Touch 3G, iPod Touch 4G; \textit{Windows Phone}: Nokia Lumia 610, Nokia Lumia 800. Die Samsung-Geräte geizten ähnlich mit Standardschnittstellen wie die von Apple und \gls{RIM} (BlackBerry). Dagegen haben sich die folgenden Geräte wegen deutlicher Verarbeitungsmängel oder starker Einschränkungen der durch die Plattform vorgegebenen Möglichkeiten als ungeeignet erwiesen: \textit{Android}: Motorola Backflip, ZTPad ZT-280; \textit{iOS}: iPhone 3.} zu entscheiden, da diese die Fähigkeiten und Einschränkungen der Geräte wesentlich mitbestimmen. Die Frage der richtigen Plattform stellte sich damals natürlich in dieser Form nicht, da nur eine Plattform, nämlich Symbian S60 zur Verfügung stand. Die konkrete technische Ausstattung der Geräte ist nur noch als sekundär zu betrachten, da es für alle im Moment relevanten Plattformen diverse Modelle gibt. Dies gilt zumindest, wenn man sich auf \textit{Smartphones}, \textit{Hybride} und \textit{Tablets} beschränkt, was derzeit aufgrund der Leistungsfähigkeit und Ausstattung der Geräte sinnvoll erscheint. Außerdem ist mit diesen am ehesten die Entwicklung auf den Geräten möglich. Die Frage nach dem Gerätetyp tritt auch insofern in den Hintergrund, als die meisten Plattformen jeweils für unterschiedliche Gerätetypen zur Verfügung stehen. Es besteht also inzwischen die komfortable Situation, nicht mehr exklusiv zwischen verschiedenen Gerätetypen entscheiden zu müssen. So sind gemischte Einsatzszenarien denkbar.
|
|
|
|
Die technischen Details der einzelnen Gerätetypen treten also, anders als noch in \cite{Spittank2011} vermutet, in den Hintergrund. Trotzdem muss eine gewisse technische Mindestausstattung als notwendige Grundlage betrachtet werden. So müssen sie etwa, da in der Schule -- zumindest bei schuleigenen Geräten -- standardmäßig kein Zugang zu Mobilfunknetzen genutzt werden kann, in der Lage sein, sich mit einem \gls{WLAN} zu verbinden. Zur schnellen und bequemen Vernetzung (etwa zum Austausch von Nachrichten) sollten sie über \textit{Bluetooth} verfügen. Auch weitere Standard-Schnittstellen sind hilfreich, jedoch nicht unbedingt erforderlich. Zu nennen sind hier etwa \textit{USB-Host} oder ein \textit{Videoausgang} zum Anschluss an einen Beamer zur Präsentation von Ergebnissen.
|
|
|
|
Zumindest eine \textit{Kamera} sollte aufgrund der vielfältigen Anwendungsmöglichkeiten, wie sie in \cite{Heming2009} beschrieben werden, vorhanden sein. Weitere \textit{Sensoren} und \textit{Ortungsmodule} können die Einsatzmöglichkeiten bereichern, sind jedoch nicht zwingend erforderlich. Eine lange \textit{Akkulaufzeit} erscheint hier als wichtigeres Kriterium. Außerdem sollte der \textit{Akku austauschbar} sein.
|
|
|
|
Ein \textit{kapazitiver Touchscreen} sollte heute auf jeden Fall einem resistiven Modell vorgezogen werden, da die Bedienung damit deutlich angenehmer und flüssiger möglich ist. Die verwendete Display-Technologie spielt hingegen keine wesentliche Rolle für den Unterricht. Lediglich könnte man hier festhalten, dass eine \textit{höhere Auflösung} besser ist, da sich Texte dann leichter lesen lassen. Der Einblickwinkel des Displays spielt hingegen keine besonders große Rolle, da die Arbeit an den Geräten aufgrund ihrer Größe tendenziell allein erfolgt.
|
|
|
|
Generell sollte für schulische Geräte das Kriterium der Langlebigkeit\vglr{secKritLang} berücksichtigt werden. Zumindest sollten die Geräte einigermaßen gut verarbeitet sein und längere Benutzung unbeschadet überstehen. Vorteilhaft wäre es, wenn die Geräte kleinere Stürze überleben würden, daher kann die Anschaffung \textit{zusätzlicher Schutzhüllen} sinnvoll sein. Dies setzt wiederum eine gewisse Verbreitung\vglr{secKritVer} voraus, damit diese überhaupt als Zubehör angeboten werden. Auch die Verfügbarkeit von Ersatzteilen (vor allem Akkus) und Reparaturmöglichkeiten sollte berücksichtigt werden.
|
|
|
|
Aktuell würde der Autor den Einsatz von Smartphones und Hybriden empfehlen, da diese derzeit noch einen stärkeren Alltagsbezug aufweisen als Tablets und zumindest die Smartphones sehr günstig zu bekommen sind. Durch die zunehmende Verbreitung von Tablets kann sich dies jedoch schnell ändern. Beim Einsatz von Smartphones ist eine gewisse Vorsicht geboten, da nach Erfahrungen des Autors nicht alle Smartphones vollständig ohne SIM-Karte betrieben werden können, obwohl die Betriebssyteme dies grundsätzlich zulassen. Auf einigen Plattformen (bzw. von einigen Apps) wird das \gls{SIM} als eindeutiges Identifikationsmerkmal für die Lizensierung kommerzieller Applikationen verwendet, sodass diese nicht ohne eigelegte SIM-Karte funktionieren.
|
|
|
|
Insgesamt sollten bei der Anschaffung schuleigener Geräte diese auf jeden Fall zuvor auf die Kriterien hin überprüft werden. Durch Anpassungen der Gerätehersteller an den Betriebssystemen könnte man sonst unangenehme Überraschungen erleben. Teilweise schränken diese nämlich Funktionen und Eigenschaften ein, die die Plattformen grundsätzlich besitzen.
|
|
|
|
Das optionale Kriterium \enquote{Umweltfreundlichkeit und Sozialverträglichkeit} sollte ebenfalls berücksichtigt werden. Dass dies im Moment nur sehr eingeschränkt möglich ist, wurde bereits bei der Beschreibung des Kriteriums erwähnt. Trotzdem kann dieses Kriterium zumindest teilweise befolgt werden, wenn das Kriterium der Langlebigkeit erfüllt ist.
|
|
|
|
\section{Plattformauswahl}
|
|
|
|
Wünschenswert wäre es natürlich -- insbesondere unter dem Aspekt der Einbindung von den \SuSn gehörenden Geräten in den Unterricht --, wenn mit denselben Unterrichtsmaterialien alle relevanten Plattformen abgedeckt werden könnten, sodass diese gleichberechtigt im Unterricht eingesetzt werden könnten. Hierauf wird im \referenz{chpGestaltung} zur Gestaltung der mobilen Informatiksysteme für den Unterricht noch genauer eingegangen.
|
|
|
|
\subsection{Vorauswahl -- Systemrelevanz}
|
|
|
|
Trotzdem muss zunächst betrachtet werden, inwieweit die verschiedenen verfügbaren Plattformen sich überhaupt für den Einsatz im Unterricht eignen. Aus rein praktischen Gründen stellt sich zudem die Frage, welche Plattformen vorrangig betrachtet werden sollten. Offensichtlich sind also für eine Vorauswahl zunächst die Kriterien der Verbreitung und des Alltagsbezugs\vglr{secKritVer} von Bedeutung.
|
|
|
|
Die \referenz{figOSMarkt} stellt hier die aktuelle Verbreitung der verschiedenen Plattformen sowie die Veränderung zum Vorjahr dar. Die Ergebnisse der Erhebung \citep{Bitkom2012a} passen zu denen der früher, aber ebenfalls von comScore durchgeführten Studie \citep{comscore2012}. Andere Studien kommen hier zu tendenziell ähnlichen Ergebnissen. Einzig das \gls{OMP} \citep{OMP} weicht hier deutlich ab. Dies mag aber daran liegen, dass die Daten auf einer Umfrage basieren, die die Antwort \enquote{weiß nicht} zuließ, die mit einem Anteil von 15\,\% der Befragten viel Zuspruch erhielt.
|
|
|
|
Zur Verbreitung der Plattformen bei Jugendlichen gibt es leider keine stichhaltig belegbaren Ergebnisse. Android und iOS sind aber auch hier beliebt. Nach den (natürlich keineswegs repräsentativen) Erfahrungen des Autors liegt Android derzeit mit leichtem Vorsprung vor iOS, während die anderen Plattformen praktisch keine Rolle spielen.
|
|
|
|
\DTLloaddb[]{csSPOS}{chartdata/comscore/smartphone_os.csv}
|
|
|
|
\begin{figure}[htbp]
|
|
\begin{scriptsize}
|
|
|
|
\centering
|
|
|
|
\begin{normalsize}
|
|
\textbf{Marktanteile von Smartphone-Betriebssystemen in Deutschland}
|
|
\end{normalsize}
|
|
\vspace{0.5cm}
|
|
|
|
\DTLsetpiesegmentcolor{1}{green}
|
|
\DTLsetpiesegmentcolor{2}{grayTwo}
|
|
\DTLsetpiesegmentcolor{3}{yellow}
|
|
\DTLsetpiesegmentcolor{4}{blue}
|
|
\DTLsetpiesegmentcolor{5}{black}
|
|
\DTLsetpiesegmentcolor{6}{red}
|
|
|
|
\DTLpiechart{
|
|
variable=\datpz,
|
|
radius=2.5cm,
|
|
cutaway={1-2,3},
|
|
innerratio=0.8,
|
|
innerlabel={},%\DTLpiepercent\,\%},
|
|
outerlabel={\datn\ -- \textbf{\datpz\,\%}\ (\datpe\,\%)}%
|
|
}{csSPOS}{\datn=Name,\datpz=2012,\datpe=2011}
|
|
|
|
|
|
\setlength{\DTLbarwidth}{10pt}
|
|
\setcounter{DTLbarroundvar}{0}
|
|
\setlength{\DTLticklabeloffset}{10pt}
|
|
\setlength{\DTLbarlabeloffset}{20pt}
|
|
|
|
|
|
\DTLsetbarcolor{1}{green}
|
|
\DTLsetbarcolor{2}{grayTwo}
|
|
\DTLsetbarcolor{3}{yellow}
|
|
\DTLsetbarcolor{4}{blue}
|
|
\DTLsetbarcolor{5}{black}
|
|
\DTLsetbarcolor{6}{red}
|
|
|
|
\vspace{1cm}
|
|
\begin{normalsize}
|
|
\textbf{Veränderung der Marktanteile von 2011 bis 2012}
|
|
\end{normalsize}
|
|
\vspace{0.5cm}
|
|
|
|
\DTLbarchart{variable=\datd,upperbarlabel={\datn\ -- \textbf{\datd}},
|
|
ylabel={Veränderung in Prozentpunkten 2012 zu 2011},verticalbars=false,axes=y,yticgap=10,
|
|
maxdepth=-20,max=30}{csSPOS}{\datd=Differenz,\datn=Name}
|
|
|
|
|
|
\caption[Smartphone-Betriebssysteme (Deutschland, 2012)]{Betriebssysteme von aktiven Smartphones in Deutschland für das Jahr 2012, Werte des Jahres 2011 in Klammern, jeweils 1. Quartal, nach einer Presseveröffentlichung des \gls{BITKOM}, Quelle: \cite{Bitkom2012a}}\label{figOSMarkt}
|
|
\end{scriptsize}
|
|
\end{figure}
|
|
|
|
Hieraus und aus der allgemeinen Verbreitung\vglr{figOSMarkt} wird deutlich, dass die beiden relevantesten Plattformen iOS und Android sind. Bei einem Blick auf die Veränderungen erkennt man zudem, dass Windows deutliche Umsatzeinbußen verzeichnen musste, was mit der Plattformumstellung auf Windows Phone 8 zu tun haben kann. Die Abkündigung von Symbian durch Nokia hatte hingegen einen dramatischen Einbruch der Marktanteile dieser Plattform zur Folge. Symbian und HPs Tabletbetriebssytem WebOS sind zwar inzwischen als Open-Source-Software verfügbar, es ist jedoch bisher nicht abzusehen, ob sich ein Hersteller findet, der entsprechende Hardware anbieten wird.
|
|
|
|
Windows scheint derzeit bei \SuSn nicht sonderlich verbreitet zu sein, allerdings, muss es -- vor allem im Hinblick auf den Plattformwechsel zu Windows (Phone) 8 -- trotzdem weiter betrachtet werden. BlackBerry OS hingegen ist weder vom Marktanteil noch von der Ausrichtung der Plattform für die Schule relevant. Es ist voll und ganz auf den geschäftlichen Einsatz ausgerichtet und verfehlt sowohl im Hinblick auf die Individualisierbarkeit, als auch bei den Unterhaltungsmöglichkeiten (vor allem bei Spielen) die Anforderungen der Jugendlichen\vglr{secKritJu} und damit das Kriterium des Alltagsbezugs\vglr{secKritVer}. Da außerdem bei den Kommunikationsfunktionen spezielle BlackBerry-Produkte und besondere Tarife der Mobilfunkanbieter notwendig sind, wird das Kostenkriterium\vglr{secKritKost} ebenfalls verfehlt. Es gibt zwar Anzeichen dafür, dass der Hersteller hier sein Konzept anpassen wird, derzeit rechtfertigt dies aber keine besondere Betrachtung.
|
|
|
|
Kurz zusammengefasst kann man also festhalten, dass derzeit lediglich die Plattformen iOS, Android und Windows wirklich relevant sind. iOS und Android weisen den höchsten Alltagsbezug und die höchste Verbreitung auf. Trotzdem werden im \referenz{secPlatOth} noch einige weitere, derzeit nicht relevante Plattformen betrachtet, die möglicherweise in Zukunft gute Alternativen sein könnten.
|
|
|
|
\input{imgs/mobos/mobos_preamble.tex}
|
|
|
|
\subsection{iOS}
|
|
\begin{figure}[htbp]
|
|
\centering
|
|
\begin{scriptsize}
|
|
\textsf{\input{imgs/mobos/mobos_app.tikz}}
|
|
\end{scriptsize}
|
|
\caption{Abstammung von mobilen Betriebssystemen 1: iOS}\label{figPlatApp}
|
|
\end{figure}
|
|
|
|
\subsubsection{Sinnvolle Einbindung und Programmierbarkeit}
|
|
Apples iOS ist sowohl für Tablets (iPad), Smartphones (iPhone) und Multimediaabspielgeräte (iPod Touch und AppleTV) verfügbar\vglr{figPlatApp}. Dabei sind die bei \SuSn verbreiteten iPhones und iPods von der Leistung und Ausstattung gleichermaßen für den Unterrichtseinsatz geeignet. Die iOS-Geräte sind allerdings reine \glspl{KonsumG}\vglr{secKonsum}. Die vorhandenen Einschränkungen, etwa der fehlende Zugriff auf das Dateisystem, die eingeschränkten Möglichkeiten zum Austausch von Dateien, die exklusive Bindung an Apples Distributionskanäle für digitale Inhalte und rigide rechtliche Beschränkungen zusammen mit der festen Bindung an Apples Cloud-Infrastruktur erschweren die kritische Benutzung der Plattform. Zudem gibt es für die Apps, zumindest bis zum noch nicht veröffentlichten iOS 6, kein Rechtesystem für den Zugriff auf API-Funktionen mit Ausnahme des Zugriffs auf die Ortungsfunktionen. Es ist also zu keinem Zeitpunkt ersichtlich, was die Apps tatsächlich tun. Ein Spiel könnte also nebenbei etwa Kontaktdaten auslesen und ins Internet senden. Damit ist die Einnahme der analytischen Perspektive zumindest erschwert.
|
|
|
|
Eine Programmierung der Geräte ohne Zuhilfenahme von stationären Informatiksystemen ist nicht vorgesehen. Zudem erfordert die Entwicklung für die Geräte einen kostenpflichtigen Entwicklerzugang, ohne den keine Apps auf echten Geräten installiert werden können, und Informatiksysteme mit Mac OS X, also Apple-Rechner. Es ist also von mittleren bis hohen zusätzlichen \textit{Kosten} auszugehen. Für die Programmierung steht außerdem im Wesentlichen nur die appleeigene Programmiersprache ObjectiveC zur Verfügung, die im Hinblick auf die Kriterien eher ungeeignet erscheint. Vor allem die Orthogonalität (Verwendung von Klammern u.~a.~m.) und die einfache Erlernbarkeit sind nicht gegeben.
|
|
|
|
Die Ausführung von Code, der nicht aus dem Appstore stammt, ist nicht zulässig, damit sind keine Interpreter und Compiler für iOS möglich\footnote{Tatsächlich gibt es zwar einige entsprechende Apps, diese behelfen sich jedoch durch Tricks. Mit der App \enquote{Codea} etwa kann zwar programmiert und der Code ausgeführt werden, ein Export des Codes vom eigenen Gerät herunter (auch über die Zwischenablage) ist jedoch ebenso unmöglich wie der Import von fremdem Code. Mit \enquote{Python for iOS} ist dies zwar möglich, dafür stehen nur eine Textkonsole und Standard-Python-Pakete zur Verfügung. Zugriff auf die \glspl{API} von iOS erhält man damit auch nicht.}. Einzig die Entwicklung von Webapps wäre möglich, jedoch aufgrund des fehlenden Dateisystemzugriffs nur mittels eines externen Servers. Durch die fehlende Programmierbarkeit erübrigt sich die Frage nach der \textit{Verfügbarkeit von Werkzeugen und Dokumentation} natürlich direkt. Außerdem wird so durch den fehlenden Zugang zur Perspektive der Veränderung der Wirklichkeit das Sinn-Kriterium auf Seiten der \SuS konterkariert, da sich durch den Unterrichtseinsatz keine neuen Möglichkeiten im Alltag ergeben.
|
|
|
|
\subsubsection{Andere Kriterien}
|
|
|
|
Zwar hat sich die Plattform an dieser Stelle bereits disqualifiziert, aber aufgrund ihrer hohen Verbreitung sollen die übrigen Kriterien der Vollständigkeit halber zumindest noch knapp angesprochen werden.
|
|
|
|
Die Geräte von Apple sind zwar vergleichsweise hochpreisig, dafür sind sie aber gut verarbeitet und weisen generell eine recht hohe Lebensdauer auf. Allerdings wird dieser positive Eindruck durch die fest verbauten Akkus konterkariert, die nicht nur die Lebensdauer verringern, sondern auch das optionale Kriterium \textit{Umweltfreundlichkeit und Sozialverträglichkeit} negativ beeinflussen. Die andauernden Berichte in den Medien über schlechte Arbeitsbedingungen in den Produktionsländern tragen nicht zu einer besseren Bewertung für dieses Kriterium bei.
|
|
|
|
Generell bieten die Geräte eine gute Ausstattung, allerdings verfügen sie nicht über Standardschnittstellen (HDMI oder analoge Videoausgabe sind über einen recht teuren Adapter möglich) und übliche Erweiterungsmöglichkeiten. Allerdings gibt es sehr viel proprietäres Zubehör. Die eingebaute Bluetoothunterstützung kann nur für den Anschluss von Audiogeräten und proprietäre Profile genutzt werden. Der übliche Datenaustausch ist nicht möglich.
|
|
|
|
Viele Open-Source-Lizenzen, nämlich alle, die öffentliche Zugänglichmachung des Codes erfordern (\zb die \gls{GPL}), sind nicht mit den Bedingungen von Apples Appstore kompatibel. Dies führt dazu, dass nur wenig Freie Software im Appstore zu finden ist.
|
|
|
|
Der Vollständigkeit halber sei erwähnt, dass es mittels \gls{Jailbreaking} möglich wäre, alle relevanten Einschränkungen zu umgehen. Im dann zugänglichen, alternativen Appstore Cydia finden sich Python und andere Freie Software. So wäre es möglich, eine didaktisch fundierte Klassenbibliothek zu entwickeln und die Geräte vollumfänglich im Informatikunterricht zu nutzen. Doch das Jailbreaking ist leider für die Schulen derzeit keine Option\vglr{secKonsum}. Sollten die Einschränkungen irgendwann aufgehoben werden, wovon nicht auszugehen ist, oder das Jailbreaking rechtlich unproblematisch werden, wäre iOS eine nahezu ideale Plattform für den Informatikunterricht.
|
|
|
|
\subsection{Android}
|
|
\begin{figure}[htbp]
|
|
\centering
|
|
\begin{scriptsize}
|
|
\textsf{\input{imgs/mobos/mobos_lin.tikz}}
|
|
\end{scriptsize}
|
|
\caption{Abstammung von mobilen Betriebssystemen 2: Linux}\label{figPlatLin}
|
|
\end{figure}
|
|
|
|
\subsubsection{Sinnvolle Einbindung}
|
|
Android ist das derzeit am weitesten verbreitete mobile Betriebssystem\vglr{figOSMarkt}. Allerdings wird Android inzwischen auch auf anderen Informatiksystemen genutzt. Dazu zählen Multimediaabspielgeräte, Setopboxen und Fernseher (GoogleTV) aber auch Autoradios, Navigationssysteme und andere Exoten. Sogar eine Spielekonsole auf Android-Basis (Ouya) wurde bereits angekündigt. Da Android sogar auf x86-Systemen läuft, steht einer Verwendung mit stationären Informatiksystemen ebenfalls nichts im Wege. (Korrekt erstellte) Apps laufen auf all diesen Systemen gleichermaßen. Android-Geräte sind häufig bei \SuSn anzutreffen. Aufgrund der auf \textit{ Freier Software} gründenden Basis gibt es keine wesentlichen, künstlichen Einschränkungen. Lediglich die Modifikation des Betriebssystems selbst oder die Installation eines selbst erzeugten Betriebssystems bedürfen in der Regel des Rootings der Geräte. Allerdings fehlen dem normalen Android einige, von Desktop-Linux-Distributionen bekannte Softwarebibliotheken. Dies ist für die Nutzung im Unterricht aber nur in einigen, wenigen Fällen relevant\vglr{chpAndroid}.
|
|
|
|
Die Nutzung der Geräte zu Kommunikations- und Unterhaltungszwecken ist problemlos möglich, das App-Angebot ist riesig und inzwischen fast so groß wie bei iOS. Im offiziellen Appstore sind, anders als bei anderen Plattformen, sehr viele Open-Source-Apps zu finden. Die Installation von Apps aus Fremdquellen ist möglich, somit gibt es auch diverse alternative Appstores. Dabei ist Android das am stärksten individualisierbare System. Selbst ohne Rooting lässt sich nahezu die gesamte grafische Oberfläche inklusive diverser Standardprogramme austauschen.
|
|
|
|
Die kritische Nutzung wird dadurch begünstigt, dass ein grundlegendes Rechtesystem für Apps existiert. Vor Installationen wird detailliert angezeigt, welche Berechtigungen eine App erfordert. Benutzer oder Benutzerinnen können dann entscheiden, ob sie dies akzeptieren. Eine Einschränkung der Berechtigungen einer App ist entweder mittels Rooting oder per Modifikation der Manifest-Datei der jeweiligen App möglich. Dazu ist inzwischen mit AppGuard eine entsprechende App aus dem Umfeld der Universität Saarbrücken verfügbar\vgln{AppGuard}. Die beiden letzteren Möglichkeiten sind allerdings mit dem Verlust der regulären Updatefunktion verbunden. Updates für die veränderten Apps müssen danach manuell installiert und erneut angepasst werden.
|
|
|
|
\subsubsection{Programmierbarkeit}
|
|
Bei Android bestehen derzeit mindestens vier verschiedene Möglichkeiten zur Programmierung mit den Geräten für die Geräte. Außerdem bestehen weitere Möglichkeiten etwa über WebApps, grafische Programmierung oder auf Makros basierenden Automatisierungstools. Natürlich ist die Programmierung für die Geräte mit einem stationären Informatiksystem möglich. Es lassen sich allerdings auch reguläre Apps nur mittels der mobilen Informatiksysteme erzeugen. Die verschiedenen Ansätze werden im \referenz{chpAndroid} noch ausführlicher diskutiert. Die \enquote{Verfügbarkeit von Werkzeugen und Dokumentation}, die bei allen Ansätzen unterschiedlich ist, wird dort ebenfalls erörtert.
|
|
|
|
\subsubsection{Kosten}
|
|
Android-Geräte gibt es in allen Preislagen. Es ist hier letztlich eine Frage der gewünschten Ausstattung, wieviel man für ein konkretes Gerät bezahlen muss. Weitere direkte Folgekosten entstehen bei Android nicht. Durch die Verfügbarkeit von Open-Source-Software kann ein großer Teil des schulischen Bedarfs abgedeckt werden. Eine kostenpflichtige Registrierung als Entwickler gibt es nicht, auch die Veröffentlichung von Apps im Google Play Store ist nicht mit Kosten verbunden.
|
|
|
|
|
|
\subsubsection{Langlebigkeit}
|
|
Es gibt extrem günstige Geräte mit Android, die teilweise sehr schlecht verarbeitet sind. Bei den meisten Geräten ist dies jedoch kein Problem.
|
|
|
|
Wie bei anderen Plattformen sind bei Tablets die Akkus in der Regel fest verbaut, sodass die Lebensdauer eingeschränkt wird. Bei anderen Android-Geräten ist dies jedoch die absolute Ausnahme.
|
|
|
|
Sehr schwer wiegt allerdings das Problem der Fragmentierung von Android. Da die Hersteller in der Regel starke Anpassungen am System vornehmen, sind diese vollumfänglich für Updates zuständig. Die Versorgung mit Updates ist daher sehr stark herstellerabhängig. Lediglich gerootete und die von Google direkt oder in Kooperation mit bestimmten Partnern angebotenen Nexus-Geräte erhalten garantiert schnell, regelmäßig und langfristig neue Updates. In Bezug auf Sicherheitslücken und Malware ist das ein elementarer Schwachpunkt der Plattform.
|
|
|
|
Ein anderes Problem sind günstige Geräte, die für ältere Android-Versionen konstruiert wurden und nun mit dem aktuellen Android 4 ausgestattet wurden. Derartige Geräte findet man für rund 100\euro\ in Baumärkten, Ramschläden und in diversen Onlineshops. Es hat sich gezeigt, dass derzeit keines der günstigen Geräte mit Android 4 wirklich zufriedenstellend funktioniert.
|
|
|
|
Bei der Anschaffung von Android-Geräten ist für den sinnvollen schulischen Einsatz mindestens die Version 2.2 erforderlich. Dies stellt jedoch kein wesentliches Problem dar, da es kaum noch Geräte mit älteren Versionen im Handel gibt.
|
|
|
|
\subsubsection{Gute Ausstattung}
|
|
Im Allgemeinen (Ausnahme: Samsung) verfügen Android-Geräte über diverse Stan\-dard-Schnitt\-stel\-len. Weitgehend uneingeschränktes Bluetooth, Speicherkartenslots, USB-Host- und HDMI-Schnitt\-stel\-len gehören inzwischen zur Standardausstattung der Geräte. Bei Smartphones sind dazu allerdings oft Adapter nötig, die jedoch meist für wenig Geld zu bekommen sind.
|
|
|
|
|
|
\subsection{Windows}
|
|
\begin{figure}[htbp]
|
|
\centering
|
|
\begin{scriptsize}
|
|
\textsf{\input{imgs/mobos/mobos_win.tikz}}
|
|
\end{scriptsize}
|
|
\caption{Abstammung von mobilen Betriebssystemen 3: Windows}\label{figPlatWin}
|
|
\end{figure}
|
|
|
|
Windows ist derzeit bei mobilen Informatiksystemen nicht sehr verbreitet, es hat sogar Marktanteile eingebüßt\vglr{figOSMarkt}. Dies hat sicherlich damit zu tun, dass die aktuelle Plattform Windows Phone 7 kurz vor der Ablösung steht und die aktuellen Geräte keine Updates auf Windows Phone 8 erhalten werden, das nicht mehr auf der CE-Linie von Windows, sondern auf Windows 8 basiert\vglr{figPlatWin}. Es ist jedoch nicht unwahrscheinlich, dass sich die neue Plattform deutlich stärker verbreiten wird. Zumindest ist Microsoft bereit, zur Optimierung seiner Betriebssysteme für mobile Informatiksysteme die Desktop-Version komplett umzugestalten. So wurde dem Desktop-Windows die \enquote{Metro} genannte Bedienoberfläche des mobilen Windows implantiert. Aufgrund fehlender Touchscreens bei stationären Systemen erscheint dies nur im Hinblick auf die Gewöhnung der Benutzerinnen und Benutzer an das Bedienkonzept der mobilen Systeme sinnvoll.
|
|
|
|
Microsoft verfügt bei seiner neuen Betriebssystemgeneration über drei Systeme für mobile Geräte: Windows Phone 8 für Smartphones, Windows 8 für x86-Tablets und Windows RT für ARM-Tablets. Die drei relevanten, verschiedenen Varianten von Windows müssen im Folgenden getrennt betrachtet werden, da sie die verschiedenen Kriterien unterschiedlich gut erfüllen. Es ist noch nicht in allen Punkten klar, was überhaupt möglich sein wird, da noch keine mobilen Informatiksysteme mit diesen Plattformen erhältlich sind.
|
|
|
|
\subsubsection{Sinnvolle Einbindung und Programmierbarkeit}
|
|
|
|
Die Einnahme der kritisch-analytischen Perspektive erscheint durchweg gut möglich, da die vorhandenen Einschränkungen im Wesentlichen dem \gls{DRM} und dem Kopierschutz bestimmter Inhalte dienen, aber keine bedeutenden, grundlegenden Sperren vorhanden sind. Der Einsatz Freier Software ist grundsätzlich möglich, der offizielle Distributionsweg über den Windows Marketplace bleibt vielen Lizenzen jedoch aus demselben Grund wie bei Apple verwehrt. Anders als bei Apple werden diese Lizenzen, allen voran die \gls{GPL}, sogar explizit vom Marketplace ausgeschlossen\vgl{MicrosoftAgreement}{1}.
|
|
|
|
Es gibt genügend Möglichkeiten zur Individualisierung der Geräte etwa über entsprechende Apps und Metro-Kacheln. Die Möglichkeiten für die kommunikative Nutzung der Geräte sind reichhaltig, und es ist ein ausreichendes Angebot an Unterhaltungsmöglichkeiten zu erwarten. Bei Windows Phone 7 war dies schon recht ordentlich. Durch die teilweise gemeinsame Unterstützung von Windows 8, Windows RT und Windows Phone 8 sind hier allerdings noch deutliche Verbesserungen zu erwarten.
|
|
|
|
Bei der Programmierbarkeit sieht die Sache allerdings etwas anders aus. Windows 8 stellt hier naturgemäß kein Problem dar, da es die freie Installation und Nutzung beliebiger Desktop-Software zulässt. Es ist die gesamte Palette an Windows-Software verfügbar. Bei Windows Phone und Windows RT ist man hingegen im Wesentlichen auf Metro-Apps und Webapps beschränkt. Auch hier spricht jedoch kein handfester Grund gegen die Programmierung auf den Geräten. Es gibt sogar seit langem eine offizielle, \enquote{Touchstudio} genannte, App für Windows Phone, die auch für Windows Phone 8 verfügbar sein wird. Mit dieser ist eine grundlegende Programmierung der Geräte möglich. Da es sich jedoch um eine eingeschränkte -- und aus didaktischer Sicht eher ungeeignete -- grafische Programmierumgebung handelt, ist sie für den Unterricht nicht relevant. Dennoch bestünde die Möglichkeit, eine entsprechende App für die Ausführung von (\zb in Python geschriebenem) Code zu entwickeln. Dies wäre zwar aufwendig, anders als bei Apple aber möglich. Es stehen also für Windows 8 alle notwendigen Werkzeuge und Dokumentationen bereit, für Windows RT und Windows Phone wären hingegen noch deutliche Vorarbeiten zu erbringen.
|
|
|
|
\subsubsection{Kosten}
|
|
|
|
Die Anschaffungskosten für gut ausgestattete Smartphones mit Windows Phone 7 liegen derzeit deutlich unter vergleichbaren Geräten der anderen Plattformen. Allerdings gibt es keine besonders günstigen Einstiegsgeräte. Die Preise für die nächste, aktuelle Generation, inklusive der neuen Tablets, sind noch weitgehend unbekannt. Weitere Kosten entstehen nicht zwingend, so ist zwar für die Verbreitung von Windows Phone Apps ein Entwicklerzugang notwendig, das Testen von unsigniertem Code auf der eigenen Hardware erfordert jedoch nur eine kostenfreie Registrierung.
|
|
|
|
\subsubsection{Langlebigkeit}
|
|
|
|
Grundsätzlich scheint Microsoft eine recht sinnvolle Update-Politik zu verfolgen. Regelmäßige Updates für alle Geräte sind üblich, da diese weitgehend herstellerunabhängig sind. Die verfügbaren Geräte selbst unterscheiden sich in Verarbeitung und Haltbarkeit nicht wesentlich von anderen mobilen Informatiksystemen. Allerdings gibt es bisher keine sehr günstigen, tendenziell eher schlecht verarbeiteten Geräte.
|
|
|
|
\subsection{Andere}\label{secPlatOth}
|
|
Neben den bereits weit verbreiteten Plattformen gibt es einige weitere, sehr interessante Ansätze, die allesamt auf Linux basieren\vglr{figPlatLin}. Bisher ist ihnen allerdings gemein, dass die nötige Hardwarebasis fehlt. Außer einigen Testgeräten sind de facto keine Modelle mit den Systemen erhältlich.
|
|
|
|
Es zeigt sich erneut, wie bedeutungsvoll das optionale Kriterium der Verwendung Freier Software\vglr{secKritOSS} ist, denn alle als Freie Software verfügbaren Plattformen erfüllen grundsätzlich die Anforderungen für den Unterricht. Die Verfügbarkeit des Quellcodes und die zugrunde liegende Basis erlauben eine weitreichende Anpassung und die Ausführung der meisten als Freie Software vorliegenden Programme. Außerdem sind viele Standardbibliotheken verfügbar, sodass die Programmierbarkeit und die Verfügbarkeit von Werkzeugen kein Problem darstellen. Spezialfälle sind jedoch die Betriebssysteme \textit{Tizen}, \textit{Chrome OS} und \textit{Firefox OS}, da diese entweder teilweise (Tizen) oder vollständig auf Webapps setzen. Dies schränkt natürlich die Perspektive der Veränderung der Welt auf den Aspekt der Erzeugung von Webapps\vglr{secPersWebApp} ein.
|
|
|
|
Im Hinblick auf die Einsatzmöglichkeiten für die Schule erscheinen derzeit die beiden Plattformen MeeGo-Ableger \textit{mer} und \textit{Jolla} als besonders aussichtsreich. Da mer allerdings zunächst hauptsächlich den Aufbau einer entsprechenden technischen Basis vorantreibt, ist Jolla hier wohl die bessere Option. Ob sich diese Systeme tatsächlich etablieren können, ist derzeit allerdings fraglich.
|
|
|
|
Für den Einsatz von Tablets kommen noch weitere Kandidaten infrage. Neben üblichen Desktop-Linux-Distributionen und solchen mit speziell auf Touchscreens optimierten Benutzungsschnittstellen (etwa Ubuntus Unity Desktop) sind hier speziell entwickelte Ansätze wie Plasma Active\vglr{figPlatLin} verfügbar. Allerdings fehlt auch hier derzeit noch die Hardwarebasis. Mit der Verbreitung von Windows 8 Tablets könnte jedoch die Bedeutung dieser Systeme geringfügig zulegen. Zumindest die Windows 8 Tablets erlauben die Installation alternativer Betriebssysteme, da sich hier \gls{SecBoot} deaktivieren lässt. Bei den eigentlich interessanteren Tablets mit Windows RT\vglr{figPlatWin}, auf Basis der ARM-Architektur, wird dies jedoch nicht ohne Weiteres möglich sein, sodass hier vermutlich die Rooting-Problematik\vglr{secRoot} greift.
|
|
|
|
\subsection{Fazit}
|
|
|
|
Das bei \SuSn durchaus beliebte iOS muss derzeit für den Informatikunterricht als unbrauchbar gewertet werden. Daher ist Android in der jetzigen Situation die einzig sinnvolle Basis. Es erübrigt sich also die Frage, welche Plattform zunächst für die Umsetzung berücksichtigt werden sollte.
|
|
|
|
Es gibt zwar viele Anzeichen dafür, dass in Zukunft weitere Plattformen genutzt werden können, dem steht jedoch im Moment in erster Linie die Verbreitung dieser Plattformen im Weg. Einzig bei Windows scheint es mittelfristig einigermaßen sicher, dass eine entsprechende Verbreitung erreicht werden kann. Windows 8 bietet gute Möglichkeiten für den Einsatz im Informatikunterricht, Windows RT und Windows Phone sind hingegen relativ stark geschlossene Plattformen. Trotzdem erscheint ihr Einsatz mit entsprechendem Aufwand durchaus möglich.
|
|
|
|
Da potentiell eine Vielzahl von Plattformen infrage kommt, muss bei der Gestaltung der Systeme eine grundlegende Plattformunabhängigkeit berücksichtigt werden.
|