[dev] Umbenennen von Wegpunkten

UncleOwen · 29 Juli 2009

Mein Eclipse behauptet, dass CacheHolder.rename() an keiner Stelle im Code aufgerufen wird. Stimmt das? Wenn ja: Wie kommts? Alter Code? Bug?

Ein kurzer Test ergab, dass anscheinend wirklich keine Dateien umbenannt werden: Die xml-Datei hatte ich nach dem umbenennen doppelt, die Bilder hatten alle noch den alten Dateinamen. Angezeigt wurden sie aber trotzdem noch.

MiK · 29 Juli 2009

Ein kurzer Blick auf den SVN-Blame zeigt mir, dass das erst am 21. von greiol eingefügt wurde. Das ist wohl work in progress.

UncleOwen · 29 Juli 2009

ah, ok.

greiol · 29 Juli 2009

die funktion ist noch nicht eingebunden. im moment arbeite ich mich von verschiedenen seiten an die eine oder andere ungereimtheit im details panel heran.

so ist die frage ob du noch bilder nach dem umbenennen hast derzeit nur in abhängigkeit von der verwendeten version, dem gerät und dem was du zwischendurch noch so tust zu beantworten. manchmal hat man die details (und damit die bilder), manchmal nicht. und spätestens mit dem verschieben in ein anderes profil sind die bilder weg, da sie nicht in das wegpunkt*.* schema passen.

da das handling von events und änderungen im detailspanel jedoch deutliche spuren der entwicklung über die zeit zeigt, wird die vollständige entwirrung noch ein paar tage dauern.

greiol · 29 Juli 2009

und wo ich da gerade so spiele, ist mir noch etwas "lustiges" aufgefallen:

1. erstelle ein leeres profil
2. erstelle einen custom waypoint (verwalten/neuer wegpunkt)
3. ändere den typ in addi: final
4. wechsel in die listenansicht
5. wo ist der wegpunkt?
6. versuche einen neuen wegpunkt zu erstellen (verwalten/neuer wegpunkt)
7. anwendung / speichern
8. anwendung / beenden

bug 5. hatte auch die 1839 (älteste version die ich noch auf der platte habe) schon. die ab 6. sind neueren datums.

greiol · 29 Juli 2009

5. hat auch die 1947 also scheint er schon sehr alt zu sein.

dann check ich mal meine letzen änderungen ein und dann kann man in ruhe nach den exceptions 6ff suchen.

für den rest gilt: erst mal keine addis erzeugen die keinen parent haben

greiol · 31 Juli 2009

puh, also das zusammenspiel von detailspanel, profil, cachedb und cache ist ganz schon verwirrend

TweetyHH · 1 Aug. 2009

greiol schrieb:
puh, also das zusammenspiel von detailspanel, profil, cachedb und cache ist ganz schon verwirrend

Da UncleOwen und ich momentan auch ziemlich am Refactorn sind kann ich das bestätigen

Viel Glück noch bei der Suche.

pfeffer · 1 Aug. 2009

Ich hoffe, Ihr bekommt es so hin, dass es hinterher schön übersichtlich ist

Beste Grüße,
Pfeffer.

EDIT: Und ja, es stimmt: Cachewolf wurde erstmal irgendwie zusammengebastelt, damit Grundfunktionen klappen. Dann wurde so weiter gebastelt, dass wir die wichtigsten Bugs gefixt haben, aber an der verwurstelten Struktur nix mehr geändert haben, weil wir ein Release wollten. Nun ist die Zeit aufzuräumen ;-) und ich finde super, dass Ihr das macht!

TweetyHH · 1 Aug. 2009

Na, da Wünsch ich euch dann viel Spaß beim Rückportieren von der Java API zur Ewe API. Genauso bei Features wie Enums oder Generics ;-)

Alles in allem ist das doch 'ne ziemliche Arbeit das alles aufzuräumen ... 3 Kreuze wenn das Gröbste geschafft ist ;-)

P.S. Die blöden Zahlen bei der i18n bereiten mir noch immer erhebliche Kopfschmerzen ;-)

pfeffer · 1 Aug. 2009

nö, nix rückportieren. Greiol macht es doch grad für Cachewolf.
Vielleicht wäre es nicht schlecht, wenn Ihr mal über Konzepte dabei miteinander sprecht ;-)

Gruß,
Pfeffer.

greiol · 1 Aug. 2009

TweetyHH schrieb:
Na, da Wünsch ich euch dann viel Spaß beim Rückportieren von der Java API zur Ewe API. Genauso bei Features wie Enums oder Generics ;-)

ich verstehe im moment nicht so ganz wovon du redest, aber es freut mich, dass ihr euch darum bemüht mit eurem fork kompatibel zum cachewolf zu bleiben, denn für den mobilen teil könnt ihr mit all euren tollen enums und generics ja leider keine alternative bieten. also was soll dieses unreflektierte rumgetrolle?

TweetyHH schrieb:
Alles in allem ist das doch 'ne ziemliche Arbeit das alles aufzuräumen ... 3 Kreuze wenn das Gröbste geschafft ist ;-)

ihr dürft es hinterher gerne übernehmen. es bleibt am ende doch bei der alten regel: man kann in jeder sprache schlechten code schreiben.

TweetyHH schrieb:
P.S. Die blöden Zahlen bei der i18n bereiten mir noch immer erhebliche Kopfschmerzen ;-)

was? bei einer aktuellen java version? kann doch gar nicht sein!

pfeffer schrieb:
nö, nix rückportieren. Greiol macht es doch grad für Cachewolf.

ähm, was mach ich gerade?

pfeffer · 1 Aug. 2009

ich dachte, Du würdest das Detailspanel renovieren?

Gruß,
Pfeffer.

greiol · 1 Aug. 2009

pfeffer schrieb:
ich dachte, Du würdest das Detailspanel renovieren?

ja, aber ich wollte nur das panel renovieren und nicht den halben wolf

ich hab zwar inzwischen eine idee wie wir das sauber mit den wegpunkten hinbekommen, aber dafür muss ich in verdammt viele stellen reingreifen. packe ich das ganze in einen branch, habe ich einen horromerge vor mir falls jemand am hauptzweig arbeitet und arbeite ich am hauptzweig haben wir evtl. zwischendurch auch mal einen NB der die ganze cachedb auffrisst (oder im besten fall einfach nicht funktioniert). beide alternativen erscheinen mir derzeit noch wenig attraktiv.

und dann ist da noch das alte problem, dass eine robuste implementierung leider nicht unbedingt schneller wird.

TweetyHH · 1 Aug. 2009

Nee, ich wollte nicht rumtrollen, ich dachte Pfeffer meinte, dass wir ja aufräumen, und das kann dann ja übernommen werden.

Wir werden wohl erstmal beim Format für die Datenbanken bleiben, damit erübrigt sich dann auch ein Exporter für den CacheWolf ;-)

Ihr habt ja häufig versucht XML zu schreiben. Das ist ja sehr löblich, leider geht ihr beim Parsen teilweise sehr nach dem Motto vor: "Ich weiß ja, was als nächstes kommen muss". Das erschwert es leider, hier Erweiterungen unterzubringen, ohne das eure Parser aussteigen (in einem Fall (beim Log) hatte ich das bisher beobachtet).

Ansonsten probieren wir momentan eher auf saubere Architektur denn auf Performance zu achten. Auf einem PC spielt Speicher oder CPU ja nicht so die Rolle wie auf einem Mobilen Gerät. Wir werden auch den Support für ältere Profile oder ähnliches raus kegeln, da ich denke, dass das wenig Sinn macht diesen mit zu führen. Ich weiß nicht, in wie fern die Größe des Codes auf einem PDA eine Rolle spielt. Von daher solltet ihr das vielleicht auch überlegen und wenn es dann doch mal soweit ist einen externes Konvertierungsskript an zuwerfen.

Doch einmal muss ich noch trollen:

greiol schrieb:
es bleibt am ende doch bei der alten regel: man kann in jeder sprache schlechten code schreiben.

Davon bin ich jetzt auch Überzeugt ;-)

MiK · 2 Aug. 2009

Ist das jetzt die Art, wie die beiden Projekte laufen sollen? Klare Abgrenzung in "wir" und "ihr"? Und Anfeindungen, wie schlecht doch der Code der anderen ist? "Ihr" macht es Euch einfach, indem ihr auf alle Möglichkeiten von Java zurück greift? Schön und gut. Aber dann akzeptiert auch, dass unter EWE und mobil einige Sachen eben mehr auf Performance als auf sauberes Design getrimmt sind. Wenn ihr das besser könnt, dürft ihr es gerne im CW-Code beweisen. Aber dieses Rumgemecker am Design des CW-Codes ohne es selbst mindestens genauso schnell auf den gleichen Plattformen hinzubekommen, geht mir auf den S...

pfeffer · 2 Aug. 2009

greiol schrieb:
pfeffer schrieb:

ich dachte, Du würdest das Detailspanel renovieren?

Zum Vergrößern anklicken....

ja, aber ich wollte nur das panel renovieren und nicht den halben wolf

ich hab zwar inzwischen eine idee wie wir das sauber mit den wegpunkten hinbekommen, aber dafür muss ich in verdammt viele stellen reingreifen. packe ich das ganze in einen branch, habe ich einen horromerge vor mir falls jemand am hauptzweig arbeitet und arbeite ich am hauptzweig haben wir evtl. zwischendurch auch mal einen NB der die ganze cachedb auffrisst (oder im besten fall einfach nicht funktioniert). beide alternativen erscheinen mir derzeit noch wenig attraktiv.

Also, wenn Du denkst und die anderen Entwickler einverstanden sind, dann würde ich vorschlagen, darfst Du für ne Weile alleine am CW entwickeln (Du würdest sozusagen ein Lock auf trunk kriegen).

greiol schrieb:
und dann ist da noch das alte problem, dass eine robuste implementierung leider nicht unbedingt schneller wird.

Das ist in der Tat ein Problem. Da sollten wir vorher drüber sprechen. Einige Entwickler hier haben dazu schon Experimente durchgeführt, was in Ewe besonders langsam ist.

Hast Du bestimmte Sachen in Kopf, die Du "sauber" anders machen würdest, aber Performance-Verlust befürchtest?

Die Sache, die TweetyHH angesprochen hat, dass wir nicht XML-konform einlesen, z.B. hat Performance gründe. Hatten wir früher konform(er), haben wir aus Performance-Gründen leider beseitigen müssen.

Gruß,
Pfeffer.

Engywuck · 2 Aug. 2009

pfeffer schrieb:
Also, wenn Du denkst und die anderen Entwickler einverstanden sind, dann würde ich vorschlagen, darfst Du für ne Weile alleine am CW entwickeln (Du würdest sozusagen ein Lock auf trunk kriegen).

Das Lock wäre ja nur dann nötig, wenn er seine Arbeiten still nebenher in einem Branch machen will. Dies wiederum ist nur deshalb nötig, weil er keine nicht-lauffähigen Baustellen im trunk zurücklassen will. Dies wiederum will er nur deshalb nicht, damit keine nicht-lauffähigen NBs entstehen.
Einfache Lösung also: Das Erstellen der NBs so lange abschalten, bis diese Arbeiten beendet sind.

Gruß,
E.

greiol · 2 Aug. 2009

ich muss mir das mal in ruhe ansehen (aber wir bekommen besuch und sollten mit den zum teil alten bugs noch ein paar tage leben). potential für optimieren scheint vorhanden.

ich hab die cachedb mal mit ein paar debug statements versehen und das passiert dort wenn man einen neuen wegpunkt anlegt und direkt wieder zur liste zurückkehrt:

CacheDB getting index position of wpt
checking CacheDB size
CacheDB adding waypoint CW0000
CacheDB getting index position for ch CW0000
CacheDB getting index position of wpt CW0000
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
checking CacheDB size
CacheDB getting cacheholder from index position 0
ChacheDB rebuild
CacheDB getting index position of wpt CW0000
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
CacheDB getting cacheholder from index position 0
checking CacheDB size
CacheDB getting cacheholder from index position 0
checking CacheDB size
checking CacheDB size
CacheDB getting cacheholder from index position 0
checking CacheDB size
checking CacheDB size
CacheDB getting cacheholder from index position 0
checking CacheDB size

da ist auf alle fälle potential

macht erst mal normal weiter. ich melde ich wenn ich eine idee habe und anfange.

Engywuck · 2 Aug. 2009

Man sollte sich nicht so viel an ausgeführtem Code aufhalten. Ob ein paar Zeilen Code mehr oder weniger ausgeführt werden, ist meiner Erfahrung nach ohne Belang, so lange man sich nicht in einer Schleife befindet.
Um ein Beispiel aus meinen eigenen CW-Beiträge anzuführen: Früher wurde durch lesen des public-Feldes is_filtered bestimmt, ob ein Cache in der Liste angezeigt wird, oder nicht. Heute macht das die Methode isVisible(), die (mal eben) wie folgt aussieht:

Code:

	public boolean isVisible() {
		Profile profile = Global.getProfile();
		int filter = profile.getFilterActive();
		boolean noShow=
			(  (profile.showBlacklisted() != this.is_black())   
				||
			   (profile.showSearchResult() && !this.is_flaged)   
			    ||
			   ( (filter==Filter.FILTER_ACTIVE||filter==Filter.FILTER_MARKED_ONLY) &&	
			  	 (this.is_filtered())^profile.isFilterInverted())                            
			  	||
			   (filter==Filter.FILTER_CACHELIST) && 
			     !Global.mainForm.cacheList.contains(this.getWayPoint())
			);
		boolean showAddi = this.showAddis() && this.mainCache != null && this.mainCache.isVisible();
		noShow = noShow && !showAddi;
		return !noShow;
	}

Obwohl das deutlich mehr Code ist und die Methode an vielen Stellen aufgerufen wird, merkt man keine Geschwindigkeitsnachteile, obwohl man natürlich (bei so viel mehr Code) versucht ist, welche zu vermuten.

Was Dein Beispiel mit dem Detail-Panel angeht: Dort wirst Du auch bei optimaler Programmierung vermutlich keine Änderungen der Performance bemerken. Das geht eh alles im Ewe-Handling der Oberfläche unter. Schließlich müssen da einige Controls abgebaut und andere neu gemalt werden - da ist es im vergleich relativ egal, ob Du zwei oder zwanzig mal checkst, wie groß die cacheDB ist.
(Nicht dass wir uns falsch verstehen: Der DetailsPanel-Code ist alles andere als einfach und durchsichtig, dem tut eine Grundreinigung sicher gut. Aber gerade bei so interaktivem Anwendungscode sind wir i.d.R. das kleinste Rad am Wagen...)

Gruß,
E.

[dev] Umbenennen von Wegpunkten

Geocacher

Geoguru

Geocacher

Geoguru

Geoguru

Geoguru

Geoguru

Geomaster

Geowizard

Geomaster

Geowizard

Geoguru

Geowizard

Geoguru

Geomaster

Geoguru

Geowizard

Geowizard

Geoguru

Geowizard