Whiz-zarD

Wenn ich schon sowas lese, kriege ich die Krise. Aus dem Namen "out2" wird nicht ersichtlich, was die Methode eigentlich macht und offenbar dir auch nicht, denn sonst hätte sie einen sprechenden Namen.

Hallo, ich wollte mich mal privat etwas mit Bluetooth beschäftigen und suche daher ein paar gute Lektüren zu diesem Thema. Speziell geht es mir um die Programmierung und um die Sicherheitsaspekte, die zu berücksichtigen sind. Ich selber arbeite inzwischen zwar hauptsächlich mit C# aber ich habe vor sechs Jahren auch beruflich für Android entwickelt, also bin ich auch der Sprache Java mächtig, wenn auch schon etwas eingerostet. Kennt da wer ein brauchbares Buch oder eine Webseite, wo man sich mal ein bisschen reinlesen könnte? Vielen Dank im Voraus.

Und da kommt man dann von hundertstel ins tausendstel und verbrät dann zu viel Zeit und Energie. Für eine Software, die sowieso wohl schon veraltet ist. Da sollte man sich schon mal fragen, welchen Sinn es noch macht, etwas eigenes zu entwickeln, wenn es doch schon fertige Bibliotheken gibt? Man muss nicht immer das Rad neuerfinden. Man sucht sich zwei oder drei Bibliotheken. Überprüft deren Einsatz und schaut sich die Lizenzbedingungen an. Evtl. kommt man dann zum Entschluss, dass es doch besser wäre, etwas eigenes zu entwickeln, wenn man das Feature wirklich braucht aber die Evaluierung grundsätzlich auszuschließen, weil man vorherein schon Angst hat, nicht etwas passendes zu finden, ist falsch.

Darum sollte man auch mehrere Bibliotheken suchen und diese evaluieren ...

So einfach ist das nicht. SELECT DATE('2016-01-01') FROM DUAL Wird ja in SELECT DATE ( '2016-01-01' ) FROM DUAL formatiert, was nicht schön aussieht. Vielleicht solltest du dann meinen Beitrag noch mal durchlesen. Ich rede nicht von der gesamten Anwendung, sondern von einer Bibliothek, was dir das SQL formatiert ...

Es ist ein Trugschluss, wenn man denkt, dass es besser ist, wenn man alles selber entwickelt. Das Problem sehe ich auch in der Firma, wo ich arbeite. Die Software ist jetzt 10 Jahre alt und damals war man auch der Meinung, dass es besser wäre alles selbst zu entwickeln, weil man Angst hatte, wenn man Bibliotheken von Drittanbietern ins Boot holt, dass die Firmen irgendwann pleite gehen und dann mit einer veralteten Bibliothek stehen bleibt. Man hat dann angefangen, etliche Frameworks selbstzuentwickeln. Die Entwicklung hat dann Jahre gedauert und nun hat man veraltete, gigantische nicht testbare Frameworks im Einsatz, die man nicht mal gegen modernere Frameworks austauschen kann. Das Fazit der ganzen Geschichte ist: Die sog. Test-Pyramide steht auf dem Kopf. Alles wird manuell getestet. Die Tester bremsen die Entwicklung aus, weil sie nicht hinterherkommen. Die Kunden beschweren sich zunehmend über die Performance und die Anzahl der Bugs erhöht sich auch immer weiter. Wir sind jetzt dabei, die komplette Anwendung neuzuschreiben, weil es nicht mehr anders geht. Wir haben nur das Glück, dass wir eine Nischensoftware für Banken entwickeln und in dieser Nische Marktführer sind. Ansonsten wären wir auch schon lange weg vom Fenster. Daher finde ich, dass eine Firma sich mehr auf ihre Kernkompetenzen konzentrieren soll und weniger um das Drumherum. Wenn ihr ein SQL-Formatter einbauen wollt, dann müsst ihr auch eins im Klaren sein: Nur weil ihr es entwickelt, ist es nicht kostenlos und auch nicht besser! Die Entwickler kosten auch ihr Geld und besitzen auch evtl. das nötige Know-How so ein Feature entwicklen zu können und da sollte man sich schon überlegen, ob es dann nicht eher Sinn macht, einmal Geld in die Hand zu nehmen und eine Bibliothek kaufen, was das gewünschte Feature kann, anstatt es selbstzuentwickeln und sehr viele Ressourcen dafür zu verschwenden. Es ist ja nicht nur die initiale Entwicklung. Es betrifft ja auch die Wartung und das Bugfixing. Dass das Know-How bei euch nicht vorhanden sieht man schon, dass ihr nicht wisst, wie ihr da vorgehen müsst, denn im Grunde müsst ihr ein Parser schreiben und dafür eignet sich ein endlicher Automat.

General SQL Parser Das ist so das erste, was ich unter Google gefunden habe, was auch wohl als Open Source zur Verfügung steht. Alle anderen Frameworks, die ich gefunden habe, waren kostenpflichtig. Wofür dient denn das Tool? Als Datenanalyse? ETL? Vielleicht wäre es auch angebracht, mal das Tool zu überdenken und zu schauen, ob es überhaupt noch Sinn macht, das Tool weiterhin zu pflegen oder ob man nicht ein Tool einkauft, was genau die Aufgabe macht, die ihr braucht. Edit: Ok, ist wohl doch nicht so ganz kostenpflichtig, wie ich dachte. :/

Ich finde auch schon die ganze Infrastruktur sehr merkwürdig und veraltet. Windows CE PDAs, ein Datenbank-Server der aus irgendwelchen Gründen regelmäßig neugestartet werden muss, im ERP-System müssen XML-Dateien manuell korrigiert werden, Webbrowser werden gezwungen maximiert dargestellt zu werden, ... Klingt alles nicht gerade nach einer gut funktionierenden Infrastruktur, sondern nach jahrzehntelanger Vernachlässigung der Infrastruktur, die ein Azubi jetzt wieder zurechtfrickeln muss, damit sie irgendwie am Leben erhalten werden kann.

Du hast doch nur die zwei Möglichkeiten: Entweder du sorgst für eine Ausfallsicherheit (wie sie auch immer aussehen mag) und du hast die Daten redundant oder du sorgst dafür, dass der Abgleich der Datenbanken nicht stattfinden kann, wenn Datenbank B nicht zur Verfügung steht. Man kann ja nicht zaubern und ein Abgleich implementieren, der auf eine Datenbank zugreift, die nicht da ist.

Man könnte es auch so machen, dass man von der View eine Tabelle auf Datenbank A erstellt und dann mit dieser Tabelle arbeitet. Wenn Datenbank B erreichbar ist, wird dann die Tabelle neu erstellt und wenn die dann nicht erreichbar ist, hat man weiterhin den Stand.

Mocking-frameworks machen auch schon bei simplen Dingen Sinn, da der overhead sehr gering gehalten wird. Du musst einfach keine Klassen erstellen, in der vielleicht ein oder zwei Methoden implementiert sind, sondern du schreibst nur drei Zeilen Code.

Wenn du das nicht weißt, wer dann? Wenn der Server zwei mal im Monat für eine gewisse Zeit offline ist, dann ist er ja für, sagen wir mal, 95% der Zeit online und da sollte man sich auch fragen, ob für die restlichen 5% überhaupt sich der Aufwand lohnt, irgendwas zu machen, wenn die Daten sich sowieso kaum ändern. Vor allem in der Zeit, wo er offline ist, die Daten sich sowieso nicht ändern.

Wenn die Datenbank nicht erreichbar ist (was ich schon sehr merkwürdig finde), dann kannst du ja schlecht die Daten abrufen. Also muss eine Ausfallsicherheit geschaffen werden, z.B. einen weiteren Benutzer, wo die Daten redundant gespeichert werden.

Was meinst du mit komplex? Bild-dateien könntest du mit Base64 kodieren und als ein CDATA-abschnitt in die XML-datei packen. Wenn die Texte mehrsprachig sein müssen, kannst du auch nur einen identifier in die XML-datei packen und dann für die Sprachen eine Ressourcen-datei anlegen oder du legst für jede Sprache ein eigenes Element in der XML-datei an. Wenn ich mich noch recht erinnere, dann müsste in Android auch SQLite integriert sein. Vielleicht ist das ein Stück eleganter. Es gibt hier nun mal keine einfache klicki-bunti-lösung. Da muss man dann selbst ran.

Das ist dann mein Fehler in dem anderen Thread. Bei der Methode Show() wird die Form aus dem Speicher gelöscht, wenn sie geschlossen wird. Die richtige Methode wäre ShowDialog(). Hier wird die Form dann nur unsichtbar geschaltet, wenn sie geschlossen wird und besitzt dann ein DialogResult.

Welche Gründe sprechen denn dagegen? Der initiale Aufwand? Wurde auch berücksichtigt, dass die App sich nicht alleine deployed? Jedes Mal eine neue App in den Store laden, wenn eine Erweiterung hinzugefügt wurde, halte ich für nicht zielführend. Schon mal davon ausgehen muss, dass nicht jeder die aktuelle App-Version besitzt und somit nicht alle Erweiterungen sieht. Eine REST-Schnittstelle zu implementieren ist jetzt auch nicht die Welt. Man braucht jetzt auch keine Datenbank aufsetzen. Eine XML- oder SQLite-Datei würde auch schon reichen. Alternativ lädt man nur die XML-Datei runter. Ein Apache-Server ist binnen wenigen Minuten aufgesetzt und ein HTTP-Request ist mittels Java auch ein Ein-Zeiler. Über die Zeit gesehen ist dieser Aufwand geringer, als immer eine neue App in den Store zu laden.

Naja, es werden doch mal weitere Erweiterungen hinzukommen, oder nicht? Daher ist so etwas ja nicht unbedingt statisch und sollte auch nicht in der App hinterlegt werden, sondern sollte über eine REST-Schnittstelle abgerufen werden. Ansonsten müsste man bei jeder neuen Erweiterung eine neue Version der App ausliefern. Ich könnte mir da sowas wie OData vorstellen.

Das Problem ist, du rufst die Konstruktoren immer wieder neu auf. Du hast hier ein Zirkelschluss produziert. Wenn du Settings instanziierst, wird im Konstruktor Form1 instanziiert und Form1 instanziiert wiederrum Settings, usw. usw. Ich nehme mal an, dass Form1 dein Hauptfenster ist und in Form1 Settings aufgerufen werden soll. Settings darf von Form1 nichts wissen. Wozu auch? Und wenn Settings unbedingt Form1 kennen muss, dann musst du Form1 als Abhängigkeit reinreichen. public Settings(Form mainForm) { InitializeComponent(); this.mainForm = mainForm iniText = form1.GetIniText(); } Aber selbst das würde ich nicht tun. Ich würde beim Aufruf von Settings den iniText reinreichen: public Settings() { InitializeComponent(); } public string IniText { get { return this.iniTextTextBox.Text; } set { this.iniTextTextBox.Text = value; } } Dann würde ich Settings so aufrufen: Settings settings = new Settings(); settings.IniText = "foo bar"; settings.Show(); Damit ist Settings nicht von Form1 abhängig.. Dies ist jetzt nur eine abgespeckte Version, um das Prinzip etwas zu verdeutlichen. Wenn du es wirklich elegant lösen willst, dann informiere dich über MVP (Model-View-Presenter).

Dann musst du mal erklären, was du unter "Set" verstehst und was du damit machen möchtest. Natürlich kannst du dir auch eine XML-Datei schreiben und diese dann Parsen. Unter Java kannst du auch JAXB oder XMLBeans verwenden. Das sind Frameworks, mit der du XML-Elemente direkt mit Java-Klassen binden kannst. Das hat den Vorteil, dass du die Eigenschaften anpassen kannst, ohne gleich neu kompilieren zu müssen. Ansonsten musst du das Parsen selbst übernehmen; z.B. mit SAX. So oder so entspräche dies eher dem Open-Closed-Prinzip.

Ja, ein Mocking-Framework nimmt dir dort viel Arbeit ab. Das erfordert aber, dass du für jede Abhängigkeit immer ein Interface bereitstellst. Dann kannst du ein Mocking-Framework benutzen und über das Framework bestimmen, wie die einzelnen Methoden reagieren sollen. Welches Framework unter Java empfehlenswert ist, weiß ich leider nicht aber offenbar wird häufig JMockit oder Mockito verwendet.

Da liegst du richtig, dass man es so nicht macht. Ich schreibe hier gerade vom Smartphone aus, deswegen kann ich gerade kein Beispiel schreiben, aber das was zu suchst, nennt sich unter Java HashMap. Kannst ja mal danach suchen.

Ich denke dann mal wohl, dass die Bearbeitung per Hand erfolgt und deshalb die XML-Dateien sortiert haben möchte, damit man sich besser orientieren kann. Das ist also mehr ein organisatorisches Problem und kein technisches.

Ein Shopsystem, was mit XML-Dateien rumhantiert und über die XML-Datei werden die Produkte sortiert, wie sie dann in der Oberfläche angezeigt werden? O_o Klingt sehr abenteuerlich. Schon mal ich dafür wohl nicht XML nehmen würde, sondern JSON, weil das Format kompakter ist.

Wozu muss eine XML-Datei sortiert werden?

Vielleicht wäre es angebracht, dass du dich erst mal mit C# beschäftigst (Bücher, Tutorials, etc.), denn offenbar scheitert es schon am Verständnis dieser Sprache bzw. am Verständnis der Objektorientierung.