Tobias Hößl

Seit diesem Jahr arbeite ich als regelmäßiger Freelancer bei der „Portal München Betriebs-GmbH“ – oder besser bekannt einfach als „muenchen.de“, also dem offiziellen Münchner Stadtportal.

Nikolaus Gradl, den ich schon seit seiner Stadtratszeit kenne, hatte mich als einer der Projektleiter dort eingeladen und mit einem Projekt geködert, bei dem ich nach München Transparent wohl ein recht naheliegender Kandidat war: der Web-Umsetzung der Münchner Rathaus Umschau, einer werktäglich erscheinenden „Zeitschrift“ der Stadtverwaltung, die neben einer Printversion bisher nur im PDF-Format erschienen ist. Die Herausforderung dabei war, das so in den bisherigen Prozess der Rathaus Umschau zu integrieren, dass dieser erst einmal weit gehend unverändert weiter laufen kann und das PDF auch weiterhin die „Referenzfassung“ bleibt. In der Praxis heißt das, dass die Web-Version hauptsächlich durch ein automatisiertes Parsen des PDFs erstellt wird. Das PDF wird dabei in die einzelnen Meldungen, Terminhinweise, Anträge usw. zerlegt, analysiert und dann veröffentlicht. Das ist sicher nicht die eleganteste Lösung (PDFs wieder zurück in Text umzuwandeln ist leider nicht ganz so komplikationsfrei wie man annehmen könnte), aber hier erst einmal das zweckmäßigste.

Da die PHP-Anwendungen im muenchen.de-Umfeld (der Kern von muenchen.de selbst läuft nicht unter PHP) hauptsächlich auf Laravel basieren, war das außerdem einmal eine gute Gelegenheit, mich damit intensiver zu beschäftigen – sonst hatte ich ja hauptsächlich mit Yii und früher noch mit Zend gearbeitet. Mein persönlicher Favorit bleibt aber bis auf weiteres Yii2. 😀

Ansonsten geht es technisch recht bislang recht abwechslungsreich zu: ein automatischer Konverter von HTML nach AMP war dabei, mit München 360° die Web-Umsetzung einer VR-App auf Basis des Tools krpano, und aktuell ein Projekt, bei dem ich einmal mit Angular2 und Typescript auf Tuchfühlung gehen kann. Typescript finde ich sehr cool, da ich inzwischen ein recht großer Freund statischer Typisierung bin. Mit Angular 2… komme ich auch langsam zurecht, auch wenn ich das 1er darin eigentlich gar nicht mehr wiedererkenne. Wahrscheinlich wäre es sinnvoller, darin gleich ein komplett unabhängiges, neues Framework zu sehen, und weniger einen Nachfolger von Angular 1. Für größere Projekte sehe ich auf alle Fälle die Vorteile gegenüber dem 1er, auch wenn es um einiges komplizierter erscheint.

Bei der demnächst neu erschienen Version 2.1 von OpenSlides hatte ich die Gelegenheit, auch ein paar wichtigere neue Funktionen beizutragen: die Zeilennummerierung, das Inline-Bearbeiten von Anträgen sowie die Verwaltung von Änderungswünschen inkl. Änderungsansicht. Alles sind natürlich Funktionen, von der Art, mit der ich bei Antragsgrün bereits Erfahrung gesammelt habe, auch wenn sich die konkrete Implementierung schon allein deshalb maßgeblich unterscheidet, dass sie bei Antragsgrün hauptsächlich serverseitig in PHP implementiert, während OpenSlides hauptsächlich AngularJS-basiert (mit minimalem Python-Backend) ist. Das hat Vor- und Nachteile: grundsätzlich ist das Interface von OpenSlides dadurch natürlich deutlich responsiver. Gerade bei den aufwändigeren Algorithmen (Zeilennummern und Änderungsansichten sind komplizierter, als man anfangs oft meint) und bei längeren Texten stellt das aber auch höhere Ansprüche an die Leistungsfähigkeit des Client-Rechners, und mindestens an einer Stelle konnten wir aus diesem Grund auch nicht die beste Implementierung wählen.

Spannend war auch das Erzeugen des PDFs auf Basis der JavaScript-Bibliothek PDFMake. Es ist einerseits cool, dass es überhaupt funktioniert, PDFs rein clientseitig im Browser zu erzeugen – andererseits sind wir auch an einige problematische Einschränkungen gestoßen. Wobei der Antragsgrün-Ansatz, auf LaTeX bzw. XeTeX als Backend fürs PDF-Rendering zu setzen, auch nicht unproblematisch ist.

Ich bin auf alle Fälle gespannt, wie es sich weiter entwickelt – und wie sich das Zusammenspiel zwischen OpenSlides und Antragsgrün weiterentwickelt. Anders als einige andere sehe ich die zwei Tools ja auch immer noch als eher komplementär zueinander, und weniger als Konkurrenz. Auf alle Fälle wird ein weiteres Betätigungsfeld sein, die Schnittstellen zwischen den beiden Tools weiter zu verbessern.

Seit Ende Oktober bin ich nun selbstständig, und nach zwei Weiterentwicklungs-Sprints für Antragsgrün im Auftrag vom Grünen-Bundesverband einerseits und dem Deutschen Bundesjugendring andererseits bin ich nun im ersten größeren Projekt: bei der Seite pflege.de, die im hübschen Hamburg sitzt.

Moment, Hamburg?

Ja, die Situation ist tatsächlich: ich wohne weiterhin in München, arbeite unter der Woche aber in Hamburg. Mein erster Gedanke bei der Idee war, einmal die Woche mit dem Zug zwischen München und Hamburg pendeln geht gar nicht. Andererseits: vor wenigen Monaten bin ich erst über 15.000km mit dem Zug von München nach Saigon gefahren und habe das als erholsamen Urlaub empfunden, da können mich ein paar Stunden im ICE nun auch nicht mehr schocken.

Nach einer anfänglichen Überraschung – als PHP-/JavaScript-/HTML-Entwickler angeheuert, durfte ich stattdessen erst mal hauptsächlich auf Ruby on Rails, CoffeeScript und HAML programmieren – hab ich mich inzwischen recht gut eingelebt. Und das das eigentliche Projekt, für das ich ins Boot geholt wurde, hat nun auch den ersten großen Meilenstein erreicht: den Relaunch des Content-Management-Systems. Zum Glück auf PHP-Basis. 🙂

I moved one of the components of Antragsgrün into a separate library, as it might be useful for other projects: HTML2OpenDocument converts formatted HTML content to OpenDocument Text- and Spreadsheet-Files (ODT / ODS). It can handle basic formattings like bold, italic, underlined, strike-through, inserted and deleted text. Lists are supported in Text-Files. The library is licenced under the MIT licence and is available on GitHub and on Packagist / Composer.

Vor wenigen Tagen ging nach langer Vorbereitungszeit endlich die neue Website des Laimer Bezirksausschuss online:

Die lange Vorbereitungszeit lag dabei nicht an der eigentlichen Gestaltung – technisch ist die Seite eher trivial, wie man denke ich recht schnell sieht. Ungewohnt war für mich nur, einmal komplett ohne serverseitigen Skriptsprachen zu arbeiten und stattdessen nur auf statische HTML-Seiten zu setzen – aber dank Jekyll & co ist das ja inzwischen auch kein Problem mehr. Die rechtliche Klärung dauerte dafür aus nicht ganz nachvollziehbaren Gründen locker fünfmal so lang wie die eigentliche Programmierung. Na ja, Ende gut, alles gut – jetzt ist sie endlich da und alle sind glücklich. 🙂

One of the features most wished for in one of my Cordova-based android apps was to let the users choose another sound for push notifications, or to disable sound altogether (without having to mute the whole smart phone and still keeping vibration). The Push Plugin supports custom sounds, however all sound resources have to be embedded in the app. In my case, I wanted to let the users choose among the system sounds provided by Android itself, which apparently isn’t possible without some major changes to the plugin.

Here, I’m going to outline the changes necessary to integrate Android’s native RingtonePreference dialog into a Cordova-based app to let the users choose another notification sound. I’ve published the modified plugin that should work on android projects on Github.

Configuration Dialog

Choosing the preferences for push notifications is done in a native android PreferenceScreen that is opened from within the app using a new javascript-method on the pushNotification-Object. The configuration screen is defined by a xml file stored at platforms/android/res/xml/pushsettings.xml:

The referenced strings are stored in platforms/android/res/values/strings-gcm.xml:

    Notifications
    Light
    Light is switched on
    Light is switched off
    Vibration
    Vibration is switched on
    Vibration is switched off
    Sound
    Sound is switched on
    Sound is switched off
    Ring tone
    Choose a ring tone

Translated versions can be stored in files like platforms/android/res/values-de/strings-gcm.xml

Opening the dialog
First of all, a new activity has to be defined in the platforms/android/AndroidManifest.xml:

The Activity itself is pretty simple, just remember to replace the „CORDOVA_PACKAGE_ID“ by the id of your app (necessary to access the R.xml.pushsettings-resource):

package com.plugin.gcm;

import CORDOVA_PACKAGE_ID.R;
import android.os.Bundle;
import android.preference.PreferenceActivity;

public class PushSettingsActivity extends PreferenceActivity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        addPreferencesFromResource(R.xml.pushsettings);
    }
}

This activity is called from PushPlugin.java’s execute-method, something like:

if ('showPushSettings'.equals(action)) {
    Intent i = new Intent(this.cordova.getActivity(), PushSettingsActivity.class);
    this.cordova.getActivity().startActivityForResult(i, RESULT_PUSH_SETTINGS);
    callbackContext.success();
}

The JavaScript-method to call this in PushNotification.js is:

PushNotification.prototype.showPushSettings = function (successCallback, errorCallback) {
    if (errorCallback == null) {
        errorCallback = function () {}
    }
    if (successCallback == null) {
        successCallback = function () {}
    }

    if (typeof errorCallback != "function") {
        console.log("PushNotification.showPushSettings failure: failure parameter not a function");
        return;
    }

    if (typeof successCallback != "function") {
        console.log("PushNotification.showPushSettings failure: success callback parameter must be a function");
        return;
    }

    cordova.exec(successCallback, errorCallback, "PushPlugin", "showPushSettings", []);
};

With all these changes applied, a call to plugins.pushNotification.showPushSettings() should open the configuration dialog and let the user apply her desired notification sound. The settings are stored automatically in android’s SharedPreferences. In the source code of the plugin, I also added a getPushSettings()-method that returns the settings into JavaScript, if you ever need to query these settings.

Using the settings for the notification
The actual notification sound is triggered in GCMIntentService.java’s onMessage-method. The new code reads the settings from the SharedPreferences and acts accordingly:

SharedPreferences app_preferences = PreferenceManager.getDefaultSharedPreferences(this);
boolean vibration = app_preferences.getBoolean("com.plugin.gcm.vibration", true);
boolean sound = app_preferences.getBoolean("com.plugin.gcm.sound", true);
boolean light = app_preferences.getBoolean("com.plugin.gcm.light", true);
String ringtonePath = app_preferences.getString("com.plugin.gcm.ringtone", "defValue");
int defaults = 0;
if (vibration) defaults = defaults | Notification.DEFAULT_VIBRATE;
if (light) defaults = defaults | Notification.DEFAULT_LIGHTS;
		
NotificationCompat.Builder mBuilder =
    new NotificationCompat.Builder(context)
        .setDefaults(defaults)
        .setSmallIcon(context.getApplicationInfo().icon)
        .setWhen(System.currentTimeMillis())
        .setContentTitle(extras.getString("title"))
        .setTicker(extras.getString("title"))
        .setContentIntent(contentIntent)
        .setAutoCancel(true);

if (!ringtonePath.equals("") && sound) {
    Uri uri = Uri.parse(ringtonePath);
    Ringtone r = RingtoneManager.getRingtone(getApplicationContext(), uri);
    r.play();

    mBuilder.setSound(null);
}

I’m using the Ringtone.play() instead of the setSound()-method of NotificationCompat.Builder, as the latter one somehow didn’t actually change the sound, even with the URL of the sound provided. I haven’t yet figured out why, but there probably is a solution that’s more elegant than the one showed above.
That’s it. Have fun! 🙂