Das Experiment eine iOS App für 5$ ist damit abgeschlossen. Das Resultat ist ok, aber weit davon entfernt zu sein von daher werde ich nach und [...]]]> Ready for Sale

Die App hat den Apple Review ohne Komplikationen passiert und ist nun in iTunes zum Download verfügbar. Die kleinen Änderungen haben also gereicht um den Review zu überstehen.

Zusammenfassung

Das Experiment eine iOS App für 5$ ist damit abgeschlossen. Das Resultat ist ok, aber weit davon entfernt zu sein von daher werde ich nach und nach die fehlenden Features (Offline-Fähigkeit, Sharing, Kommentare, etc.) nach und nach ergänzen.

Für einen Laien wäre die App allerdings nichts gewesen, denn die diversen Mängel hätten die App niemals den AppleReview passieren lassen. Von den “versteckte Features” wie dem fremden Google Analytics Account ganz zu schweigen. Es ist also nicht ohne weitere möglich eine App für 5$ zu erhalten die man ohne Programmierkenntnisse oder weitere Unterstützung in den AppStore stellen kann.
Für mich als Entwickler war es aber ein interessantes Experiment und auch wenn ich die App lediglich als mögliche Grundlage für eine selbstentwickelte App nach meinen Vorstellungen betrachte, sind 5$ für das grundlegende Projekt auch ein interessantes Angebot.

Nachdem die iOS App nun also im AppStore ist werde ich mich Android und Windows Phone zuwenden. Für beide Plattformen habe ich inzwischen ein vergleichbares Angebot gefunden und warte aktuell auf die erste Lieferung des Quellendes. Es wird also demnächst Beiträge zu den Themen “Eine Android App für 5$” und “Eine Windows Phone App für 5$” geben.

weitere Teile

• Teil 1: Das Experiment
• Teil 2: Der gelieferte Sourcecode 
• Teil 3: Vorbereitungen für den AppStore
• Teil 4: Der Apple Review

In diesem Teil möchte ich kurz erläutern welche Teile ich geändert habe bevor ich die App in den AppStore eingestellt habe. Insgesamt habe ich nicht mehr als 2,5h damit verbracht.

Bei Kauf [...]]]> Im 2. Teil habe ich ja beschrieben, welche verschiedenen Bugs und Unvollständigkeiten den Release der gelieferten App in den AppStore de facto unmöglich machen.

In diesem Teil möchte ich kurz erläutern welche Teile ich geändert habe bevor ich die App in den AppStore eingestellt habe. Insgesamt habe ich nicht mehr als 2,5h damit verbracht.

Unerwünschtes löschen

Bei Kauf der App wusste ich nicht, dass z.B. mein privates Facebook-Profil Teil der App werden würde, da es mit meinem Blog nichts zu tun habe, habe ich die Tabbar mit den Socialmedia-Links (die eh einfach nur in einem WebView geöffnet wurden gelöscht.

Nötige Kosmetik

Da die App auch als Experiment natürlich irgendwie auf mich zurückfällt habe ich die App mit so wenig Aufwand wie möglich ein wenig aufgehübscht. Dank UIAppearance war das sehr schnell erledigt. Die App sieht nun so aus:

Nötige rechtliche Änderungen

Bei der App war natürlich kein Impressum vorgesehen, was man ja auch nicht erwarten kann, denn generell ist es doch eher ein recht deutsches Phänomen. Die Impressumseite musste ich also ebenfalls ergänzen.

Das Google Analytics Tracking habe ich natürlich auch nicht weiter auf den fremden Account weiterlaufen lassen sondern durch meinen Account ersetzt. In einem Update werde ich es vermutlich ganz entfernen. Erstmal wollte ich es aber drin lassen um die App so wenig wie möglich zu verändern.

Erste Tests mit Usern & fehlende Features

Vor dem Apple-Review habe ich die App einigen Nutzern gezeigt um ein paar Meinungen zu der App zu sammeln um zu sehen, welche Features die Leute eigentlich von einer “Blogreader”-App erwarten. Die Hauptkritikpunkte waren:

• mangelnde Offlinefähigkeit
• Gallerie oben ist nicht zu erkennen und auch nicht “klick”bar
• Links innerhalb von Blogposts werden im WebView als Webseite geladen
• Videos werden nicht sauber im Vollbild abgespielt
• kein PullToRefresh für die Artikel/kein Nachladen der älteren Artikel beim scrollen nach unten

Danke an Carsten Pelka, Mirko Lemme (mileon.net) und Kevin Grahl(kevingrahl.de) für’s testen und Feedback schicken.

Und jetzt abwarten

Die App ist nun in den Apple Review eingereicht. Sobald die App abgelehnt oder im AppStore ist, werde ich den letzten Teil dieser Reihe schreiben.

• Teil 1: Das Experiment
• Teil 2: Der gelieferte Sourcecode 
• Teil 3: Vorbereitungen für den AppStore
• Teil 4: Der Apple Review

Direkt beim ersten Start/Blick auf den Sourcecode war klar, diese App wird es so nicht in den AppStore schaffen, denn Apps, die in den AppStore hochgeladen werden müssen u.a. 2 Bedingungen erfüllen:

Sie müssen mindestens iOS 4.3 als [...]]]> Wie im 1. Teil angekündigt werde ich in diesem Teil genauer auf den Sourcecode der gelieferten App eingehen.

Experiment vorbei?

Direkt beim ersten Start/Blick auf den Sourcecode war klar, diese App wird es so nicht in den AppStore schaffen, denn Apps, die in den AppStore hochgeladen werden müssen u.a. 2 Bedingungen erfüllen:

Sie müssen mindestens iOS 4.3 als Target haben und einen iPhone5 Splashscreen anbieten, also das iPhone5 Display unterstützen.

Auf den ersten Blick war also klar: Diese App schafft es so nicht durch den Review. Streng genommen wäre das Experiment damit vorbei, denn Ziel war es ja die App auch im AppStore zu veröffentlichen. Aber da sich zumindest diese beiden Punkte mit wenigen Klicks beheben lassen, setzen wir das Experiment mal weiter fort.

Alter Code

Die oben genannten Probleme ließen schon vermuten, dass die App nicht unbedingt gestern, sondern vor einiger Zeit entstanden ist. Die Kommentare im Header deuten auf Ende 2011/Anfang 2012.

Das Alter stört aber eigentlich kaum, da die App ja trotzdem tut was sie soll man iOS Apps normalerweise das Alter des Sourcecodes nicht bzw. kaum ansieht. Für Nicht-Programmierer mag dieser Punkt also völlig irrelevant sein. Andererseits ist es für Nicht-Programmierer auch nicht gerade leicht die für den Review nötigen Änderungen durchzuführen, auch wenn sie wirklich gering sind.

Viel Framework, wenig selbstgeschrieben

Ein Punkt, der wirklich nicht verwerflich ist. Viele der Klassen stammen aus OpenSource Projekten. Das würde ich sogar als Pluspunkt verbuchen, da ich hier bei mit heißer Nadel gestrickten eigenem Lösungen wesentlich mehr Bauchschmerzen hätte. Die selbstgeschriebenen Bereiche beschränken sich wirklich auf die ViewController.

EDIT: Ärgerlich ist, dass auch Beschränkungen der verwendeten Frameworks nicht berücksichtigt wurden, so tauchen in der Liste HTML Tags auf, die aus dem RSS-Feed stammen und nicht entfernt werden.

Was ist Retina?

Ein Ärgernis ist, dass in einer 2012 geschriebenen App (da war das iPhone4 schon anderthalb Jahre alt) nicht alle Grafiken in Retina-Auflösung mitgeliefert werden. Das sieht nicht nur besch…en aus, es ist auch ebenfalls ein Ablehnungsgrund. Interessant ist auch, dass alle nachgeladenen Grafiken eine Breite von 480px haben und damit genau zwischen normal und Retina liegen. Vielleicht ein Kompromiss für die Ladezeiten, vielleicht auch einfach seltsam.

Kritisch: Nicht genannte Features

Über ein Feature bin ich beim Durchsehen eher zufällig gestolpert. Die App nutzt Google Analytics und zwar mit eingetragenem (fremden) Account! Das fand ich dann doch ein starkes Stück. Ein unbedarfter Blogger, der sich tatsächlich einfach nur eine App für seinem Blog kaufen will würde also die Tracking-Daten seiner Nutzer unwissend Dritten zur Verfügung stellen.

Fazit

Die App ist vom geschriebenen Code nicht schlecht, wirklich nicht. Aber da die App für Nicht-Entwickler niemals durch den Review gehen wird und außerdem ein fremdes Google Analytics Konto mit den Tracking-Daten versorgt wird, kann ich an dieser Stelle nur davon abraten solch ein Angebot zu erwägen.

Ich werde die App trotzdem nach so wenig Anpassungen wie möglich in den AppStore stellen um zu sehen ob die App es durch den Apple Review schafft.

• Teil 1: Das Experiment
• Teil 2: Der gelieferte Sourcecode
• Teil 3: Vorbereitungen für den AppStore
• Teil 4: Der Apple Review

Das Angebot lautete grob: Die eigene WordPress [...]]]> Was für Marketing Agenturen und andere Firmen, die Apps entwickeln lassen, wie die Erfüllung all ihrer Träume und Gebete klingt, wird bei Entwicklern sicherlich nur Kopfschütteln hervorrufen. 5$ (abzgl. der Gebühren der Plattform) für eine komplette App, das ist wirklich mickrig. Doch was bekommt man für seine 5$?

Das Angebot

Das Angebot lautete grob: Die eigene WordPress Seite als native App für 5$.
Ok, dachte ich. Das kann man eigentlich für 5$ nur dann anbieten, wenn man eine Standart-Lösung hat, in die man einfach die URL einträgt und das Ganze ausliefert. Außerdem hatte ich ein wenig die Sorge lediglich die kompilierte App zu bekommen und für alle Anpassungen (wie z.B. ein Impressum) immer wieder zahlen zu müssen. Doch hier wurde ich überrascht. Für die 5$ sollte tatsächlich auch der komplette Sourcecode mit drin sein. Ok, damit war die Entscheidung gefallen und ich habe dieses Angebot bestellt.

Weitere 5$

Nachdem ich das Angebot gekauft hatte, sollte ich einige Grafiken bereitstellen, die ich aber gerade nicht zur Hand hatte, außerdem war ich ja neugierig auf den Sourcecode und zu ungeduldig um die 10 Grafiken eben zu erstellen, also habe ich darum gebeten einfach Platzhalter zu verwenden, ich würde die Grafiken dann später austauschen. Die Antwort kam zügig: Das ginge nicht, aber für weitere 5$ würde man mir “richtige” Grafiken (Splashscreen, App-Icon, etc) erstellen. Ok also weitere 5$ bezahlt, danach hieß es warten, denn die Auslieferung der App sollte ca. 7 Tage in Anspruch nehmen.

Die fertige App

Nach 5 Tagen konnte ich mir mein Projekt dann herunterladen und ausprobieren. Die Optik war eher enttäuschend. Aber die App lief solide, die Artikel wurden geladen und angezeigt. Die weiteren Tabs führten zu WebViews in denen dann jeweils mein Facebook Profil, mein Twitter Account oder mein GooglePlus Account (mit Video-Icon) angezeigt wurden.

Die Grafiken waren die größere Enttäuschung, aber fairer Weise muss man ja auch sagen, was will man für 5$ schon erwarten. Die App machte auf den ersten Blick genau was sie sollte und auch bei der Detailansicht wurde nicht einfach die Website in einem WebView geladen.

Wie es weiter geht

In weiteren Schritten werde ich den gelieferten Sourcecode noch ein wenig näher beleuchten und die App anschließend so vorbereiten, dass sie in den AppStore gestellt werden könnte (Impressum hinzufügen, die gröbsten Design-Schnitzer entfernen, etc). Ziel hierbei wird sein, den Sourcecode nicht bzw. nur minimal zu verändern und generell so wenig Aufwand wie möglich zu betreiben. Am Ende soll die App auch in den AppStore gestellt werden um zu sehen ob eine App für 5$ es denn auch durch den Apple Review schafft.

… und was ist mit Android?

Bei Android habe ich interessanterweise noch kein Angebot entdeckt bei dem eine native App inkl. Sourcecode angeboten wird. Sollte ich solch ein Angebot finden werde ich auch für Android mal eine App für 5$ entwickeln lassen.

weitere Teile

• Teil 1: Das Experiment
  
• Teil 2: Der gelieferte Sourcecode
• Teil 3: Vorbereitungen für den AppStore
• Teil 4: Der Apple Review

Die Folien dazu habe ich jetzt auch auf Slideshare hochgeladen.

Building High Quality Android Applications from Leif Janzik

.@elliotmonster [...]]]> Auf der DroidCon 2013, der größten Konferenz zum Thema Android in Deutschland, habe ich einen Vortrag zum Thema “Building High Quality Android Apps by using Jenkins and automated device tests” gehalten.

Die Folien dazu habe ich jetzt auch auf Slideshare hochgeladen.

Eine Rückmeldung via Twitter:

.@elliotmonster thanks for your great #droidcon talk on continuous integration and device testing.

— Andreas Jägle (@ajaegle) 9. April 2013

Mit folgenden Attributen kann man AirPlay für ein Video deaktivieren: <video src="video.mov" [...]]]> Zugegeben, mir fällt kein Grund ein warum man AirPlay für ein Video deaktivieren sollte. Aber das heisst ja noch lange nicht, dass es keine Gründe gibt oder das niemand einen Kunden hat, der AirPlay für seine Videos nicht erlauben möchte.

Mit folgenden Attributen kann man AirPlay für ein Video deaktivieren:

<video src="video.mov"
       height="768" width="1024"
       x-webkit-airplay="deny" >
</video>
 
<!-- or -->
 
<embed airplay="deny"
       src="movie.mov"
       width=320
       height=240
       mime-type="video/quicktime">
</embed>

Mehr über CocoaPods findet ihr unter cocoapods.org, dort gibt es auch [...]]]> Nachdem ich in meinem neuen Job immer öfter mit CocoaPods, einem Dependency Management Tool für iOS Apps zu tun habe und mich in letzter Zeit verstärkt mit dem Thema Continuous Integration beschäftigt habe, habe ich nun eine erste Version eines Jenkins Plugins für CocoaPods veröffentlicht.

Mehr über CocoaPods findet ihr unter cocoapods.org, dort gibt es auch ein kurzes aber umfassendes Einsteiger-Tutorial.

In der ersten Version gibt es lediglich einen Build-Step, der ein “install” und ein “update” ausführt, d.h. die Abhängigkeiten für frisch ausgecheckte Projekte werden initial heruntergeladen bzw. aktualisiert.

Für spätere Versionen sind u.a. noch folgende Erweiterungen geplant.

• Pfad zur “pod”-Executable konfigurierbar machen
• Report über die Pods des gebauten Projekts

Verbesserungsvorschläge und Bugs

Verbesserungsvorschläge, Feature-Wünsche und Bugs werden hier gesammelt.
Außerdem könnt ihr den Sourcecode auf GitHub finden.

Wer das iPad mini schon jetzt in Präsentationen oder Konzepten einbinden möchte kann also sofort starten.

24.10.2012 EDIT: inzwischen gibt es mehrere weitere iPad mini PSDs

Eine Möglichkeit um diesen Code zu reduzieren, die bei normalen Java Applikationen bereits große Verbreitung findet, ist die [...]]]> Eine Sache, die mich bei Android sehr nervt ist die Art wie View, Resourcen oder Layouts mit der Activity interagieren. Es überfrachtet den Sourcecode mit unnötigen Zeilen in denen Buttons, TextViews, Layouts usw. mit der Activity verknüpft werden.

Eine Möglichkeit um diesen Code zu reduzieren, die bei normalen Java Applikationen bereits große Verbreitung findet, ist die Verwendung eines Dependency Injection Frameworks wie Spring oder Googles Guice. Doch für Android sind diese Frameworks (noch) zu schwergewichtig und für die meisten Apps außerdem völlig überdimensioniert. Doch es gibt ein kleines Framework, das mit wenig Overhead genau diese Dependency Injection für Android bietet: Roboject

Schon mit wenigen Elementen wirkt die onCreate schnell überladen

Views und Layout müssen manuell in der onCreate Methode verknüpft bzw. definiert werden.
Mit Roboject sähe die gleiche Activity wie folgt aus:

Auf das Überschreiben der onCreate Methode kann in diesem Fall komplett verzichtet werden, der größte Vorteil an Robject liegt allerdings nicht im Sparen von Codezeilen sondern in der Verbesserung der Lesbarkeit und damit auch der Wartbarkeit des Quellcodes. Einzige Restriktion ist, dass die Activity von RobjectActivity erben muss.

Eine Kleinigkeit missfällt mir allerdings an Robject in der aktuellen Version. Die IDs sind Strings und die R Klasse wird nicht direkt verwendet. Das bietet zwar große Vorteile beim Logging für Roboject, d.h. die “ID” kann im Error Log angezeigt, wenn die ID nicht gefunden wird. Dafür ist ein späteres Refactoring allerdings sehr fehleranfällig und auch die Code-Completion der IDE kann nicht genutzt werden.

Aus diesem Grund habe ich einen Fork des Projektes gemacht und verwende dort wieder direkt die Klasse R

Der Quellcode sieht dann wie folgt aus:

Für mich überwiegt an dieser Stelle einfach das bessere Refactoring und die Code-Completion die lesbareren Logs, zumal die Wahrscheinlich für Fehler drastisch sinkt, da die meisten Tippfehler bereits vom Compiler entdeckt werden würden.

Der Fork auf GitHub

Wie jedes Mal nachdem ein neues Gerät mit “Flaggschiff”-Qualität (egal ob nun Nokia Lumia, Samsung Galaxy S3 oder iPhone) in den Verkauf steht suche ich nach geeigneten PSDs für [...]]]> Das iPhone5 ist jetzt bereits seit ein paar Tagen im Handel. Ich selbst warte zwar noch auf mein Gerät, hoffe es aber noch diese Woche zu bekommen.

Wie jedes Mal nachdem ein neues Gerät mit “Flaggschiff”-Qualität (egal ob nun Nokia Lumia, Samsung Galaxy S3 oder iPhone) in den Verkauf steht suche ich nach geeigneten PSDs für Konzepte, Präsentationen, App Websites usw.

Für das iPhone5 gibt es bereits eine Menge schöner PSDs, alle hier zusammengetragenen PSDs haben eins gemeinsam: Das Display ist ein Smart-Object und somit kann der Inhalt sehr leicht ausgewechselt werden, die perspektivische Anpassung erfolgt dann automatisch.

iPhone 5 Psd Vector Mockup

klassische Frontansicht, gut geeignet für Konzepte oder wichtiger Screenshots

Zur PSD

3/4 iPhone 5 Vektor MockUp

Als schöner Blickfang auf App-Websites oder in Präsentationen ist die 3/4 Ansicht mal eine willkommene Abwechslung.

Zur PSD

iPhone5 Characteristic Angle

Zur PSD