Jetzt, da ich ein Gerät für Multitouch habe, muss ich natürlich auch ein wenig mit den API spielen. Und natürlich muss es unglaublich toll sein. Das sind die Gedanken, die jeder hat, wenn er mit dem Thema startet. Was kann man also machen? Skalierende und rotierende Bilder… alter Hut. Also wo fängt man an?

Ich weiß nicht, was anderen dazu einfallen würde. Ich habe mich erst mal um meine Webseite gekümmert und ein kleines aber in meinen Augen wichtiges Feature eingebaut. Ja, ich weiß, sie macht Augenkrebs. Aber das ist nicht der Punkt. Eine der ersten Sachen, die mir aufgefallen sind, ist die Tatsache, dass Flicks über ActiveX nicht funktioniert. Wer Flicks nicht kennt, lese bitte hier.

Wer sich meine Website einmal genauer angesehen hat, dem ist sicher aufgefallen, dass sie Deep Linkinging unterstützt. Das Ganze wird mit Hilfe des NavigationFrameworks von Silverlight realisiert. Ziel meiner ersten Schritte mit der Silverlight Touch API war es, Back und Forward Flicks zu ermöglichen. Meine User sollen die Möglichkeit haben, meine Seite wieder zu verlassen. Bis jetzt ging das auf Touch-Geräten nur durch klick der Buttons in der Browserleiste. Jetzt geht es auch mit Flicks. Leider nicht so schön, wie im Browser selbst, aber der erste Schritt ist gemacht.

Was ist besonders daran? Das Navigation Framework hat doch eine History. Und die kann doch schon GoBack() und GoForward()!

Ja, das gibt es. Das Problem dabei ist die Tatsache, dass nicht in der echten Browser-History zurück gesprungen wird, sondern ein neuer Eintrag generiert wird und in die Browser-History hinzu gefügt wird. Der Grund dafür ist laut eines Microsoft Mitarbeiters folgender.

“You’re correct that GoBack() creates a new journal entry rather than having the browser actually go back – this was an intentional design choice for two reasons.

1) If you call GoBack() too many times, we didn’t want to make it step off your Silverlight application – since you have no good way to know how many times it’s possible to call GoBack() before leaving the HTML page, we felt this prevented the app from accidentally making it too easy for the user to leave the application (and thus maybe lose in-progress data, for example).

2) If we ever make the Navigation framework integrate with other history-management frameworks (like ASP.NET AJAX HistoryManager, Yahoo!’s library, etc…) then GoBack() must create a new journal entry to remain consistent.  Consider this case:

a) User comes to a page where two history management frameworks are playing nicely together and sharing the URI fragment.

b) Eventually, you end up in this sequence :

#SLNavigation={whatever}&AJAXNavigation={abc}
#SLNavigation={whatever}&AJAXNavigation={def}

Now, if GoBack() just went back in the browser, it would actually navigate the AJAX controls back – instead of the Silverlight content, which is obviously not intended.

To be consistent in this future world (no promises that we will ever do this), we wanted the behavior of GoBack() to be defined clearly from the start to just go back within Silverlight – NOT within the browser.  If you really want to go back in the browser, it is possible to call out to JavaScript and call “history.goBack(-1)” via the DOM bridge.”

Ok, wenn ihr meint. Persönlich bin ich eher der Meinung man sollte beim Default Verhalten bleiben und wenn man es anders haben will, die Möglichkeit haben einzugreifen, aber sei es drum.

Auf meiner Website funktioniert es jetzt.