Crystal Development Framework

Willkommen!

Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.
  • tjaa, wie auf Twitter angekündigt habe ich mein Framework für WebOS nun veröffentlicht.


    Das Framework ist noch recht jund und besitzt noch nicht viele neue Funktionen, dennoch nimmt es dem Entwickler eine menge Arbeit in Sachen Widgets aufsetzen, Events festlegen und sie anschließend wieder zu löschen.
    Nun könnten sich einige wieder ausmalen: Dann muss ich ja immer das App updaten wenn das Framework aktualisiert wird. Aber das ist FALSCH!
    Das Framework wird auf der USB Partition abgelegt und kann so durch den "Crystal Development Framework Loader" (langes word und schon im Webchannel) heruntergeladen werden. Wird also ein App gestartet und der Core merkt dass das Framework fehlt startet es das app, schließt sich, der loader läd, schließt sich und startet das app welches das alles verursacht hat. Sollte der loader nicht installliert sein wird der katalog aufgerufen.
    Darüber habe ich aber auch wieder gebrütet: der aufwand lohnt sich nur wenn mehrere apps das framework nutzen. aktuell tun es all meine apps und noch ein paar von meinen freunden, allerdings ohne den loader!
    doch all meine nächsten updates werden eben dies verwenden. (wer das nicht möchte, als entwickler, kann das framework aber auch einbinden).


    Nun zu den funktionen:
    - Verwalten von Widgets
    ---> Alle Widgets werden über eine funktion angelegt, z.B. Core.Widgets.add("button"); Dabei werden voreinstellungen geladen welche man allerdings direkt mit den parametern wie man es vom webos framework gewohnt ist modifizieren. Wurd alles angelegt ruft man Core.Widgets.setup()'; auf und alles wird definiert.


    - Events
    ---> Mit den events läuft es ähnlich Core.Events.add(ID (string), Event (Mojo.Event.xxx), function); Das wars. man kann über diese funktion auch intervale aufrufen Core.Events.add("intervalName", "interval", function, timeout);
    ---> in der cleanup function gibt man Core.Events.cleanup() an und das wars.
    ---> man kann die events auch einzelnd abschießen Core.Events.kill("intervalName");


    - Cookies
    ---> Core.Cookie.get("name"); , Core.Cookie.set("name", value); - Selbsterklärend ;)


    - Depots
    ---> Core.Depot.init("name", version, size, replace, callback); - initialisiert das depot
    ---> Core.Depot.get("FieldName", callback); Core.Depot.set("FieldName", value, callback); - wieder selbsterklärend.
    ---> Im moment nur ein depot pro anwendung, wir aber ausgeweitet


    Database
    ---> Ähnlich wie Depot in der initialisierung
    ---> Werde dazu im noch aufzubauenden wiki etwas verfassen, sind befehle wie: insert, select, update, delete und query. alles kein hardcore sql danke sql builder!


    Database Cache
    ---> Das ist was ganz feines, man kann damit die daten eines querys ablegen und diese abrufen und aktualisieren ohne immer mit database und so den ganzen quatsch zu wiederholen
    ---> näheres dann auch im wiki


    File
    ---> nur eine funktion bis jetzt: read. kommen aber noch viele wie exists, write(download) dazu.


    Log*
    ---> Ein eigener Log der remote debugging unterstützt und die vom palm geschickten errors abfängt.


    Update*
    ---> Zeigt in der App an ob updates im katalog sind.


    * Benötigen die entsprechenen Scripte (am besten mit meinem CMS, also das worauf meine Seite läuft, saugt sich immer die Feeds von Palm und aktualisiert somit die apps auf der seite, bilder, downloads, rating und so)


    Notify
    ---> im moment noch nicht viel: banner und alert.


    Extensions
    ---> ein paar prototyp erweiterungen, noch im aufbau


    Connection
    ---> Eine sehr wichtige klasse zu überprüfung der Verbindungseigenschaften (ist man Online, verbindungstyp etc.)


    Das soll ersteinmal ein kleiner vorgeschmack gewesen sein. Den Download findet ihr wie immer auf meiner Website im Download Archiv, bei Facebook und/oder Twitter. Oder laded das Framework mit dem Crystal Development Framework Loader herunter (Ich liebe diese wort :P)


    DOWNLOAD


    greez
    TheRealLink

  • Wie schonmal drauf hingewiesen: es heißt DIE App!!!


    +1 Augenkrebs!!!


    TheRealLink: Das Framwork erleichtert dem Entwickler einfach ein wenig Arbeit, richtig?

  • oh, eine Grammatikdiskussion :boogie:
    bei App ist es wie bei anderen Fremdwörtern - der Artikel richtet sich u.a. danach, welchen Artikel ein vergleichbares Wort im Deutschen hat: : die Anwendung (oder hier noch sinniger: die Applikation)

  • Hallo "TheRealLink",
    ...ich habe keine Kenntnisse/Erfahrungen im Bereich webOS-Entwicklung. Aber eine Ahnung davon, was Du mit Deinem Framework geleistet hast resp. leisten wirst. Eine absolute Bereicherung....! :thumbup:


    Gerade in diesem Zusammenhang finde ich die drei nachfolgenden Beiträge in Bezug auf deutsche Rechtschreibung mehr als nur OT. :thumbdown:


    Sorry, auch ich bin der deutschen Sprache mächtig und versuche sie adäquat anzuwenden (...auch wenn zeitweise Anglizismen ("Sorry") oder Fremdwörter ("adäquat") mit einfliessen.). Aber ich muß nicht alles permanent korrigieren.
    Was mich in diesem Fall stört, ist das "zerreden" eines "Top-Beitrags".


    TheRealLink: weiter so....! :thumbup:


    Gruß Jörg

    ========================================================
    PalmOS => Vx | T3 | Treo 680 ......=> andere <=...... Treo 750v | Treo Pro <= WM 6

  • Ersteinmal: Vielen Dankf für euer Feedback :)


    Jonny-TX: Das Framework nimmt dem Entwickler in der Tat einiges an Arbeit ab, fügt allerdings auch viele neue Funktionen hinzu.
    Blacklight: Das mit dem PDK ist eine feine Sache, auch ich zog es bereits in Erwägung, nur kenn ich mich dann doch nicht so gut in SDL/openGL aus um vernünftige Programme zu schreiben (C/C++/C# beherrsche ich jedoch).
    @OT Schreiber: Die App, Die App, Die App, Die App, Die App, Die App... zufrieden? (gestern war es spät -.-)


    greez
    TheRealLink

  • Blacklight: Das mit dem PDK ist eine feine Sache, auch ich zog es bereits in Erwägung, nur kenn ich mich dann doch nicht so gut in SDL/openGL aus um vernünftige Programme zu schreiben (C/C++/C# beherrsche ich jedoch).


    Och, dann würdest du schnell reinkommen. Ich hab ja vorher noch nicht mal in C++ geschrieben, nur Java. Allerdings muss ich das auf SDL eingrenzen.. OpenGL ist ziemlich komplex. Ich hab aber auch nur ein wenig rumgespielt, richtig interessant könnte ich mir zukünftig gut gemacht Hybrid-Apps vorstellen.

  • omg, du hast recht! hab eine geniale seite gefunden die alles schritt für schritt erklärt! (c/c++ vorrausgesetzt)
    Also leute: bald pdk apps von mir ;) hab schon einige games auf lager die nur drauf warten umgesetzt zu werden :D *freu mich gerad riesig ^^*


    greez
    TheRealLink


    P.S: das framework wird bereits von ein paar apps verwendet und bekommt am mittwoch (FERIENNNN!!!!!) ein paar updates.

  • Na siehst du ;) Welche Seite war das denn? Nur so aus Neugier, auch wenn ich die vielleicht auch schon entdeckt hab.


    +1 Würde mich auch interessieren!

  • http://www.sdltutorials.com ;) so einfach und genial (englisch)
    nur das mit diesen fucking zeigern und address verweisen bekomm ich einfach nicht in meinen kopf... (naja, wird schon)


    Ah danke, die kannte ich doch noch nicht. Hehe, jaja die Pointer.. ewige Qual.


    Wenn übrigens wer den SDL_Mixer für Audio Wiedergabe nutzen will und Performance Probleme hat, fragt mich :pfeift:
    Und ganz wichtig, weshalb meine Apps vermutlich abgelehnt wurden: ihr müsst die PDK Apps von debug symbols "strippen"!! Sie werden sonst rejected.. das geht mit der "-s" Option bei den Linker Flags (also neben "-lSDL" usw.), oder mit dem strip-utility nach dem build.

  • Ich möchte an dieser Stelle kurz meine Meinung zu dem Framework abgeben:


    Ich finde es sehr gut und auch lobenswert, dass du dich damit befasst, wie man code mehrfach verwenden kann. Ich weiß auch wie viel Arbeit es ist und wie viele Gedanken man sich machen muss, bis so etwas wirklich steht und auch funktioniert.


    _ABER_


    Soweit ich das jetzt verstanden habe und aus den Quellen des Frameworks lese, wird das Framework auf dem "USB-Speicher", also in /media/internal abgelegt. Das ist ein ganz großes Problem!!!


    Du nutzt das, damit das Framework universell verfügbar ist und auch unabhängig von der eigentlichen App gewartet werden kann. Genau diese Eigenschaften reißen aber auch eine riesen Sicherheitslücke in das ganze System.


    Genau wie dein Framework kann nämlich auch jede andere App ohne das Wissen des Nutzers die Dateien des Frameworks ändern und austauschen. Das ermöglicht es fremden Leuten, das Framework um Schadcode zu erweitern. Dieser Schadcode wird dann von deinen Apps, oder den App die das Framework nutzen, ausgeführt!


    Deswegen rate ich dringend davon ab, Code der ausgeführt wird an einem Ort abzulegen, wo jede App drauf schreiben und lesen kann und das ist /media/internal nunmal. Wenn sich der Angreifer etwas geschickt anstellt, merkt der Benutzer sogar nicht mal, dass der Code ausgetauscht wurde und kriegt nicht mit, dass er Schadcode ausführt. Da die App selber auch keinen Schadcode enthält, sonder dieser erst zu tage kommt, wenn dein Framework installiert ist, hat Palm auch keine Möglichkeit Apps danach zu untersuchen.


    Hier ein konkretes Beispiel eines möglichen Angriffes:


    Das Framework besteht jetzt mal rein hypothetisch nur aus einer Datei und die liegt wie schon gesagt in /media/internal/crystalframework/main.js. Dort sind mehrere Funktionen und alles funktioniert auch mit deinen Apps super. Jetzt kommt eine Andere App daher und läd eine Datei von einem Server runter und speichert sie genau an der selben Stelle /media/internals/crystalframework/main.js. Dadurch wird das Original überschrieben. Da der Angreifer das Framework selber installiert hat, kennt er den Inhalt der original Datei und hat diese so modifiziert, dass sie zwar noch funktioniert wie sie soll, aber zusätzlich noch das macht, was der Angreifer will. Z.B. im harmlosesten Fall bei jedem Start einer Framework App eine Homepage aufrufen.


    Der Nutzer hat keine Ahnung warum das so ist, die Schad-App funktioniert und tut was sie soll und alle deine Apps öffnen beim starten seine Seite.


    Ich hoffe an dieser Stelle ist klar geworden, warum es eine schlechte Idee ist, Code von einer anderen Stelle als der eigenen App einzubinden.


    Was kann man tun um das Problem zu lösen? Man müsste sicherstellen, dass es sich wirklich um das original Framework handelt. Dies geht mit md5 summen oder ähnlichem, was aber leider mit javascript nicht möglich ist.


    Soviel an dieser Stelle von mir, ich persönlich finde das Risiko des Missbrauchs sehr hoch und gerade bei einem so sensiblen Gerät wie dem Handy sollte man nicht mehr Sicherheitslücken aufreissen als nötig.

  • Hm dieser gedanke ist mir natürlich auch gekommen, desswegen arbeite ich gerad an einem validator welcher in der init.js (welche in jedem app ist und immer eingebunden wird) steckt. erste testläufe laufen sehr gut ;)


    Das FW steck ja noch in v0.5.0 und wird nun mit folgenden funktionen erweitert:


    -Connection
    > Ping, Geschwindigkeits Bestimmung


    -File
    > Download / Upload
    > Exists


    -Download Manager
    > Download Files
    > Ticket Management
    > Abort / Delete Downloads


    -Contacts
    > Search
    > Lookup


    -Init
    > Validator


    greez
    TheRealLink

  • wie gesagt: praktisch sieht es da ganz anders aus, im moment ist es das problem die neusten hashes auch in die app zu bekommen. aktuell ist es eine kurze online abfrage bei geänderter main core version welche in einem cookie abgelegt wird und als referenz dient. (die checksummen natürlich auch)