Cross-Plattform – die Lösung für das iOS vs. Android Dilemma?

Cross-Plattform – die Lösung für das iOS vs. Android Dilemma?

Wie im letzten Beitrag schon erläutert, sollte ein App Programmierer, der nicht gerade bei Apple oder per se eingestellt ist, sondern für Auftraggeber arbeitet, um deren Geschäftsideen in eine funktionierende App zu gießen, auch genau dies tun. Klingt selbsterklärend? Nun ja, der erfahrene App-Entwickler wird wissen, dass dies meist nicht so einfach und schnell umgesetzt ist, wie so mancher Kunde sich erhofft. Um dennoch eine möglichst große Reichweite an App-Nutzern zu erzielen, sollte man darauf achten, eben nicht ausschließlich für iOS oder Android zu programmieren. Dadurch würden mit Sicherheit viele potentielle Kunden verloren gehen.

Denn was für das eine programmiert ist, wird für das andere nicht laufen. Es gilt also sich dranzusetzen und für jedes Betriebssystem die gewünschte App zu schreiben. Das kostet nicht nur Zeit und Energie, sondern den Auftraggeber einiges mehr an Geld, da der Entwickler die App zwei Mal separat schreiben muss.

Auch für den Entwickler selbst eine ziemlich nervenaufreibende Angelegenheit, die viel Detailgetreue, Kleinarbeit und Konzentration erfordert.

Geht das wirklich nicht einfacher?

Da Softwareentwickler so viel Zeit und Aufwand sparen wollen wie nur möglich, hat man natürlich auch für Situationen wie diese einen Lösungsansatz entwickelt – Cross Plattform. Wie der Name schon sagt, kann man auf einer Plattform Schnittmengen programmieren für eine App, die auf verschiedenen Betriebssystemen auf dem Smartphone laufen soll.

Mit Frameworks wie Xamarin, PhoneGap, oder Titanium und zahlreichen weiteren Möglichkeiten, die auf Webtechnologien wie HTML, C# und JavaScript basieren, kann man eine App nur einmal schreiben und sie auf allen Smartphones mit verschiedenen Betriebssystemen laufen lassen. Hört sich eigentlich wie die Lösung schlechthin an und das oben beschriebene Problem erscheint ziemlich unnötig aufgebauscht, wenn es doch so etwas wie Cross Plattform gibt. Doch ganz so einfach ist das leider nicht, da nativ geschriebene Apps immer noch im Vorteil sind. Mit nativen Apps sind hierbei Betriebssysteme wie Android und iOS gemeint, die in ihrer eigenen Entwicklungsumgebung und ihrer zuständigen Sprache geschrieben sind. Vergleichbar ist dies mit Muttersprachlern (sprich Natives), die unter sich reden, statt mit anderen auf einem einigermaßen akzeptablem Englisch Niveau, sodass man sich auch noch mit anderen unterhalten kann. Letzteres wäre im übertragenen Sinne die Cross Plattform Variante.

Schnittmenge Cross Plattform – der App-Allrounder
Dazu kann man durchaus unterschiedliche Meinungen haben, denn wieso sollte man sich nicht einfach auf Englisch unterhalten, damit auch möglichst viele mich verstehen können? Der Vorteil hierbei ist natürlich erstmal, dass ich so viel mehr Leute ansprechen kann ohne jemanden auszuschließen, auch wenn jeder von uns eine jeweils andere Muttersprache hat. So verhält es sich auch mit der Cross Plattform, die es ermöglicht Android, iOS, Windows oder Blackberry User anzusprechen und die Apps für jedermann zur Verfügung zu stellen. Keiner ist aufgrund seines Betriebssystems und der Wahl seines Smartphones von dem Zugang der App ausgeschlossen. Grundlegend eine ausschließlich positive Sache, die dem Auftraggeber sowie Entwickler es ermöglicht, die App auf möglichst breite Masse weiterzugeben. Wie schon erwähnt, braucht man für die Entwicklungsumgebungen für eine Cross Plattform App Kenntnisse in JavaScript, HTML und CSS – oder C# für Xamarin. Das sind die Sprachen, die ein App Entwickler beherrschen sollte, um sich in die Aufsetzung einer Cross Plattform einzuarbeiten.

Gibt es einen Haken?

Weg vom Englisch-Vergleich, hin zum konkret technischen Pro-Contra. Kommen wir nun zu dem Haken, den solch eine Allrounder Lösung über kurz oder lang aufweist:

Eine Cross Plattform kann natürlich nur einen Teil der möglichen Features und Assets abbilden, die in einer nativen App vorhanden sind. Zu einer Wettbewerbsbeschränkung kann es also dann kommen, wenn iOS oder Android Updates durchführen und neue Funktionalitäten rausbringen, die in einer Cross Plattform – App noch nicht integriert werden konnte und die Nutzer somit auf diese Funktionen verzichten müssen, die eine native App demzufolge automatisch auch kann, sobald ein Update der Betriebssysteme durchgeführt wird. Das könnte einige Nutzer stören und somit von der entwickelten Cross Plattform -App Abstand nehmen lassen, was natürlich sehr schade ist.

Wann lohnt sich Cross Plattform, wann native Entwicklung?

Man sollte sich als angehender App-Entwickler also immer die Frage stellen, wann die Umsetzung der Idee eine native App Entwicklung erfordert und wann eine Cross Plattform Entwicklung.
Bei einer Gaming App ist beispielsweise die Performance sehr wichtig. Graphische Anforderungen sowie die Rechnerleistung müssen on top sein und eins a funktionieren. Hier macht der Cross Plattform Ansatz keinen Sinn. Eine saubere, native Entwicklung ist hierbei erforderlich.

Ebenso gibt es Fälle, in denen auf die Smartphone-eigenen Ressourcen zurückgegriffen wird und viele Daten schnell und responsive verarbeitet werden müssen. Auch hierbei würden wir raten, sich an einzelne native Entwicklungen zu machen.

Quality Over Quantity

Als abschließendes Fazit lässt sich sagen, dass der Cross Plattform Ansatz eine kostengünstige und gute Variante ist, um viele App-Nutzer mit an Bord zu holen und die App grundsätzlich jedem zur Verfügung zu stellen. Energie, Zeit und Kosten werden gespart, wovon wir – wer nicht? – ein großer Fan sind.
Dennoch gilt das Prinzip Quality over Quantity gerade in Bereichen, in denen Kunden den Erfolg des Produkts bestimmen. Wenn die Qualität mit der Cross Plattform also gegeben ist, ist sie ein hilfreicher Allrounder. Sprechen Aspekte, wie die oben genannten dagegen, sollte man davon absehen.

Wir hoffen, dass der Beitrag beim Entscheidungsweg helfen konnte und die wichtigsten Pros und Contras in den Vordergrund gestellt hat.

Wir freuen uns über Feedback und weitere Anregungen in der Kommentarspalte.

Die Angst um das Ende von React bringt alte Bekannte zurück: Angular vs. Vue.js vs. Ember

Die Angst um das Ende von React bringt alte Bekannte zurück: Angular vs. Vue.js vs. Ember

Python, JavaScript, PHP, Java, C# – die Wahl der richten Programmiersprache und der passenden Frameworks stellt für Entwickler in manchen Augenblicken die Qual der Wahl dar. So gibt es für unterschiedliche Anforderungen und Schwerpunkte bestimmte Sprachen und Programme, die dafür am besten geeignet sind. Nichtsdestotrotz existieren einige Top-Acts, die die Liste anführen. So hat IT-Gigant IBM JavaScript zur besten Erlern-Programmiersprache 2017 gekürt.
Doch auch da ist die Auswahl für Frameworks riesig. Nachdem nun React für manche mehr oder weniger abgehakt werden kann – siehe dazu unseren letzten Blogbeitrag – wollen wir euch nun drei Alternativen dazu vorstellen. Diese lauten Angular, Vue.js und Ember.

Wer sind sie?

Alle drei Frameworks sind clientseitig, basieren auf dem MVVM (Model View ViewModel) Model, werden für das Erstellen von SPAs (Single Page Applications) verwendet und sind (mehr oder weniger) in JavaScript geschrieben. Angular wurde von Google entwickelt und gehört mit seiner Vorgängerversion AngularJS zu den am meisten verwendete JS Framework für SPAs. Angular 2 ist in Typescript geschrieben, das auf JavaScript, Java und C# basiert. Seit Ende März ist Version 4 auf dem Markt. Vue.js ist ein relativ junger Newcomer, der vorgibt, das Beste aus Angular und React herauszuholen. Ember wurde 2015 als das beste JavaScript Framework angepriesen und findet zum Beispiel bei Netflix, Yahoo und LinkedIn Verwendung.

Was können sie?

Bei allen drei Frameworks fällt durch das MVVM die Controller Einheit weg und es wird stattdessen eine Verbindung der Darstellungs- und Logikebene hergestellt. Interaktionen können so schneller und einfacher umgesetzt werden. Angular wird vor allem aufgrund der Einfachheit der Nutzung von den Entwicklern präferiert. Es kann somit mit WordPress‘ Konzept verglichen werden – sehr einfach zu verwenden, aber in der technischen Umsetzung nicht so extravagant. Bei Vue.js lag der Fokus darauf ein schnelles und schlankes Frontend Framework zu entwickeln. Ähnlich wie bei React wird hier eine virtuelle DOM Implementierung genutzt, die die Rendering Geschwindigkeit und den Speicherverbrauch laut Entwicklern um bis zu das Vierfache verbessert haben soll. Vue.js lässt ebenso dem Programmierer die Wahl zwischen Templates und JSX/Hyperscript. In Version 2 gibt es zusätzlich eine Redone-Rendering Schicht, die für eine bessere Performance sorgen soll. Ebenso ist das Framework mit der neuen Version auch (besser) auf die Entwicklung von mobilen Apps ausgerichtet. Ember folgt dem DRY Prinzip und ist nach dem Grundsatz data down, actions up aufgebaut. Das Framework nutzt Web Compoments, und will langfristig die Controller und Templates durch diese ersetzen.

Wie gut sind sie?

Angular stellt die beste Option für Unternehmensbasierte Apps und Programmierlandschaften mit hohen Lesbarkeits-Standards dar. Die bessere Wahl für die schnelle Entwicklung von betriebssystemübergreifenden Lösungsansätzen ist jedoch Vue.js. Das Framework punktet zudem durch eine einfache Handhabung. Ember wird demgegenüber vornehmlich für komplexe Webapplikationen und Websites mit vielen Features verwendet. So sind dynamische Apps und Websites bei Ember gut aufgehoben. Es ist das Framework, das einen, wenn man es verstanden hat, dazu befähigen kann, sehr produktiv zu sein. Jedoch heißt dies, dass die Lernkurve auch sehr hoch ist und es somit gleich zu Beginn viel zu lernen gibt.

Fazit

Alle drei Frameworks können zwar als Konkurrenten angesehen werden, jedoch besitzt keines davon einen signifikanten Vorteil gegenüber den anderen. Alle besitzen die gleiche Grundlage – sie sind ein JavaScript Framework. Das bedeutet im Endeffekt mehr Effizienz, Sicherheit und weniger Kosten als ohne Framework. Egal ob durch Angular, Vue.js oder Ember – Programmierarbeiten können zeitsparender und strukturierter umgesetzt werden und haben gleichzeitig bessere Sicherheitsbestimmungen. Zudem sind alle Frameworks Teil einer Open Source Software – und anders als React von Facebook – auch wirklich frei zugänglich.

Ist das das Ende für React?

Ist das das Ende für React?

Die JavaScript Bibliothek React von Facebook gehörte bisher zu den beliebtesten Tools zur Erstellung von interaktiven Websites. Jetzt kann React den Programmierern jedoch zum Verhängnis werden. Denn die Lizenz-Situation und Nutzungsbedingungen des eigentlich als Open Source ausgelegten Tools sind heikel geworden. Zu Open Source gehören Softwares, deren Quelltext öffentlich eingesehen, genutzt und verändert werden darf. Eigentlich.

 

Was steckt dahinter?

React, welches erstmals 2013 mit einer Open Source Software herausgegeben wurde, dient dazu, Anwendungen sehr flüssig darzustellen, selbst bei großen Datenbanken. Der Vorteil von React ist, dass dort ein virtuelles DOM vorliegt, welches einfacher zu manipulieren ist und die Bibliothek so in der Lage ist, Interaktionen schneller umzusetzen. Gleichzeitig nimmt React die Komplexität aus dem View-Layer. Demnach ist das Tool besonders nützlich, wenn eine Website viel Interaktivität fordert.
Jedoch steht die Verwendung von Facebook‘s Open Source Software, darunter eben auch genannte Bibliothek React, unter einer BSD Plus Lizenz. BSD (Barkeley Software Distribution) heißt, dass die Software nur kopiert, verändert und verbreitet werden darf, wenn das Copyright Vermerk des ursprünglichen Programms nicht entfernt wird. So weit so gut. Nun hat Facebook vor einigen Wochen eine weitere Klausel zum Lizenzrecht ihrer Software hinzugefügt. Diese sagt aus, dass jedem die Nutzungsrechte für eben jene Open Source Software entzogen werden, wenn mit der Nutzung in irgendeiner Weise Konkurrenz-Ansprüche zu Facebook entstehen. Weiterhin geht aus der Klausel hervor, dass durch eine Klage gegen Facebook die Lizenzrechte ebenfalls entfallen. Im Original heißt dies:

„The license granted hereunder will terminate, automatically and without notice, if you […]take a direct financial interest in[…] any Patent Assertion against Facebook […]“

Open Source Software mit BSD Plus Lizenz – heißt konkret?

Facebook‘s Technik-Direktor Adam Wolff begründet diese Entscheidung damit, dass Facebook die Balance halten möchte, weiterhin Open Source Software zur Verfügung zu stellen, gleichzeitig aber das eigene Unternehmen vor teuren Rechtsstreitigkeiten schützen will.
Die Website React-etc empfiehlt in dieser Hinsicht gar einen Anwalt heranzuziehen, wenn React weiter benutzt werden möchte. Ebenso rät ein Entwickler der Apache Foundation , dass Startups möglichst nicht React benutzen sollten. Dies könnte mögliche Firmenübernahmen gegebenenfalls verhindern. Die Apache Foundation, eine Gemeinschaft von Entwicklern, die an Open Source Software Projekten arbeiten, hat nun sogar die Verwendung der Open Source Software von Facebook ihren Programmierern untersagt. Diese Entscheidung wird damit begründet, dass diese Lizenz ein Risiko an den Konsumenten weiterreichen würde und dieses Risiko deutlich stärker zu Lasten der Anwender ausfallen würde. Außerdem würde dies die Apache-Richtlinien verletzen, die unter anderem diktieren, ein universeller Spender zu sein.

React – das trojanische Pferd unter Open Source?

Diese Entscheidung stellt nun ein großes Problem für Entwickler dar, die unter Apache arbeiten, da sie React an vielen Stellen verwendet haben. Am meisten jedoch stört sie die unethische Einstellung von Facebook gegenüber einer Open Source Software. React sei, so die Entwickler, ein trojanisches Pferd in der Open Source Community und diese Verhaltensweise sei kein Beispiel dafür, wie Open Source funktionieren sollte. Adam Wolff gibt zu, durch diese Entscheidung einige Nutzer zu verlieren, jedoch stehe der Schutz des Unternehmens an erster Stelle. Er argumentiert, dass Facebook die Software auch ganz vom öffentlichen Markt hätte nehmen können.

Also, ihr lieben Programmierer unter euch, passt auf, wenn ihr React benutzen wollt – Alternativen dazu stellen beispielsweise das Webframework vue.js, die Programmiersprache Elm oder die Bibliothek Riot.js dar.

Hilfreiche jQuery/Javascript Plugins – Teil 5

Hilfreiche jQuery/Javascript Plugins – Teil 5

Heute setzen wir unsere Reihe zu jQuery Plugins fort und stellen euch ein paar praktische Neuheiten vor, die jede Website zum absoluten Hingucker machen.

iziToast

iziToast

Mit diesem Plugin könnt ihr schicke Notifications auf eurer Website einbinden. Diese sind nicht nur schlank und flexibel, sondern auch noch responsive. Dadurch lassen sich informative Mitteilungen auf der Seite einblenden, aber auch Aufforderungen zu einer Aktion oder Warnmeldungen. Das sieht nicht nur gut aus, sondern macht die Seite auch persönlicher und interaktiver für Nutzer.

Hier eine beispielhafte Vorschau des Codes:

Mirror Effect

Der Name „Mirror Effect“ sagt eigentlich schon alles: Hiermit könnt ihr hübsche Spiegeleffekte erzeugen. Das macht sich zum Beispiel besonders gut auf der Landing Page einer Website. Ein Bild wird entweder innerhalb einer Slideshow gespiegelt, oder einfach als Dekoration. Wichtig ist, dass dafür ein moderner Browser verwendet wird.

nanogallery2

nanogallery2

nanogallery2 ermöglicht das Erstellen schöner Bildergalerien mit einer Vielzahl an Effekten. Es stehen eine Reihe von Designoptionen zur Verfügung, mit denen ihr nach Belieben eine Galerie für eine Website oder einen Blog entwerfen könnt. Individuell angepasst werden können zum Beispiel das Layout, Hover Effekte für Thumbnails und der Darstellungsmodus. Auch die Navigation über Tags und die Einbindung von Bildern aus Services wie Flickr ist möglich.

Das sieht dann zum Beispiel so aus:

Paroller.js

Dieses Plugin macht Parallax Scrolling auf Websites möglich. Das sieht zum einen wirklich elegant aus und bringt zum anderen Leben in die Seite. Während des Scrollens können sich Elemente entweder horizontal oder vertikal bewegen. Der Code lautet dann beispielsweise so:

Außerdem ist das Plugin auch noch für mobile Geräte geeignet. Was will man mehr?