Annäherungsalarm..?

[ViTho]

OK, dank der Hinweise hab ich jetzt mal zwei patch-Dateien erstellt: Eine mit Eclipse und eine zweite mit Tortoise-SVN. Ich hoffe, dass es funktioniert hat... Vielleicht hat ja jemand Zeit und Lust das Ganze zu testen.

 

[ViTho]

Vielleicht sollte ich noch erwähnen, das sich die abzuspielende wav-Datei im Stammverzeichnis des Cachewolf liegen muss. Da müsst ihr euch was pasendes raussuchen. Ich hab einfach mal den Connect-Sound von Active Sync genommen, der hört sich ganz vernünftig an...

 

[Wutschkow]

Habe den Patch gerade mal eingespielt und getestet (allerdings nur am Schreibtisch).
Klappt soweit, wie es soll. In der Kartenansicht habe ich es nicht getestet (dazu hätte ich mich ja bewegen müssen ).

ToDo (auf die Gefahr hin, das Offensichtliche anzumerken):

Es müsste natürlich erst getestet werden, ob überhaupt eine "sound.wav" vorhanden ist. Bei der Gelegenheit vielleicht noch einen eindeutigeren Namen verwenden, z. B. "alarm.wav" oder so. Eventuell überprüft man das nur einmal beim Cachewolf-Start, das spart dann später Zeit und Dateizugriffe.

Bei allen GUI-Geschichten sollte konsequenterweise mit MyLocale gearbeitet werden, denke ich. Sonst wird es vermutlich nie eingecheckt.

Ich würde vielleicht das eigentliche Abspielen der Sounddatei noch in eine eigene Funktion auslagern. In der könnte man dann Fallunterscheidungen machen:
Wenn Windows-Plattform und sound.wav vorhanden -> sound.wav abspielen
(Vm.getPlatform().equals("WinCE")) || (Vm.getPlatform().equals("Win32"))
Wenn Java-Plattform oder keine sound.wav -> Beep

Dann wäre die Fallback-Lösung auch erledigt.

 

[ViTho]

Danke für die Anregungen! Ich hab schon angefangen mich zu langweilen...
Den Test auf die Art der VM wollte ich sowieso noch einbauen, hatte nur die richtige Methode noch nicht parat. Danke für die Hilfe. Die Abfrage nach der vorhanden wav-Datei ist ne gute Idee, bin ich garnicht drauf gekommen. Den Tipp mit MyLocale kann ich noch nicht ganz nachvollziehen, bin wohl nich nicht tief genug ins Projekt eingestiegen. Man muss sich ja erst mal durch die ganzen Klassen arbeiten :schockiert: Nähere Hinweise dazu nehm ich gerne entgegen!

 

[Wutschkow]

MyLocale:
Alle GUI-Texte werden nicht hart in den Code geschrieben, sondern über MyLocale und die Sprachdateien eingebunden. So kann man leichter verschiedene Sprachversionen machen.
Also statt des Textes "Annäherungsalarm" schreibst Du
MyLocale.getMsg(XYZ, "Approach notification")

XYZ ist dabei die Nummer, unter der Du den gewünschten Text in den Sprachdateien vermerkt hast (die findest Du im Ordner "languages"). DE und EN reichen, denke ich, wenn Du nicht geraden NL und FR kannst. Der Text in Anführungszeichen dahinter ist ein Fallback-Text, der verwendet wird, wenn unter der Nummer nichts gefunden wird bzw. wenn die Sprachdateien komplett fehlen. Der sollte standardmäßig in Englisch sein.

Soweit habe ich es zumindest im Kopf.

 

[ViTho]

MyLocale:
Alle GUI-Texte werden nicht hart in den Code geschrieben, sondern über MyLocale und die Sprachdateien eingebunden. So kann man leichter verschiedene Sprachversionen machen.
Also statt des Textes "Annäherungsalarm" schreibst Du
MyLocale.getMsg(XYZ, "Approach notification")

XYZ ist dabei die Nummer, unter der Du den gewünschten Text in den Sprachdateien vermerkt hast (die findest Du im Ordner "languages"). DE und EN reichen, denke ich, wenn Du nicht geraden NL und FR kannst. Der Text in Anführungszeichen dahinter ist ein Fallback-Text, der verwendet wird, wenn unter der Nummer nichts gefunden wird bzw. wenn die Sprachdateien komplett fehlen. Der sollte standardmäßig in Englisch sein.

Soweit habe ich es zumindest im Kopf.

Ok, das war das... Das wollte ich auch noch machen (steht glaub ich auch als TODO irgendwo im Code). Das kleine Problem dabei ist, dass die zu verwendeten Nummern ja eindeutig sein sollten. Wenn ich also jetzt an die Sprach-Datei einfach meine Zahlen anhänge und einer der anderen Entwickler die gleichen Zahlen für andere Strings nutz, dann gibt's Probleme. Gibt's da eine interne Übereinkunft?

 

[pfeffer]

ja, es gibt eine Übereinkunft:
Am Beginn jeder Java-Datei sollte in einem Kommentar stehen, welches Offset für die Sprach-Datei für diese Klasse verwendet werden soll.

Gruß,
Pfeffer.

 

[MiK]

Eigentlich sollte jede Klasse ihren eigenen Zahlenbereich haben. Der Start steht dann am Anfang der Datei in einem Kommentar z.B. "Class ID: 1500". Das wurde aber nicht immer konsequent durchgesetzt.

In welche Klasse soll es denn rein? Schau dann einfach mal, welche ID die anderen Strings in der Klasse haben und füge die neuen am Ende dieses Bereichs an.

 

[greiol]

ja, es gibt eine Übereinkunft:
Am Beginn jeder Java-Datei sollte in einem Kommentar stehen, welches Offset für die Sprach-Datei für diese Klasse verwendet werden soll.

an welcher stelle der doku habe ich das überlesen?

 

[pfeffer]

welche Entwickler-Doku?

Es wäre vielleicht in der Tat ganz gut, mal ein paar Punkte für neue Entwickler aufzuschreiben.

Gruß,
Pfeffer.

 

[ViTho]

Alles klar! Danke für die prompte Antwort... Werd' mich die Tage mal an die Arbeit machen.

 

[Engywuck]

Eigentlich sollte jede Klasse ihren eigenen Zahlenbereich haben. Der Start steht dann am Anfang der Datei in einem Kommentar z.B. "Class ID: 1500".

Ups, davon hör ich jetzt zum ersten Mal... ps:

Das wurde aber nicht immer konsequent durchgesetzt.

feif:

Gruß,
E.

 

[ViTho]

So, ich hab die Sache mal ein bißchen weitergetrieben. Ist noch nicht ausgiebig getestet. Wer möchte, kann sich das ganze mal angucken. Die zip-Datei enthält wieder zwei patch-Dateien und zusätzlich noch das angepasste Sprachfile, sowie die sound-Datei, die im CW-Verzeichnis liegen muss.

 

[Wutschkow]

Ich habe den Patch nicht eingespielt. Es wäre hilfreich, wenn Du vor dem Erstellen eines Patches die Source-Dateien jeweils vom SVN aktualisierst. Dein Patch ist für Rev 2042, das SVN ist inzwischen bei Rev 2069. Das macht das Patchen schwieriger, weil Eclipse die Änderungen teilweise nicht mehr automatisch zuordnen kann und man dann manuell nachhelfen muss.

Ich habe jetzt also nur so in den Patch reingeschaut. Wenn ich das richtig sehe, gibt es jetzt unter Win32 und WinCE eine Fehlermeldung, wenn keine sound.wav gefunden wird. Ich fürchte, das sorgt für unnötige Komplikationen. Wäre es nicht einfacher, auch in diesem Fall einfach den Beep auszugeben, der ja in jedem Fall funktioniert?

Ich versuche nur, das aus der Perspektive des unbedarften Benutzers zu sehen. Der entdeckt diese Funktion im Menü, schaltet sie ein und kriegt dann erstmal eine Fehlermeldung vor den Latz geknallt. Da fände ich es besser, er bekommt zumindest den Beep. Das und wie ein anderer Klang möglich wäre, kann er dann im Manual/Wiki/Forum oder wie auch immer erfahren.

 

[MiK]

Funktional stimme ich Dir da zu. Allerdings sollten wir dann auch direkt eine sound-Datei beilegen, wenn wir diese Funktion einbringen.

 

[ViTho]

Danke für die Rückmeldungen. Ich denke auch, wenn man die Funktion einbaut, dann sollte man die Sound-Datei direkt mitliefern. Wem der Klang dann nicht gefällt, der kann die Datei ja auswechseln. Daher finde ich auch die Fehlermeldung bei nicht vorhandener Sound-Datei sinnvoll. Wenn sonst nur der Fallback auf den beep läuft, dann fällt dem Anwender evtl. garnicht auf, dass da was falsch läuft.
Ich habe die Funktion playSound(...) auch so geschrieben, dass als Übergabeparameter der Dateiname angenommen wird und so im Prinzip auch andere Soundausgaben möglich wären (falls sowas jemals notwendig wird...) Auch dann wäre eine Rückmeldung bei nicht vorhandener Datei m.E. sinnvoll.
Ich hab am Ende mal die patches zur aktuellen Revision dazugepackt... ps:

 

[Wutschkow]

Ich habe gestern mal den Annäherungsalarm im Feld testen können. Funktioniert alles prima.

Nur eines habe ich bemerkt und das hat jetzt auch gar nichts mit der konkreten Implementierung zu tun, dass wäre bei meinem Schnellschuss genauso passiert:

An einer Station habe ich mein Smartphone auf den Boden neben einem Baum gelegt, um die Hände zum Suchen freizuhaben. Der Empfang war da ohnehin schon nicht besonders doll. Mit dem Gerät am Boden war es dann wohl ganz vorbei. Jedenfalls schrillte während meiner Suche mehrmals der Alarm fröhlich durch den Wald, obwohl sich das Gerät keinen Zentimeter bewegt hat.
Ich denke, das kann man kaum sinnvoll vermeiden, wenn der Empfang abschmiert, kann es schon mal kurzfristig 100 Meter und mehr daneben gehen, das ist klar.
Ich habe nur gedacht, ob man das "Wiederscharfschalten" nach einem Abspielen des Alarms nicht doch besser an das Festlegen eines neues Ziels knüpft. Ich habe jetzt noch nicht in den Code geschaut, aber ich denke, da wird es eine zentrale Funktion geben, in die man das reinsetzen kann.
Wäre vielleicht eine noch etwas sauberere Lösung: Der Alarm wird durch das Setzen eines neuen Ziels scharf geschaltet und nach einmaligen Alarmieren bleibt er aus, bis man auf die eine oder andere Weise ein neues Ziel gewählt hat.
Hat nur einen Nachteil: Wenn man so schlau ist, ein neues Ziel zu wählen, dass weniger als die eingestellte Annäherungsgrenze entfernt ist, dann geht der Alarm sofort los.

 

[ViTho]

An einer Station habe ich mein Smartphone auf den Boden neben einem Baum gelegt, um die Hände zum Suchen freizuhaben. Der Empfang war da ohnehin schon nicht besonders doll. Mit dem Gerät am Boden war es dann wohl ganz vorbei. Jedenfalls schrillte während meiner Suche mehrmals der Alarm fröhlich durch den Wald, obwohl sich das Gerät keinen Zentimeter bewegt hat.
Ich denke, das kann man kaum sinnvoll vermeiden, wenn der Empfang abschmiert, kann es schon mal kurzfristig 100 Meter und mehr daneben gehen, das ist klar.

Ja, das störte mich auch noch ein wenig. Ist mir beim Testen zuhause auch mehrmals so ergangen.

Ich habe nur gedacht, ob man das "Wiederscharfschalten" nach einem Abspielen des Alarms nicht doch besser an das Festlegen eines neues Ziels knüpft. Ich habe jetzt noch nicht in den Code geschaut, aber ich denke, da wird es eine zentrale Funktion geben, in die man das reinsetzen kann.
Wäre vielleicht eine noch etwas sauberere Lösung: Der Alarm wird durch das Setzen eines neuen Ziels scharf geschaltet und nach einmaligen Alarmieren bleibt er aus, bis man auf die eine oder andere Weise ein neues Ziel gewählt hat.

Das wäre eine Idee. Muss ich mir mal im Code anschauen, wie man sowas am besten lösen könnte

Hat nur einen Nachteil: Wenn man so schlau ist, ein neues Ziel zu wählen, dass weniger als die eingestellte Annäherungsgrenze entfernt ist, dann geht der Alarm sofort los.

Das ist im Moment auch schon so. Dann weiß man wenigstens, dass man schon in der Nähe ist ...

 

[Wutschkow]

Das ist im Moment auch schon so. Dann weiß man wenigstens, dass man schon in der Nähe ist ...

Sollte aber eigentlich nicht so sein, oder?

if (dist < alertDistance){
			lowDistance = true;
		}
		else{
			lowDistance = false;
			if (dist > (alertDistance + 0.02)){
				soundPlayed = false;
			}

Demzufolge wird soundPlayed doch erst wieder auf False gesetzt, wenn man vom gesetzten Ziel mindestens alertDistance+20 Meter entfernt ist. Von daher kann das eigentlich nicht passieren, dass beim Setzen eines neuen Ziels direkt der Alarm losgeht.
Na gut, es sei denn, man setzt ein neues Ziel, bevor man das vorherige erreicht hatte. Ist ja aber eher untypisch.

Vielleicht arbeitet man mit zwei Kontrollvariablen:
newTarget wird beim Festlegen eines Ziels auf True gesetzt, beim Abspielen des Alarms auf False.
rearmDistance wird auf True gesetzt, wenn man mehr als alertDistance+20 Meter vom gesetzten Ziel entfernt ist, beim Abspielen des Alarms auf False.
Nur wenn NewTarget && rearmDistance dann soundPlayed = false

So deckt man fast alles ab. Wenn dann noch beim Festlegen eines neuen Ziels soundPlayed erstmal auf True gesetzt wird, hat man alles abgedeckt. Dann geht der Alarm auch bei Entfernungen < alertDistance nicht los ... hoffe ich.

 

[ViTho]

OK, ist doch etwas anders, als ich zuerst dachte: Nur wenn man beim ersten Mal nach Programmstart einen Punkt unterhalb des Grenzwertes auswählt, dann gibt's direkt einen Alarm, sonst wohl nicht...

Den Rest schau ich mir demnächst mal an.