Das Kompilieren ist nicht das Problem. Der Emulator ist das Problem. Der ist ein einziger Witz. Selbst für eine "Hallo Welt"-App braucht das Teil 5 Minuten zum Laden.
Am Besten ist es, du benutzt gleich ein Smartphone. Als Alternative kann man sich auch eine VM mit einem Android-OS installieren und dann mittels des Tools adb, welches beim SDK dabei ist, eine Netzwerkverbindung zur VM aufbauen. Das ist um weiten schneller, als der Emulator.
Eine x86 Version von Android kann man sich hier runterladen -> http://www.android-x86.org
Allerdings ist damit nicht alles möglich.
Wir haben auf Arbeit alles was wir brauchen Aber danke! Ich hab dass dann einfach so gemacht das ich den Emulator hab laufen lassen. Mehr als ein Hello World sollte ich eh nicht machen, ich wollt nur gucken wie das dann so geht. Du hast aber Recht auf einem Gerät geht es schneller und zum Glück bekomme ich morgen eins x_X
Btw ist das Laden noch lange nicht so schlimm wie die Performance von dem Ding. Ich meinte übrigens nicht das kompilieren, das ist ja in Java immer sehr fix sondern hab nur die Geschwindigkeit vergleicht (Natürlich ist C beim kompilieren schneller als der Emulator).
So eine VM werd ich mir jetzt aber trotzdem mal laden
Den Emulator benutzt du eigentlich nur, wenn du die Affenherde auf deine App los lässt. Es gibt zwar einen Paramter die nur auf ein Packet zu beschränken aber bei mir sind die schon ein par mal ausgebrochen. Wenn dein echter Androiden von denen angefallen kannste echt Spaß haben. Zack: Nummer in Pakistan gewählt. o.O
Es gibt aber die Möglichkeit den Emu mit nem Speicherabbild zu laden. Das soll angeblich schneller gehen - bei mir scheint es nicht zu funzen.
Fazit: Um gewisse Darstellungsfehler auf anderen Droiden nachvollziehen zu können ist das Ding geeignet. Schön mit ner Tasse Tee lohnt sich das. Aber für komplexe Bugs ist der echt zu lahm.
(PS: Für ne Minivorschau kannste auch direkt die .xml im Ecipse angucken Da ist wie bei der .manifest ein Reiter. Oben kannst du verschiedenen Auflösungen, Bildschirme und Themes einstellen.
Für relatives Layout ist das aber eher ein WYSIAWYG-Tool. Der Code ist ... kreativ.)
Die Gui ist mir relativ egal, das mach ich erst zu schluss, ich weiß aber bereits das ich die über die main.xml konfigurieren kann. Der Code ist echt übel, vor allem wenn du dann noch die Support Jar dazu nimmst, da heißt es dann nicht mehr Activity (lol), sondern Fragment(WTF?). Ist echt nicht witzig und ich bin ganz froh das ich das erst mal nach hinten verschieben kann. Allgemein kann ich das erst mal sein lassen, vorrangig ist jetzt: Userdaten (Name, Password usw) irgendiwe auf dem Android sichern, Stichwort Credentials. Da gibs ja irgendwas mit SharedPreferences, hoffe das klappt direkt
btw, kennt einer von euch ein gutes Json Framework? Jackson ist zwar gut, aber das zu parsen ist irgendwie merkwürdig... theoretisch müsste ich rekursiv schau ob etwas in meinem Json ist, da das keine simple Struktur ist :/
Ein Fragment ist ein Teil der GUI, der in Activities verwendet werden kann.
Falls es eine App werden soll, wo mehrere Nutzer sich anmelden und ihre eigenen Einstellungen vornehmen können, kommst du mit den SharedPreferences nicht weit. Außerdem finde ich diese ein bisschen umständlich. Nach jeder Änderung muss noch zusätzlich das commit() aufgerufen werden, da er die Daten nur erstmal zwischenspeichert. Erst beim commit() schreibt der die Daten persistent.
Zitat von YoshiGreen
(PS: Für ne Minivorschau kannste auch direkt die .xml im Ecipse angucken Da ist wie bei der .manifest ein Reiter. Oben kannst du verschiedenen Auflösungen, Bildschirme und Themes einstellen.
Für relatives Layout ist das aber eher ein WYSIAWYG-Tool. Der Code ist ... kreativ.)
...
Wer guckt sich auch schon den generierten Code an?
Die XML Datei reicht völlig aus.
Die support lib sind ja für die Abwärtskompatibilität. Kannst du also am Anfang erstmal Beiseite lassen.
SharedPreferences sind sehr gut für allgemeine Einstellungen in der App geeignet. Das reicht eigentlich auch für "Multianmeldungen" - die es so ja nicht wirklich gibt.
@Whiz: Es gibt Lebewesen die machen damit ganze Designs. "Und der Code ist ja so sauber formatiert." Nettere Menschen bekommen davon gesteigerten Blutdruck
Danke YoschiGreen Falls sich Jackson als ungeeignet herausstellen sollte versuch ich mal das. Das Problem ist echt das Format das imho (bin ja Anfänger was das angeht) ziemlich komplex, ich kann das ja mal abgespeckt posten:
Was ich tun muss ist alle Objects des ersten arrays auslesen und den "title" dann in eine Liste donnern, wass dann auf Android als List auftauchen soll. Als 2. muss ich die "// einige key/value pairs" auslesen... Das wird sich wohl noch bis morgen hinziehen.
Anders als bei x-beliebigen Java GUI-Builder setzt Android voll und ganz auf XML-Dateien für die Erstellung einer GUI.
Es ist zwar möglich, mittels Java-Code eine View zu erstellen, aber dies sollte man, aus Übersichtlichkeit, soweit wie möglich vermeiden und stattdessen die Views mittels XML definieren und sie dann mit Daten füllen. Der generierte Code, der das SDK aus den XML-Dateien bastelt hat keinen zu interessieren und sollte auch nicht verändert werden, da der Code eh beim nächsten Build wieder überschrieben wird.
Und wer meint, er müsste da irgendwas mit Java-Code zurechtfrickeln und den generierten Code verunstalten, weil der Code für ihm zu unübersichtlich ist, gehört einfach geschlagen.
@YoschiGreen
Danke, ich glaub jetzt versteh ich das besser hab das aber nicht mit Objects und Arrays gemacht weil ich das doof fand. Stattdessen hab ich auf das Full-Data-Binding von Jackson zugegriffen. Das mappt mir die Sachen auf eine POJO, dafür sind vor allem die Exceptions super. Die sagen einem direkt was noch fehlt und die Annotations lassen das ganze sogar schön aussehen (die Json-Keys haben... exotische Bezeichnungen ). Das ist vllt etwas übel, aber ich brauch ja später eh alle Projekte in der Json mit Inhalt.
@Gui
Naja Whiz, für Anfänger (war ja jeder mal) ist das sicher erst mal etwas schwerer die würde ich nicht gleich schlagen Allerdings würde ich es auch vermeiden mit Code die Gui zu machen... Bin ganz froh das es so gelöst ist. Scheint ja sogar recht ressourcenfreundlich zu sein.
Edit:
Wie pusche ich eigentlich Daten zwischen Activities umher oO. z.B. Verbindungen mit einer Datenbank oder mit dem Internet, oder allgemein Objekte?
Edit:
Wie pusche ich eigentlich Daten zwischen Activities umher oO. z.B. Verbindungen mit einer Datenbank oder mit dem Internet, oder allgemein Objekte?
...
Das ist so ne Sache, die ein IMO ein bisschen unglücklich gelöst wurde.
Man kann sog. Intents den Activities weitergeben. Das ist dann ein Key-Value-Paar. Allerdings kann man nur bestimmte Datentypen an eine Activity weiterreichen.
Für ne Datenbankanbindung haben wir eine Singleton-Klasse geschrieben, die beim Starten der App Instanziert wird.
Es ist auf jeden Fall möglich, dass man in Java Funktionen und Variablen mit allen Schriftzeichen ( aus UTF-16 - außer Klammern, spezielle Steuerzeichen, \ und / ) nennen kann. Man muss dann nur drauf achten, dass man als Encoding der Quellcode-Dateien standardmäßig UTF-16 nutzt.
Ich halte mich aber an die Konvention alle Variablen und Funktionen in englisch zu deklarieren.
Übrigens muss ich mich in Rahmen eines "Praktikums" gerade mit modellgetriebene (nicht modellbasierte!) Softwareentwicklung mit EMF und Entwicklung von Plugins und Editoren mit GEF auf Basis von Eclipse rum ärgern. Die Modelle selber und den Quellcode automatisch daraus erstellen ist kein großes Ding, aber der Code den man für GEF erstellen muss ist echt schwer und umständlich.
Habt ihr schon mal modellgetrieben etwas entwickelt?
PS: Modellgetrieben != Modellbasiert
(Da will einer einen humanoiden Roboter bauen, der über Windows läuft und dessen Software von vielen Personen modulweise entwickelt werden soll, genauso wie die Hardware, was das ganze zu einem billigen "no-brainer" werden lassen soll... Tjo.)
Dieser Absatz ist ja genial:
Zitat von TESLACOIL
Some one might be into robot hands so will focus on this, another persons interest may be object recognition or speech output. By using a single physical body plan and by separating all the code into stand alone exes which share data via simple txt files it is possible to build something pretty amazing for a fraction of the time money and effort.
...
Zeigt mir bitte mal, wie man über "simple txt files" in einem humanoiden Roboter, in Realtime Daten zwischen für "robot hands" oder "object recognition" zuständige "stand alone exes" austauschen soll. ROFL.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
Das reicht eigentlich auch für "Multianmeldungen" - die es so ja nicht wirklich gibt.
...
Ich hab eine gebastelt. ^^
Ist aber eine Firmeninterne App gewesen, wo mehrere Nutzer das selbe Gerät benutzen.
Zitat von YoshiGreen
@Whiz: Es gibt Lebewesen die machen damit ganze Designs. "Und der Code ist ja so sauber formatiert." Nettere Menschen bekommen davon gesteigerten Blutdruck
...
Die Leute, die mit selbstgefrickelten Java-Code komplette Designs basteln, haben das Android-System nicht verstanden und gehören geschlagen.
Meine längste Zeit die ein Compile-Vorgang gebraucht hat, war 3 Stunden auf'm Lappi.
Was ich da am Wickel hatte: Linux 3.4-rc6 (der Kernel selber war in 20min fertig, der Rest war die ganzen Module compilieren, mit Default-Konfiguration).
Warum ich das compiliert hatte: Bug-Report vervollständigen mit Infos. Ich habe da einen schönen Bug im Kernel auf meinem Lappi, natürlich eine Regression.
Leider habe ich zu spät gelesen, dass ich make auch noch den Parameter -j[Zahl] geben kann (z.B. -j4 für 4 Aufgaben, die parallel ausgeführt werden sollen).
Ach ja, um auf PHP zurück zu kommen:
PHP-Bashing macht immer Spaß, ich kann mich an folgendes erinnern: http://blog.fefe.de/?ts=b17a03df
PHP mag ja einen Sinn haben, aber es ist einfach nur so schlecht geschrieben und völlig verbuggt.
PS: Ich brauch eine neue Tastatur.
Wenn man für 5 Wochen Tag für Tag auf einer Laptop-Tastatur tippt (Graka vom Desktop-PC defekt und reklamiert, natürlich hab ich keine Ersatz-Graka da), fühlt sich eine "normale" Tastatur an als ob man auf einer Schreibmaschine rumtippt.
Das Problem an PHP ist einfach, dass es von einer großen Community entwickelt wird und jeder seine eigenen kleinen Brötchen backt.
Schaut man sich hingegen andere Sprachen an, so fällt schon auf, dass es dort nur eine kleine Gruppe gibt, die die Design-Entscheidungen treffen.
Beim gescheiterten PHP6 musste ich mir auch an den Kopf fassen. PHP6 sollte ja mit einer Unicode-Unterstützung ausgestattet werden, aber nicht nur bei der Ausgabe (da wäre es mal bitter nötig), sondern auch im Quellcode. Das heißt im Klartext, dass auch hebräische, chinesische, ... Funktionsnamen zulässig gewesen wären, was auch der primäre Gedanke dahinter war. Ich frage mich, wer dort so viel Rotwein gesoffen hat, um auf diese Idee zu kommen? Zum allen Überfluß hätten wir nicht nur ein Gemische aus strukturierter- und objektorientierter Programmierung, sondern noch ein Gemische aus Sprachen.
Und was Wordpress angeht:
Wordpress ist so ein Kandidat, um aufzuzeigen, wie man es an vielen Stellen nicht machen sollte.
Man siehe sich mal die Translate() Funktion an.
Der zu übersetzende Satz wird als Index missbraucht. D.h. er sucht diesen Satz in seinen Übersetzungstabellen. Also muss der Satz auch zu 100% stimmen. Ansonsten findet er ihn nicht.
Ist ja auch sehr sinnvoll ... Die haben wohl den Begriff "assoziatives Array" zu wörtlich genommen.
Das mit dem translate beruht allerdings auf gettext einem Unix Standard ... ist also keine reine PHP Erfindung.
(Ändert nichts daran das gettext einfach nur Schwachsinn ist^^)