Better Location Sharing with Shareloc

It's finally been done and I'm very happy to see Shareloc in the iOS App Store. The first prototype was created almost a year ago, the backend api has been rewritten 3 times and the app already shows its second redesinged UI. Overall I'm very satisfied with the current state and looking forward to push the app further.

Why yet another location sharing app?

Good question and I heard it a lot telling people about Shareloc. So I want to explain you how it all came together. In the beginning there was a simple need. I just wanted to share my location with my wife and my friends. And in this case there are not only alreadx exisiting some apps for that, it's an iOS integrated feature. So I used it and I was disappointed because it didn't work as expected. Then I tried other location sharing services on iOS including glympse, facebook and google maps. But none did satisfy all of my requirements and those are not that special in my opinion. Basically there are 3 obvious features that I want:

  • Ease of use: It has to be really easy and fast to use. If it takes me more than 5 seconds to share my location, I probably won't use the app.
  • Accuracy: The shared location should be as accurate as possible. If the person I shared my location with only knows my position up to 100 meters accurate, then location sharing looses some use cases for me.
  • Speed: The update interval for my location should not be limited. If there is a new location available, it should be available to my shared contact immediately.

And then there is a fourth and implied feature: security! It's not last because it's least important, it's here because the user can't see it. You maybe can check if the data transfer is encrypted, but you don't know how long the location data are stored and with whom they are shared.

As all services I tested did at least fail two of those features I created a small prototype testing if the GPS on the iPhone was accurate enough to fulfill my needs. As it turns out: Yes! And now here I'm presenting Shareloc the location sharing service living up to my and hopefully also your needs and expectations.

How are you making money with a free app?

In the current state: I'm not and that is fine for me. I'm a freelance software developer and Shareloc is a some kind of work sample for people who may want to hire me. Also the operating costs of Shareloc are pretty low, so don't expect the app to loose it's current "free"-pricetag.

That doesn't mean there are no plans to monetize the app at all. In the future it might be possible to buy some extra features via an in-app-purchase or make little donations, but that are still dreams of the future.

What's next?

Shareloc is working great as it is, but it is still an 1.0, and the plans for 1.x- and 2.x-versions have been around since the beginning. During the developement and beta testing I created a backlog of ideas and feature requests that I'm now prioritizing. Also if you have a feature request please use the contact form on the Shareloc website to share it with me.

Also if you like Shareloc and would like to see new features before everybody else, just let me know and I will add you as a beta tester.

 

Meine erste eigene iPhone (Location Sharing) App

Der Vorsatz eine eigene App im Apple Store zu haben besteht schon lange, doch irgendwie hat es bis jetzt nie geklappt. Und das obwohl ich schon 6 Jahre für die iOS Plattform programmiere. Nachdem ich inzwischen sogar selbständiger iOS Entwickler bin, konnte ich diesen Umstand so nicht belassen. Es blieb die Frage was die eigene App eigentlich machen bzw. welches Problem sie für mich, aber vor allem die Nutzer, lösen soll. Die kurze Antwort darauf ist: Location Sharing. Der primäre Grund dafür ist, dass ich mit den vorhandenen Lösungen unzufrieden war. Entweder waren diese zu umständlich, die Nutzeroberfläche nicht durchdacht, der Dienst zu langsam, ungenau oder unzuverlässig. Damit waren auch schon die Ziele der neuen App definiert: Einfach, Schnell, Präzise, Zuverlässig und da es hier um Positionsdaten von Nutzern geht, mit höchster Priorität auch Sicherheit.

Was ist dieses "Location Sharing" und wozu brauche ich es?

Mit dem Begriff "Location Sharing" wird die Möglichkeit beschrieben, den eigenen Standort mit einer anderen Person zu teilen. In der Regel wird dieser Person einfach eine Nachricht mit einem Link zu einer Webseite gesendet, über die der eigene Standort auf einer Karte angezeigt werden kann. Der Andere weiß somit wann ich mich wo befinde. Doch wozu nutze ich diese Funktion?

  • Jemanden wissen zu lassen, dass ich mich gerade auf dem Weg befinde. Egal ob der ich von der Arbeit nach Hause fahre, oder mich mit Freunden treffe.
  • Treffen ohne genauen Treff- und Zeitpunkt, wie zum Beispiel beim Shopping, in einem Park oder einem Konzert.
  • Den richtigen Weg finden. Wenn man in einer unbekannten Umgebung nicht weiter weiß, kann man einfach den Standort teilen und sich von einem Bekannten den Weg erklären lassen.

Es gibt aber viele weitere Situationen, in denen ich inzwischen gerne meinen Standort teile.

Aktueller Stand

Seit der Idee und Konzeption ist nun schon einige Zeit vergangen. Da es sich bei einem solchen Dienst nicht "einfach" nur um eine App handelt, sondern auch um einen Webservice, eine Webseite und ein paar weitere Dinge, war auch wirklich viel zu tun. Das meiste ist nun aber geschafft und ein Ende der Entwicklung in Sicht. Mit dem Ergebnis bin ich bisher sehr zufrieden, seit wenigen Monaten läuft bereits ein geschlossener Betatest des Dienstes. Entsprechend aktueller Planung wird die App im ersten Halbjahr 2017 im App Store veröffentlicht. Mehr möchte ich jetzt hier aber noch nicht verraten.

Betatester gesucht

Um die Zuverlässig- und Skalierbarkeit der App besser beurteilen zu können, benötige ich aktuell noch ein paar Betatester. Wer andere Dienste, wie das in iOS integrierte Teilen des Standortes oder Apps wie Glympse regelmäßig nutzt und daran interessiert ist meine App zu Testen, kann sich über das folgende Formular zum Betatest anmelden. Wichtig ist, dass die App nur für das iPhone gemacht ist, Nutzer eines iPads oder anderer Smartphones können diese somit aktuell nicht installieren. Nach erfolgreicher Anmeldung sende ich Dir eine TestFlight Einladung zur App, diese enthält eine Anleitung wie Du die App auf Deinem iPhone installieren kannst. Zusätzlich erhältst Du eine Einladung zu einem Slack Channel, den ich für die Kommunikation mit den Testern nutze. Dort kann man mich am einfachsten direkt erreichen, ob mit Fragen, Ideen oder Problemen.

Custom compass position in MKMapView

For map views in native iOS apps MKMapView is my first choice. While implementing an map based app I came to the point where the compass was showing under a menu component. This is because the default compass position is in the top right corner of the map view. So there were two solutions to the problem:

  1. Change the position of the compass
  2. Remove the compass and implement a custom one

Although the second option sounded tempting, the first one seemed to be the obvious choice. But then I learned that the MKMapView doesn't let you do anything with its compass besides the possibility to show or hide it via the 'showCompass' function. I was surprised by this fact, because on the iOS default map app you can see the compass on a custom position.

Custom compass position in apple maps app
Custom compass position in apple maps app

Solving the puzzle

By analyzing the issue I saw the compass is a subview of the map with a custom class called 'MKCompassView'. As the class itself is private API it is not exposed for external use, but I don't need that. To set a new position for the compass I subclassed the MKMapView component and overrode the layoutSubviews function to change the frame of the MKCompassView.

As you can see this is really easy. Then I just had tell the app to use the map view subclass as the map component and my problem was solved.

 
App showing the compass at a custom position on a MKMapView
App showing the compass at a custom position on a MKMapView
 

Make it useful

Then I realized that a static position isn't good at all in my case, you will see the reason later. So I made the position variable and added a simple animation. The final code looks like this:

Inside the app it looks like this:

 
Animated custom compass position on a MKMapView
Animated custom compass position on a MKMapView
 

Awake - An OS X Wake-on-Lan Dashboard Widget

Looking for an easy-to-use OS X Wake-on-Lan Dashboard Widget? Then you are right here. But first things first.

awake_widget.png

What is Wake-on-Lan

Wake-on-Lan is a feature many network enabled devices implement to switch on the device via the network. If Wake-on-Lan is enabled on the device you just have to send a so called "magic packet" to the device and it turns on. All you need to know about the device is its MAC address, a globally unique id, every network device has. This is especially helpful if you don't have physical access to the device like a server in a datacenter. As there is no real magic in the creation of the magic packet there are lots of applications out there supporting Wake-on-Lan.

Why using a dashboard widget

Even though it seems that the dashboard will die in OS X in the not so far future, there are still some cases where I love to have it. One of these cases is Wake-on-Lan to start up my NAS server whenever I need it. I wanted a tool that doesn't waste any menubar space and just does its job fast and easy.

Do it yourself

As I couldn't find an existing Wake-on-Lan dashboard widget I decided to make one myself. Long story short, here is "Awake":

Awake - An OS X Wake-on-Lan Dashboard Widget
Version: 0.1
Release Date: 29.09.2015

Open up

To make the project available for everybody I released it under the MIT-Zero License. So feel free to use is it in any way you like and check out the github project repository.

MacOS Mail: "Google-Konto: Anmeldeversuch blockiert"

Wer die Meldung "Google-Konto: Anmeldeversuch blockiert" schon einmal bekommen hat, wird sich fragen woran das liegt. In meinem Fall wurde der E-Mail-Abruf auf meinem MacBook Pro in Mail verhindert und ich habe folgende Meldung erhalten.

 Anmeldeversuch gesperrt – Google-Konto in MacOS Mail gesperrt

Anmeldeversuch gesperrt – Google-Konto in MacOS Mail gesperrt

Ursache

Wenn man sich durch den Prozess klickt, erfährt man auch aus welchem Grund Google den Account gesperrt hat.

 Ursache der Account-Sperrung

Ursache der Account-Sperrung

In meinem Fall handelt es sich hier aber nicht um ein ungewöhnliches Ereignis. Die Ursache war ein regulärer E-Mail-Abruf. Das besonders ärgerliche an dieser Meldung ist, dass das Fenster nicht geschlossen werden kann. Es ist modal und auch nach Abschluss der Sicherheitsüberprüfung ist die "Fertig"-Schaltfläche nicht aktiviert. Man muss das Mail-Programm also entweder über die Aktivitätsanzeige oder schneller durch Drücken der Alt-Taste und Rechtsklick auf das Mail-Symbol "Sofort Beenden". Wenn man die Sicherheitsüberprüfung des Google-Kontos erfolgreich durchgeführt hat, kann nach einem Neustart von Mail das Google-Konto wieder online geschaltet werden und der E-Mail-Abruf funktioniert wieder.

Die Quelle allen Übels

Doch was war jetzt eigentlich die Ursache für diese in meinem Fall sporadische Meldung? "Power Nap!" Seit MacOS 10.8 gibt es diese Funktion, die es dem Rechner ermöglicht auch im Schlafmodus verschiedene Dienste auszuführen und hierzu gehört auch das Abrufen von E-Mails. "Power Nap" lässt sich in den Systemeinstellungen unter "Energie sparen" aktivieren. Welche Betriebssysteme und Geräte "Power Nap" unterstützen und weitere Informationen findet man unter folgendem Link bei Apple: Informationen zu Power Nap.

 Systemeinstellungen > Energie sparen

Systemeinstellungen > Energie sparen

Ich konnte bei mir nachvollziehen, dass der Google-Account immer gesperrt wurde, wenn die Mails im Ruhezustand meines MacBook Pros abgerufen wurden. Doch auch hier stellt sich die Frage, warum das passiert. Meine Erklärung hierfür ist, dass der während des Ruhezustands genutzte Systemdienst sich beim Abrufen von Mails anders verhält als das Programm Mail selbst und so die Kontosperrung verursacht.

Lösung

Was kann man also machen um das Sperren des Google-Kontos zu verhindern? Hierfür gibt es entweder die naheliegende Möglichkeit die Funktion "Power Nap" über die Systemeinstellungen zu deaktivieren, was ich getan habe, oder man aktiviert im Google-Konto den Zugriff durch weniger sichere Apps (Link zur dieser Einstellung).

 Google-Account: Sicherheitseinstellungen bezüglich weniger sicherer Apps

Google-Account: Sicherheitseinstellungen bezüglich weniger sicherer Apps

Das ist allerdings nur möglich, wenn man für seinen Google-Account nicht die Zwei-Faktor-Authentifizierung aktiviert hat.

E-Mail-Bilder mit OCR auslesen - Harvester lernen lesen

Die Impressumspflicht zwingt quasi jeden Betreiber einer Webseite ein Impressum einzubinden. Hier müssen einige persönliche Informationen angegeben werden, was im Internet auch schnell mal missbraucht wird. So ist schon lange bekannt, dass sogenannte Harvester durch einfaches parsen von Webseiten unter anderem E-Mail-Adressen sammeln, die dann für den Spamversand genutzt werden. Aus diesem Grund wurden schon viele Methoden entwickelt, um das einfache Auslesen der E-Mail-Adresse zu verhindern. Einige basieren auf der Manipulation der Anzeige über CSS oder Javascript, da die Harvester, zumindest bis heute, nur den html-Quelltext der Webseiten durchsuchen ohne Javascript und CSS zu interpretieren. Einen interessantes Projekt in diesem Zusammenhang findet man hier: http://www.drweb.de/magazin/wirklich-wirksamer-schutz-fr-e-mail-adressen/

Doch in diesem Artikel möchte ich mich mit einem anderen Schutzmechanismus beschäftigen. Mit der Verwendung von Bildern, auf denen die E-Mail-Adresse geschrieben steht, sollen Harvester ausgetrickst werden, da sie den Text nicht lesen können. Oder etwa doch?

Da ich in mehreren Projekten bereits mit OCR (Abkürzung für: Optical Charater Recognition) in Berührung gekommen bin, also dem computergestützten Erkennen von Schrift in Bilddateien, stellte ich mir die Frage wie sicher diese E-Mail-Bilder wirklich sind. Einem entsprechend programmierten Harvester sollte es doch möglich sein den Text auf den Bilddateien zu erkennen und somit die E-Mail-Adresse zu ermitteln.

Aus der Neugier heraus, ob das wirklich funktioniert, habe ich hierfür ein Testprogramm als Proof-Of-Concept geschrieben. Die Basis für die Erkennung sind 30 selbst erstellte E-Mail-Bilder, die ich mittels verschiedener Onlinedienste erzeugt habe. Um ein möglichst realistätsnahes Ergebnis zu erhalten, habe ich außerdem mehrere übliche Variationen beim Erzeugen angewendet.

 service_1_0

service_1_0

 service_1_1

service_1_1

 service_1_2

service_1_2

 service_2_0_0

service_2_0_0

 service_2_0_1

service_2_0_1

 service_2_0_2

service_2_0_2

 service_2_1_0

service_2_1_0

 service_2_1_1

service_2_1_1

 service_2_1_2

service_2_1_2

 service_2_2_0

service_2_2_0

 service_2_2_1

service_2_2_1

 service_2_2_2

service_2_2_2

 service_3_0

service_3_0

 service_3_1

service_3_1

 service_3_2

service_3_2

 service_4_0

service_4_0

 service_4_1

service_4_1

 service_4_2

service_4_2

 service_5_0

service_5_0

 service_5_1

service_5_1

 service_5_2

service_5_2

 service_6_0_0

service_6_0_0

 service_6_0_1

service_6_0_1

 service_6_0_2

service_6_0_2

 service_6_1_0

service_6_1_0

 service_6_1_1

service_6_1_1

 service_6_1_2

service_6_1_2

 service_7_0

service_7_0

 service_7_1

service_7_1

 service_7_2

service_7_2

Der Programmablauf ist dabei wie folgt:

  1. Optimieren der Bilder für die OCR - Da eine OCR meist für die Erkennung von Text auf gescannten Dokumenten optimiert ist, hat diese bestimmte Anforderungen an das Quellmaterial. Die hier verwendeten E-Mail-Bilder wurden deshalb vor der Texterkennung optimiert, um bessere Ergebnisse zu erhalten. Nach vielen Versuchen bin ich bei folgendem Algorithmus angekommen: Bild in Graustufen umzuwandeln, skalieren und dann den Kontrast erhöhen. Ein interessanter Effekt hierbei ist, dass sich dadurch nicht nur die Erkennungsqoute gegenüber dem unbearbeiteten Bild verbessert hat, sondern auch die Verarbeitungsgeschwindigkeit der OCR deutlich erhöht wurde.
  2. Auslesen der E-Mail-Adresse aus den Bildern - Da ich es auch schon in anderen Projekten gemacht hatte, lag es nahe die freie OCR-Engine "tesseract" zu verwenden¹. Sie liefert ausreichend gute Ergebnisse, auch wenn die proprietäre Konkurrenz bekanntermaßen bessere Erkennungsraten bietet.

Zum Schluß habe ich das Ergebnis noch manuell kontrolliert, um zu prüfen ob die OCR richtig lag.

Lets go

 Programmdurchlauf des EMailImageReader

Programmdurchlauf des EMailImageReader

Nun sollen endlich ein paar Zahlen zu den Ergebnissen folgen, wobei ich mir natürlich bewusst bin, dass die verwendeten Inputbilder keine repräsentative Stichprobe, aber für diesen Test absolut ausreichend sind. Die Verarbeitungszeit der 30 Bilder betrug über mehrere Läufe gemittelt etwa 4,5 Sekunden. Die Erkennungsquote der OCR lag dabei im Durchschnitt bei 33 %. Wenn genügend Inputbilder zur Verfügung stehen ergeben sich daraus 133 korrekt ermittelte E-Mail-Adressen pro Minute, was hochgerechnet fast 8000 E-Mail-Adressen pro Stunde ergibt. Auch wenn klassische Harvester vermutlich eine deutlich größere Leistung durch einfaches Parsen von Webseiten erreichen, ist dies ein beachtlicher Wert.

Wie erwartet war die Erkennung bei Bildern mit sehr speziellen Fonts oder Bildrauschen sehr schlecht. Man muss aber auch anmerken, dass das hier verwendete Programm nur als Proof-Of-Concept bezeichnet werden kann. Es gibt noch einige Möglichkeiten die Erkennungsquote und Performance deutlich zu erhöhen und damit die Anzahl korrekt erkannter E-Mail-Adressen pro Minute.

  • Der oben beschriebene Algorithmus zur Bildoptimierung lässt sich zum Beispiel um das Entfernen von Bildrauschen oder eine dynamische Kontrastverbesserung erweitern.
  • Die einzelnen Anwendungsschritte lassen sich gut parallelisieren. Durch den Einsatz von Multithreading kann das Suchen und Laden der Bilddateien, die Optimierung der Bilddateien und die OCR gleichzeitig für verschiedene E-Mail-Bilder erfolgen. Die Geschwindigkeit dürfte sich dadurch leicht um den Faktor 5 - 10 erhöhen lassen und ist dann hauptsächlich durch die Systemleistung (CPU für OCR und Internetanbindung wegen Webseiten- und Bilder-Download) beschränkt.
  • Durch Optimierung der OCR lässt sich die Erkennungsrate noch deutlich erhöhen. Zum Beispiel ließe sich die OCR trainieren, so dass E-Mail-Adressen besser erkannt werden. Alternativ kann auch eine sogenannte Whitelist angegeben werden, die nur Zeichen enthält, die auch in E-Mail-Adressen zulässig sind. Über ein Wörterbuch, dass die häufigsten E-Mail-Provider-Domains enthält, kann die OCR-Erkennung nochmals deutlich verbessert werden. Man könnte das Wörterbuch sogar beim Crawlen dynamisch um die Domainnamen erweitern, von welchen entsprechende Bildern geladen wurden.

Wie wahrscheinlich ist der Einsatz von OCR bei Harvestern?

Auch wenn es keine technischen Hürden gibt mittels dem hier beschriebenen Verfahren E-Mail-Adressen zu sammeln, gibt es keinen Grund zur Panik. Es ist doch sehr unwahrscheinlich, dass diese Technik von Harvestern verwendet wird, auch in absehbarer Zukunft. Folgende Punkte müssen nämlich bedacht werden:

  • Da die OCR-Technologie relativ viel CPU-Leistung benötigt, ist das hier beschriebenene Verfahren deutlich rechen- und somit kostenintesiver als das herkömmliche Parsen von Webseiten.
  • Damit ein Crawler möglichst effizient arbeitet, müsste er für die vielen verschiedenen Anbieter und Varianten von E-Mail-Bildern speziell angepasst werden, was einen hohen Aufwand verursacht.
  • Manche Anbieter von E-Mail-Bildern bieten die Möglichkeit die Providerdomain als separate Grafik abzubilden (z.B.: @gmail.com) und Textfarben und -größen zu ändern um OCR zur erschwehren. Diese Techniken bieten zwar keinen echten Schutz, empfehle ich aber trotzdem jedem, der auf E-Mail-Bilder nicht verzichten kann oder möchte. Der Aufwand dem Crawler das Erkennen der Grafiken "beizubringen" dürfte auch kaum im Verhältnis zum daraus resultierenden Nutzen stehen.
  • Tendenziell werden Personen, die Ihre E-Mail-Adresse mit so viel Aufwand versuchen zu schützen, kaum auf den versendeten Spam "klicken". Die Opferquote dürfte hier viel geringer sein, als unter Personen, deren E-Mail-Adressen unbedarft ins Internet gelangen. Eine teuere Optimierung durchzuführen um danach nicht die primäre Zielgruppe zu erreichen

E-Mail-Bilder sicher nutzen

Auch wenn man vor Lesenden-Harvestern aus oben genannten Gründen keine Angst haben muss, lässt sich der Einsatz von E-Mail-Bildern mit ein paar einfachen Richtlinien weiter absichern:

  • Binden Sie das Bild nicht über einen Link zum Hersteller ein, da dieser über das Parsen der Seite Rückschlüsse zulässt. Legen Sie das Bild einfach auf dem eigenen Webspace ab.
  • Wenn das Bild über JavaScript / CSS eingebunden wird, kann der Link zum Bild in der Regel nicht durch einfaches Parsen der Webseite ermittelt werden.
  • Verwenden Sie keinen Dateinamen, der darauf hinweist, dass auf dem Bild eine E-Mail-Adresse vorhanden ist.

¹ Es ist zwar möglich eine in .NET verwendbare Version von tesseract aus dem Quelltext zu erzeugen allerdings gibt es hierfür auch schon fertige Projekte im Netz, die das Einbinden der OCR deutlich vereinfachen. Ich habe in diesem Fall das Projekt von Charles Weld verwendet: .NET Wrapper für tesseract (GitHub-Link)

PDFs verkleinern mit dem Mac

Auf einem Mac lassen sich PDF-Dateien ohne zusätzliche, meist kostenpflichtige, Anwendungen verkleinern. Hierfür reicht es das Dokument mit der integrierten Vorschau zu öffnen und über den Menüpunkt "Ablage > Exportieren" erneut abzuspeichern. Dabei muss nur der vordefinierte Filter "Reduce File Size" gewählt und gesichert werden.

 Mit Filter exportieren

Mit Filter exportieren

Die Einstellungen des Filters können dabei aber nicht auf eigene Anforderungen angepasst werden. Da Bilder und Fotos mit der Standardeinstellung sehr drastisch komprimiert werden, habe ich einen anderen Weg gesucht und gefunden, um die Grafiken nicht unnötig zu verpixeln. Hierfür muss man lediglich einen eigenen Quartz-Filter erstellen, der die gewünschte Konfiguration enthält. In der Systemanwendung "ColorSync-Dienstprogramm" dupliziert man den Eintrag "Reduce File Size", gibt ihm einem sprechenden Namen und passt die Einstellungen wie gewünscht an.

 Duplizieren des System-Filters

Duplizieren des System-Filters

 
 Beispiel für höhere Qualitätseinstellungen

Beispiel für höhere Qualitätseinstellungen

 

Der auf diese Weise erstellte Filter steht leider nicht in der oben beschriebenen Auswahl zur Verfügung, da hier nur die vordefinierten Systemfilter verwendet werden können. Es gibt aber noch einen anderen Weg, der es ermöglicht den eigenen Filter anzuwenden. Man wählt einfach im Kontextmenü der zu verkleinernden Datei im Finder den Punkt "Öffnen mit > ColorSync-Dienstprogramm", wählt unten links den selbst erstellten Filter und wendet diesen an.

 
 Öffnen mit Color-Sync

Öffnen mit Color-Sync

 
 
 Eigenen Filter wählen

Eigenen Filter wählen

 

Wenn das PDF-Dokument vorher große Grafiken enthielt, sollte es nun, abhängig von den verwendeten Einstellungen, verkleinert worden sein. In einem konkreten Fall hatte die Ausgabedatei nur noch 10% der Größe der Ursprünglichen. Aber Achtung: bei zu hohen Qualitätseinstellungen und bereits gut komprimierten PDF-Dokumenten kann es auch vorkommen, dass die Datei durch den Vorgang sogar vergrößert wird.

In abgewandelter Form habe ich diese Vorgehensweise auch an anderer Stelle im Netz gefunden, aber die Kombination mit der Erstellung eines eigenen Filters ist hier entscheidend, um den Grad der Kompression optimieren zu können.

Zu scharf - Wieviel HD brauchen wir wirklich?

Mit Einführung und Verbreitung von HD-Technologie und -Inhalten, besonders im TV-Bereich, hat es angefangen. Doch HD ist uns heute schon nicht mehr gut genug, es muss schon mindestens FullHD sein. Dass sich der Trend weiter fortsetzt, zeigt die sich bereits in den Startlöchern befindliche 4K-Technologie mit der alles noch schärfer und besser werden soll. Aber unser Alltag wird immermehr von Bildschirmen aller Art dominiert, ob Werbetafel, Smartphone, Smartwatch, Tablet PC, Notebook oder der gute alte Monitor. Dabei kommen viele verschiedene Größen, Auflösungen und Technologien zum Einsatz, doch für eine gute Darstellungsqualität sind zwei Faktoren ganz entscheidend: Die Pixeldichte und der Betrachtungsabstand. Idealerweise können wir mit bloßem Auge die Pixelstruktur der Displays nicht mehr wahrnehmen, was die biologisch maximale Bildschärfe beim Menschen darstellt. Technisch lässt sich die Pixeldichte zwar noch erhöhen, wir werden aber keinen Unterschied mehr "sehen" können. Das kann sogar negative Effekte haben, bei einer zu hohen Pixeldichte im Verhältnis zum Abstand lassen sich nicht mehr alle Details wahrnehmen.

Mobile Innovation / Revolution

Der Trend zu hochauflösenden Bildschirmen bei mobilen Geräten wurde am 07. Juni 2010 von Apple mit Vorstellung des iPhone 4 eingeläutet. Eine große Neuerung war der Einsatz eines sogenannten Retina-Displays mit der 2-fachen Auflösung im Gegensatz zum Vorgänger. Einen so hochauflösenden Bildschirm gab es bis dahin in keinem mobilen Gerät, dass auch noch in solch immensen Stückzahlen produziert und verkauft wird. Mobiles HD ist hier somit erstmals bei der breiten Masse angekommen. Auch wenn die Konkurrenz recht lange gebraucht hat gleichzuziehen, bietet sich heute eine Vielfalt hochauflösender Displays in den Geräten unseres Alltags. Es folgt der Vergleich von einigen Geräten bezüglich der Pixeldichte ihrer Displays.

Auch wenn die technischen Eckdaten von manch neuem Gerät in der Hochglanzbroschüre oder im direkten Gerätevergleich beeindrucken mögen, gilt hier auch: Weniger ist manchmal mehr. Wird nämlich die Auflösungsgrenze des menschlichen Auges überschritten, kann man keine Auflösungsunterschiede mehr wahrnehmen. Konkret heißt das, dass Sie im normalen Gebrauch keinen Unterschied sehen werden ob das Display Ihres Mobiltelefons nun mit 300 ppi oder mit 450 ppi auflöst.

Zu Scharf

Wo diese Auflösungsgrenze nun genau liegt ist strittig und nicht nur davon abhängig, ob wir gut oder schlecht sehen, sondern auch vom individuellen Betrachtungsabstand und von der verwendeten Displaytechnologie. Durch die meist unterschiedliche Pixelstruktur von TFT- und OLED-Displays, genügen bei Ersteren schon etwa 220 ppi, wobei letztere bis zu 300 ppi benötigen um die Grenze der menschlichen Sehschärfe, im folgenden Graph gemittelt bei 275 ppi eingezeichnet, zu erreichen.

Pixeldichte_geschnitten.png

Alle Geräte, deren Pixeldichte über der horizontalen roten Linie liegt, weißen damit eine für das menschliche Auge nicht mehr erkennbare Pixelstruktur auf. Wie viel der Wert über der Linie liegt ist dabei egal. Wenn man das Diagramm betrachtet muss man spätestens ab dem Sony Experia Z2 von einer unnötig hohen Auflösung sprechen. Ein konkretes Beispiel hierfür ist Folgendes:

"Der Bildschirm hat 1920 × 1080 Bildpunkte statt 1280 × 768 wie beim Nexus 4. Mit bloßem Auge lässt sich der Unterschied allerdings kaum erkennen, denn beide Anzeigen wirkten gestochen scharf." (Google Nexus 5 Gerätetest bei Heise.de)

Dabei sollte man nun noch anmerken, dass diese Übertreibung für den Nutzer keinen echten Vorteil, dafür aber Nachteile mit sich bringt. Die wichtigsten negativen Effekte einer zu hohen Pixeldichte dürften Folgende sein:

  • Die Kosten für Displays mit höherer Pixeldichte (bei gleicher Panelgröße) sind höher, somit die entsprechenden Geräte teuerer.
  • Bei gleicher Paneltechnologie z.B. TFT führt eine Erhöhung der Pixeldichte in der Regel zu einem höheren Energiebedarf und somit zu geringerer Laufzeit.
  • Zur Darstellung von Inhalten in höherer Auflösung wird zusätzlich der Prozessor und die Grafikeinheit stärker belastet, was wiederum zu einer geringeren Leistung und Laufzeit führt.

Für den Endnutzer bedeutet das konkret: Teurere Geräte mit kürzeren Akkulaufzeiten. Besonders bei Smartphones spielt der letzte Faktor aber eine ganz entscheidende Rolle.

Fazit

Auch wenn der Griff zu einem bestimmten Smartphone-Modell häufig nicht auf Grund detaillierter Analyse technischer Details erfolgt, lohnt es sich die Sinnhaftigkeit mancher "Features" zu hinterfragen. Es scheint allerdings, als würden vielen Herstellern Mut und Ideen für weitere Innovationen im Smartphone-Sektor fehlen, so dass man von Modell zu Modell die Devise verfolgt: "Größer, Schneller und Hochauflösender", egal ob das für den Nutzer überhaupt vorteilhaft ist, oder nicht.

Ribbon XML in Microsoft Office Addins

Der folgende Artikel befasst sich mit der Erstellung von Oberflächenelementen in Microsoft Office Addins, welche Probleme autreten können und wie man Sie lösen kann. Die Code-Snippets und das am Ende des Posts bereitgestellte Beispielprojekt beziehen sich auf ein Outlook-Addin, die verwendeten Techniken lassen sich aber auch direkt auf Word- oder Excel-Addins anwenden.

Designer vs. XML

Wenn man mit Visual Studio eine GUI für ein Microsoft Office Addin erstellen möchte hat man die Wahl, ob man mit dem grafischen Designer oder direkt im XML-Editor arbeiten möchte. Sicherlich ist die erste Variante einfacher, beschränkt sich aber auf das Erstellen von Ribbons. Manche Anpassungen der GUI, wie zum Beispiel das Kontextmenü, können somit nur per XML-Datei manipuliert werden. Leider lassen sich die unterschiedlichen Methoden nicht mischen¹, man muss in komplexeren Szenarien durchgängig die Oberfläche in XML beschreiben.

Neben dem geringeren Komfort für den Entwickler gibt es aber noch weitere Schattenseiten. Besonders dynamische Oberflächen, die Lokalisierung verwenden oder Elemente bedingt ausblenden, sind hiermit recht umständlich abzubilden. Der größte Nachteil kommt aber zum tragen, wenn man verschiedene Oberflächenelemente, wie Ribbon und Kontextmenu, unabhängig voneinander bei unterschiedlichen RiddonIDs verwenden möchte. Hierzu muss man nämlich für jede Kombination der Elemente eine eigene XML-Datei erstellen. Damit sinkt wiederum die Wartbarkeit und Wiederverwendbarkeit des Quellcodes. Doch dieses Problem lässt sich beheben. Warum beschreibt man nicht einfach jedes Oberflächenelement in einer XML-Datei und fügt sie dann im Programmcode zur konkreten Oberfläche zusammen?

Funktionsweise von Ribbon XML

Zum besseren Verständnis der ganzen Lösung beschreibe ich nochmal kurz die Funktionsweise von Ribbon XML. Wenn man dem AddIn-Projekt ein Ribbon XML Element hinzufügt wird nicht nur eine XML-Datei, sondern auch eine zugehörige Klasse erzeugt. Der Hook für die Ausführung von Ribbon XML ist die Funktion "CreateRibbonExtensibilityObject()" in der ThisAddin-Klasse.

Hiermit wird beim Laden der grafischen Oberfläche die Funktion "GetCustomUI" in der Klasse "CustomUIManager" aufgerufen und bietet damit die Möglichkeit eigene Oberflächenelemente zu erstellen. Wenn man mehrere getrennte Oberflächenelemente erzeugen können möchte und damit mehrere XML-Dateien verwendet, muss eine der automatisch erzeugten Klassen als Controller verwenden, die dann die Oberflächenerstellung übernimmt. Genau dort steckt auch der Kern der ganzen Lösung. Abhängig von der an die Funktion "GetCustomUI" übergebenen RibbonID, wird das entsprechende RibbonXML-String erzeugt und zurückgegeben. Die RibbonID ist ein String der angibt welcher Teil der Anwendungsoberfläche gerade geladen wird. Eine vollständige Liste der RibbonIDs in Microsoft Outlook kann im MSDN nachgelesen werden. Die restlichen Office-Anwendungen besitzen keine so komplexe Unterteilung der Oberfläche und verwenden jeweils nur eine RibbonID (im Einzelnen Microsoft.Word.Document, Microsoft.Excel.Workbook und Microsoft.PowerPoint.Presentation).

Auf den ersten Blick mag es vielleicht etwas unübersichtlich aussehen, ist aber ganz einfach. Jedes mal wenn die Oberfläche geladen wird, z.B. beim Anwendungsstart oder durch Interaktion des Nutzers, wird die Funktion "GetCustomUI" aufgerufen. In dieser wird dann die XML-Repräsenation der eigenen Oberflächenelemente erzeugt und zurückgegeben. Die einzelnen Schritte sind:

  1. Prüfen ob für die übergebene RibbonID eine eigene Oberfläche erzeugt werden soll.
    • ja: weiter mit den folgenden Schritten 2 bis 4
    • nein: sofort zurückkehren um die Ausführung nicht zu blockieren
  2. Lokalisieren der erzeugten Oberfläche mit der Funktion "LocalizeRibbonXML". Hierfür werden lediglich alle Einträge einer Ressourcendatei geladen um die Texte der Oberfläche zu setzen.
  3. Bedingtes Ausblenden von Elementen mit der Funktion "HideRibbonXMLElement". Hiermit könnnen einzelne Oberflächenelemente, falls sie aus bestimmten Gründen nicht angezeigt werden sollen, ausgeblendet werden.
  4. Zurückgeben des erzeugten XML-Strings.

Außerdem habe ich noch die Funktion "OnRibbonElement_Click" für das Eventhandling hinzugefügt um Nutzereingaben entsprechend behandeln zu können.

Das Vorgehen setzt natürlich vorraus, dass die verwendeten XML-Dateien keine XML-Header und CustomUI-Tags enthalten, der Inhalt der Datei "OUI_ContextMenu.xml" sieht bei mir zum Beispiel so aus:

Zum Ausprobieren, Weiterentwicklen und Wiederverwenden habe ich mein vollständiges Visual Studio 2010-DemoProjekt für ein Outlook 2010-AddIn zum Download angehängt. Das Konzept wurde ebenfalls mit Visual Studio 2012 und Office 2013 getestet, kann also auch in neueren Projekten angewendet werden.

1 Es ist nicht ganz richtig, dass sich Designer- und XML-Methode nicht in einem Projekt gemeinsam verwenden lassen. Wenn man die Funktion "CreateRibbonExtensibilityObject()" in der ThisAddin-Klasse, die für die Verwendung der XML-Methode benötigt wird.