Mit der adb shell ist es einfach möglich das Handling von Intents zu testen … sehr praktisch, wenn man z.B. in der App normalerweise einen QR-Code-Scanner verwendet, um eine URL zu erhalten.
Das Kommando
adb shell am start -a android.intent.action.VIEW -d 'http://www.google.de'
öffnet z.B. den Browser.
This is the translation of this german blog entry.
Even if Linked Data has been around for a while a solid standard for a JSON driven environment is yet to surface. JSON-LD has set its course to becoming this standard and goes great length in explaining their take on linked data in JSON.
In JSON-LD JSON data is enriched with information about its context enabling the client to explicitly know how to interpret this data. A simple example of JSON-Data with embedded linking information looks like this.:
{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}This example describes a person named „John Lennon“. By adding a namespace via the @context attribute the data becomes self-describing. The @subject enables the client to identify an this specific entry.
It is also possible to describe subsidiary entries of this object which could be given e.g. in a list.
This is good but not sufficient for my use case.
By following this design I have to include all related objects in the JSON messages. But I want to let the client decide which subsidiary objects he needs. What I really need is the possibility to define relations. In his blog entry „Linking in JSON“ Mark Nottingham shows that this need is not addressed properly or at all. JSON Reference and HAL do provide solutions but they are both lacking a way to define the context of the related objects. Only by knowing the context of a relation the client can decide which relation to follow and which to discard.
In my applictaion I’ve decided to stick with the JSON-LD syntax and add another property: @relations. This property is a list of relations for the object. Every relations describes the context of the related object in relatedcontext and states under which URL (href) this object can be fetched. The role attribute defines the kind of relation. Optionally the attribute list states, if the relation is actually a list of objects.
In this example we use John again and define a relation to his wife Yoko Ono and to the singles he has written.
{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"@relations": [
{
"@context": "http://coderbyheart.de/jsonld/Relation",
"relatedcontext": "http://purl.org/jsonld/Person",
"role": "http://gmpg.org/xfn/11#spouse",
"href": "http://dbpedia.org/page/Yoko_Ono"
},
{
"@context": "http://coderbyheart.de/jsonld/Relation",
"relatedcontext": "http://dbpedia.org/ontology/Single",
"role": "http://dbpedia.org/ontology/writer",
"href": "http://dbpedia.org/resource/John_Lennon/singles/",
"list": True,
}
],
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}In this way the client can be told that if he follows the (fictive) link http://dbpedia.org/resource/John_Lennon/singles/ he’ll receive a list of Singles written by John. It’s up to the client to decide a person object exists in his application with a relation to singles.
The solution presented above enables us to transfer just the minimum amount of required data but still gives the client the possibility to discover and fetch related objects.
An englisch translation of this article can be found here.
Das Thema Linked Data geistert ja nun schon eine Weile durch die Branche, noch hat sich besonders im JSON-Umfeld noch kein wirklicher Standard etabliert. JSON-LD versucht dieser Standard zu werden und hat auch schon sehr ausführlich dessen Syntax beschrieben.
In JSON-LD werden JSON-Daten mit Informationen zum Kontext angereichert, so dass der Verwender der Daten erkennen kann, wie diese zu interpretieren sind. Ein einfaches Beispiel eines JSON-Datensatzes mit Linked Data-Zusatzinformationen sieht so aus:
{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}Diese Beispiel beschreibt einer Person, deren Name „John Lennon“ ist. Der Unterschied zu normalem JSON und JSON-LD ist der, dass dieses Objekt sich eindeutig selbst beschreibt und so ohne Mehrdeutigkeit in jeder Anwendung verwendet werden kann, die mit @context ein eindeutiger „Namesraum“ angegeben wird, der die Bedeutung der Daten beschreibt. Mit @subject ist es dann möglich den konkreten Datensatz eindeutig zu identifizieren.
Die Informationsanreicherung für untergeordnete Elemente, die z.B. als Liste vorliegen ist mit JSON-LD ebenfalls möglich.
Soweit, so gut — aber eben für meinen Anwendungsfall nicht ausreichend: Ich möchte nicht bei jeder Nachricht alle zugehörigen Objekte mitliefern, sondern den Client selber entscheiden lassen, was er benötigt.
Die Spezifiktion geht davon aus, dass eine JSON-Nachricht immer die zu einem Objekt gehörenden Kind-Elemente enthält. Sie sieht aber nicht die Möglichkeit vor, Verweise zu weiteren Datensätzen zu definieren. Mark Nottingham zeigt in seinem Blog-Eintrag „Linking in JSON“, dass dieses Problem auch in anderen Linked-Data-Ansätzen nicht zufriedenstellend gelöst wird, auch wenn es mit JSON Reference und HAL mindestens zwei Ansätze gibt, fehlt beiden jedoch die Möglichkeit den Kontext der verknüpften Daten zu definieren, denn Anhand des Kontexts einer Relation kann der Verwendern erkennen und entscheiden, ob es für ihn Sinn macht, eine Relation weiter zu verfolgen.
In meiner Anwendung habe ich mich entschieden in der Syntax von JSON-LD zu bleiben und ein weiteres Element ein zu führen: @relations. Dieses Element ist eine Liste von Relation die zum jeweiligen Objekt gehören. Jede Relation beschreibt dabei mit relatedcontext, welchen Kontext das andere Objekt hat und unter welcher URL (href) dieses Objekt abgerufen werden kann; mit role wird die Art der Beziehung beschrieben. Optional gibt das Attribut list an, ob es sich um eine Liste von Objekten handelt.
Im Beispiel verwenden wir wieder John und definieren eine Relation zu seiner Frau Yoko Ono, sowie zu den Singles, die er geschrieben hat.
{
"@context": "http://purl.org/jsonld/Person",
"@subject": "http://dbpedia.org/resource/John_Lennon",
"@relations": [
{
"@context": "http://coderbyheart.de/jsonld/Relation",
"relatedcontext": "http://purl.org/jsonld/Person",
"role": "http://gmpg.org/xfn/11#spouse",
"href": "http://dbpedia.org/page/Yoko_Ono"
},
{
"@context": "http://coderbyheart.de/jsonld/Relation",
"relatedcontext": "http://dbpedia.org/ontology/Single",
"role": "http://dbpedia.org/ontology/writer",
"href": "http://dbpedia.org/resource/John_Lennon/singles/",
"list": True,
}
],
"name": "John Lennon",
"birthday": "10-09",
"member": "http://dbpedia.org/resource/The_Beatles"
}Dem Verwender kann so mitgeteilt werden, dass wenn er dem (fiktiven) Link http://dbpedia.org/resource/John_Lennon/singles/ folgt, er eine Liste von Singles erhält, die John geschrieben hat. Es bleibt aber Sache des Verwenders zu entscheiden, ob er in seiner Anwendung überhaupt ein Personen-Objekt definiert hat, dass Verweise auf Singles enthält.
Der gezeigte Lösungsansatz ermöglicht es, die Menge der übertragenen Daten in einer JSON-Nachricht gering zu halten, gleichzeitig bleibt aber die Möglichkeit bestehen, zugehörige Objekte erkennen und nachladen zu können.
Über die Feiertage habe ich Auslastung um einige Funktionen erweitert.
Die wichtigsten Änderungen im Überlick:
Die Liste aller Änderungen findet sich in der Timeline.
Eine vollwertige Test-Version der Anwendung findet sich unter http://auslastung.coderbyheart.de/.
Screenshots? Gerne.
Meinen Freunden, Kunden und Kollegen wünsche ich viel Erfolg im Jahr 2012!
Damit der Januar nicht genau so stressig beginnt, wie der Dezember geendet hat, gibt es als kleines Geschenk für deinen Desktop ein (hoffentlich) entspannenden Desktop-Hintergrund:
Für jede Auflösung gibt es ein speziell angepasste Version:
