2009-06-22 2 views
4

Ich bin in den Anfangsphasen eines Blackberry/J2ME-Projekts - und zusammen mit anderen Einschränkungen, die mit dieser wunderbaren Plattform einhergehen, bedeutet die fehlende Unterstützung für Reflexion und 1.3 Sprachlevel, dass die große Mehrheit der vorhandenen IoC-Container unbrauchbar ist . (Google hat Guice für Android ohne AOP, aber selbst das erfordert Unterstützung für Anmerkungen).Die Jagd nach dem J2ME-freundlichen IoC-Container ist eröffnet!

So ist der Platz von IoC-Containern auf J2ME ziemlich begrenzt. Der einzige Rahmen, der meine Aufmerksamkeit erregt hat, heißt Signal Framework, und er sieht ziemlich vielversprechend aus. Es versucht, konzeptionell nahe beim IoC von Spring Framework zu bleiben, indem es eine kleine Teilmenge seiner Funktionalität implementiert, und zwar ohne auf Bytecode-Modifikation angewiesen zu sein oder Laufzeit-XML-Parsing zu verursachen. Stattdessen verarbeitet es Konfigurations-XMLs zur Laufzeit, um Java-Code zu generieren, der diese IoC-Funktionalität implementiert.

Im Allgemeinen scheint die Codegenerierung zur Build-Zeit ein sehr kluger Ansatz für mobile Anwendungen zu sein - und wenn meine App weniger XML-Parsing auf dem Gerät des Benutzers ausführen muss, ist das auch toll!

Welche Erfahrungen haben Sie bei der Implementierung von IoC auf J2ME/CLDC gemacht und wie konnten Sie diesen bitteren Geschmack in Ihrem Mund löschen?

Antwort

0

Signal Framework ist es.

Update: Leider ist Signal jetzt sehr unterkocht, also gehe ich mit Israfil IOC mit benutzerdefinierten Ergänzungen.

2

In J2ME müssen Sie die Anzahl der verwendeten Klassen so weit wie möglich reduzieren, um die Größe der JAR-Dateien zu reduzieren. Dies führt zu vielen Design-Kompromissen, nicht zuletzt Flexibilität.

Es ist nicht einfach, sich an die J2ME-Entwicklung anzupassen, wenn man von dem, was man über OO gelernt hat (und zu einem hohen Wert kommen muss), aus dem Fenster werfen muss. Die Wahrheit ist, wenn Sie möchten, dass Apps, die auf einer großen Auswahl von Telefonen laufen können, sehr empfindlich auf die Beschränkungen der Geräte reagieren müssen.

Als solches glaube ich nicht, dass ein IoC-Framework die Bedürfnisse vieler Menschen nach J2ME-Entwicklung erfüllen wird.

+0

Danke shön für deinen Einblick, Grouchal :) Ich stimme deinen Gedanken zu, einige App-Design-Präferenzen auf J2ME beiseite zu legen. Der Grund, warum ich denke, dass ich es mir leisten kann, ein IoC-Framework zu verwenden, ist jedoch, dass die App, die ich entwickle, die leistungsstärkeren CLDC-basierten Geräte wie die letzten Blackberries und J2ME auf S60 anvisieren wird Modifikationen). –

+0

Die von CLDC 1.0 auferlegten Einschränkungen waren zu der Zeit, als CLDC 1.0 entwickelt wurde, fantastisch. Heute scheint es jedoch, dass die meisten Geräte von Interesse viel leistungsfähiger sind und mehr Speicher haben. Die Frage, ob wir gute Entwicklungspraktiken wie den Einsatz von IoC auf mobile Java-Entwicklung übertragen können, ist daher ziemlich natürlich. Und, wie ich schon sagte, wenn dies durch Build-Time-Code-Generierung statt während der Laufzeit getan werden kann, und es eine dramatische Verbesserung der Klarheit der Organisation von Code erreicht - warum nicht verwenden? –

1

Sie könnten Interesse an Auschecken . Auch wenn ich es nicht persönlich benutzt habe, scheint es, als ob es sich um ein nicht-sinnfreies Framework handelt, das speziell für die J2ME-Plattform entwickelt wurde.

+0

danke paracycle, ich werde es untersuchen! –

1

Ich bin während einer holländischen JUG-Konferenz auf Spring ME gestoßen (habe keinerlei Erfahrung damit).

3

Wir verwendeten Spring ME bei TomTom. Es hat gut geklappt.

Verwandte Themen