Beiträge von killphil75

Noch ein kleiner Tipp.

Du hast wie gesagt in dem onPostexecute und onProgressUpdate Zugriff auf den UI Thread,
wichtig ist es hier beim Zugriff auf UI Elemente immer gegen null zu testen da du Dir nie sicher sein kannst, das der User die Activity nicht bereits beendet hat. Somit beugst du merkwürdigen Nullpointer Exceptions vor.

if (textview != null) {
schreibe meinenporgress in Zahlen;
}

Zitat

Thomas Künneth: Android 3 Apps entwickeln mit dem Android SDK, Galileo Computing, 1. Auflage 2011

Stimmt ich habe das Buch auch hier, der redet nur von Threads und den Rest lässt er unter den Tisch fallen.
sehr unerfreulich.

Warum nutzt du keinen AsyncTask ??? Dafür sind die doch gebaut worden.

http://developer.android.com/r…android/os/AsyncTask.html
http://www.vogella.com/article…dPerformance/article.html

protected Long doInBackground(URL... urls) {


     }


     protected void onProgressUpdate(Integer... progress) {
         setProgressPercent(progress[0]);
     }


     protected void onPostExecute(Long result) {
         showDialog("Downloaded " + result + " bytes");
     }

Zitat

• onPreExecute(), invoked on the UI thread before the task
  is executed. This step is normally used to setup the task, for instance by
  showing a progress bar in the user interface.
• doInBackground(Params...), invoked on the background thread
  immediately after onPreExecute() finishes executing. This step is used
  to perform background computation that can take a long time. The parameters
  of the asynchronous task are passed to this step. The result of the computation must
  be returned by this step and will be passed back to the last step. This step
  can also use publishProgress(Progress...) to publish one or more units
  of progress. These values are published on the UI thread, in the
  onProgressUpdate(Progress...) step.
• onProgressUpdate(Progress...), invoked on the UI thread after a
  call to publishProgress(Progress...). The timing of the execution is
  undefined. This method is used to display any form of progress in the user
  interface while the background computation is still executing. For instance,
  it can be used to animate a progress bar or show logs in a text field.
• onPostExecute(Result), invoked on the UI thread after the background
  computation finishes. The result of the background computation is passed to
  this step as a parameter.

Alles anzeigen

Da kannst du deinen Progress einfach schön in onProgressUpdate packen.
Und musst nicht rum zaubern wegen Handlern und Threads.

Büdde, hab ja auch wieder was dabei gelernt.

Ich vermute mal das die Google-Jungs unter Android 4+ (oder vielleicht auch schon 3+) den DomParser soweit geändert haben, das Sie die Textelemente vorher normalizen. Das würde das Verhalten erklären 4.0 vs. 2.3 - um das zu Prüfen könnte man zwar in den SDK Source schauen aber den müsste ich erst downloaden und durchforsten... ach neee ... heute nicht

Hauptsache es funktioniert nun.

DIe UTF-8 Nummer beim Inputstream ist nur so ein Sicherheitsding, irgendwo stand geschrieben das bei manchen Androidgeräten der Stream als ISO angenommen wird, deswegen lieber den expliziten Konstruktor mit UTF

Der Domparser ist ein Drecksparser,
jetzt habe ich zwei Stunden etwas rumgetestet und Sachen ausprobiert.

Vorher die Entitys bereinigt, aber die Unicodezeichen machten immer noch Probleme.
Und nun hab ich eine Lösung die ganz einfach ist.

public String xmlFromStream(InputStream stream) throws UnsupportedEncodingException
		{
			BufferedReader r = new BufferedReader(new InputStreamReader(stream,"UTF-8"));

public final String getElementValue( Node elem ) {
			Node child;
			if( elem != null){
				
				elem.normalize();
				
		    	if (elem.hasChildNodes()){
		        	for( child = elem.getFirstChild(); child != null; child = child.getNextSibling() ){
		            	if( child.getNodeType() == Node.TEXT_NODE  ){

elem.normalize();

Scheint die Strings glattzubügeln damit der Parser drüber kommt. Dann zeigt er hier alles sauber an

Ich bin ein ganz schlimmer XMLPullParser Nutzer. Ist irgendwie am einfachsten.
Ich muss gleich weg aber ich schau mir heute Abend noch mal deinen Code an. Wenn die Childerkennung die Unicodezeichen wegschmeisst dann kann es ja nur dort irgendwo klemmen.

Zitat

An meiner Ursprungsfrage ändert das jedoch nichts:

warum kann 4.0 die UTF-8 kodierten Zeichen als String ausgeben, während 2.3 an der Stelle abbricht?

Kannst du mal etwas Code zeigen, speziell wie du die XML ausliest (es gibt bekannte Probleme hinsichtlich, XMLReader / Inputstream - ebenfalls wegen Encoding)

Und noch die Königsfrage wie gibst du die Sachen aus bzw wenn im Webview wie formatierst du die Ausgabe ?

Hast du mal nach dem "Auslesen" deiner XML ins Log geschaut bzw. dir ausgeben lassen was dort so erkannt wird ?

10min später

-- Also ich hab mir mal eben dein XML File kopiert und selber ausgelesen.
Und es kommt wie es kommen muss, XML zickt bei dem ü weil er das nicht kennt.

Ursache hier: http://en.wikipedia.org/wiki/L…aracter_entity_references

Wenn ich das einfach mal als ü umschreibe, kann ich alles andere aber super auslesen. (Ich habs nur mal unter 2.3 getestet, weil du sagst da klemmt es).

Ok klingt alles etwas vermurkst von Google wenn die Webviews schon Mist bauen.

Hast du mal statt dem "normalen" Webview den Chromeclient benutzt.

mwebview.setWebChromeClient(new WebChromeClient() {
}

Hast du das Encoding im Webview auch gesetzt bzw damit rum experimentiert ?
WebSettings settings = mWebView.getSettings();
settings.setDefaultTextEncodingName("utf-8");

bzw. beim laden

mWebView.loadDataWithBaseURL(null,meinePage,"text/html","utf-8",null);

Wichtig loaddatawithbaseurl -> weil loaddata alleine Probleme machen soll.
Eventuell ein Versuch wert.

Hmm aber irgendwie sieht dein XML auch nicht valide aus, wenn deine Datei UTF-8 ist sollten doch die Umlaute auch als solche sichtbar sein.

Ich glaube der Fehler liegt schon vorher irgendwo im Encoding.
Woher kommen die Daten ? Kannst du mal eine Probeausgabe zb in PHP machen ?

Such doch mal den AVD Manager und probier rechts klick -> Ausführen als Administrator

Was bei mir mal eine zeitlang ein Riesenproblem war. Die Comodo Firewall bzw. Defense+ wollten den Emulator nicht ausführen.
Eventl. hakt da noch eine Antiviren/Sicherheitssoftware dazwischen ?

Probier doch mal von Google das ADT Bundle, da sollte alles dabei sein

http://developer.android.com/sdk/index.html

http://developer.android.com/sdk/index.html#download

Ok,

also ich arbeite mit Eclipse daher habe ich keine Ahnung wie Mono das macht.

Aber in Eclipse ist es so, alles was du kompilierst wird erst einmal mit dem Debug-Key von Android rausgehauen,

Unter Tools -> AndroidTools -> Export Signed ApplicationPackage hast du die Möglichkeit das Programm mit deinem Key zu builden bzw. kann man sich dort auch einen eigenen Keystore und Keys anlegen.

Dieser Key ist insofern wichtig, damit GooglePlay Updates ect erkennt, du eindeutig als Developer bzw EIgentümer dieser App identifizierbar bist.

Das DebugZertifikat läuft immer nur für 1 Jahr, bei deinem eigenen kannst du selber die Dauer der Gültigkeit festlegen.

Wie gesagt das ist dein normalern Google Android App Key --> einen MD5 Fingerprint davon benutzt du ja auch für deine GoogleMaps um einen GoogleMaps ApiKey zu generieren

Hier noch mal ein Tut zum Prozedere:

http://www.androidhive.info/20…working-with-google-maps/

Ich weiss klingt jetzt vielleicht ganz blöd, aber du hast die App auch gesigned bzw. richtiger Key ???

-> Also ich habe hier bei mir 2 Google Keys .> einmal für den DEBUG-KEY und einmal für meine App welche ich mit Schlüssel signe

Wie sieht den deine Layout XML aus ?

<com.google.android.maps.MapView
	xmlns:android="http://schemas.android.com/apk/res/android"
	android:id="@+id/mapView"
	android:layout_width="fill_parent"
	android:layout_height="fill_parent"
	android:clickable="true"
	android:apiKey="hierdeinApiKeyeinfügen"
	/>

@Lucas: Ok du hast mich überzeugt bzw. nach deinen ausführlichen Darlegungen kann ich deiner Argumentation besser folgen.

Obwohl ich mich bei den Fragmenten immer noch streiten würde, ich sehe die ja weniger als Design-Missgriff,
sondern eher das sie es versäumt haben die Activitys von vorherein flexibel zu gestalten... aber das ist jetzt auch Haarspalterei

Zitat

Acessibility ist die Nutzung des Smartphones für behinderte Menschen, vornehmlich Blinde.

Klingt so als hättest du in diesem Punkt einen konkreten Ansatz bzw Erfahrung. Das fehlt mir natürlich komplett und da verstehe ich deinen Einwand oder auch Ärger wenn Google einfach die Menütaste sterben bzw. an ganz anderer Stelle wieder auftauchen lässt. (v2.x vs 4.x)

Du kannst die Optionen in deiner XML vorbelegen -> stichwort defaultValue

<?xml version="1.0" encoding="utf-8"?><PreferenceScreen xmlns:android="http://schemas.android.com/apk/res/android">  <EditTextPreference android:title="Your Name"                      android:key="username"                       android:summary="Please provide your username"></EditTextPreference>  <CheckBoxPreference android:title="Application Updates"                      android:defaultValue="false"                      android:summary="This option if selected will allow the application to check for latest versions."                      android:key="applicationUpdates" />  <ListPreference 	android:title="Download Details"                      android:summary="Select the kind of data that you would like to download"                      android:key="downloadType"                      android:defaultValue="1"                      android:entries="@array/listArray"                      android:entryValues="@array/listValues" />  </PreferenceScreen>

hier mal ein Tutorial zum ganzen Prefs quatsch

http://www.rominirani.com/android-preferences-tutorial/

Zitat

Eine Frage hätte ich aber noch. Kann man der footerbar.xml auch eine
Footerbar.java geben damit man nicht immer wieder die Codes in die
einzelnen .java's eintragen muss?

du kannst deine Initalisierungsroutinen -> findView ect..

in eine eigene Java-Klasse packen oder auch nur als Subroutine und diese dann wie gehabt einbinden/aufrufen, die Frage ist eher wie dynamisch soll das ganze werden, sprich Ändern sich die onClickhandler oder sind die für alle Ansichten immer gleich ?

@Lucas de Vil

du reitest die ganze Zeit auf UI Sachen rum, aber die SupportLib bietet bei weitem viel viel mehr.

http://developer.android.com/t…tras/support-library.html

Zitat

Genau so wie ich es beispielsweise hasse unter 4.x keine ActionBar zur
Verfügung zu haben rege ich mich tierisch darüber auf, unter 2.x
wertvollen Platz durch eine ActionBar verschwendet zu sehen.

häh ??? der Widerspruch in sich ... das verstehe ich jetzt nicht ... AB hast du doch unter 4.x ... obendrein du bist doch nicht zur Verwendung dieser Actionbar gezwungen, du bist doch bei GUI Gestaltung unter 2.x genauso frei wie unter 4.x ... -> Stichwort: Styles, Themes ect.

Zitat

Cross Platform Gedöns

nix mit Cross Platform - hier geht es lediglich um die unterstützung verschiedener Versionen/Revisionen ... die Platform Linux - Java Dalvik aka Android ist immer noch die selbe

Zitat

Sollte ich irgendwann einmal mit Fragments arbeiten wollen, könnte sich meine Meinung diesbezüglich gegebenenfalls ändern.

Allerdings halte ich sie aktuell nur für einen faulen Kompromiss für die Tablets.

Das ist etwas zu kurz gedacht, die Auflösungen der Handys nimmt zu bzw. gibt es ja auch Zwitter wie das Samsung Note,
Fragmente unterstützen dich halt wesentlich bei der besseren Nutzung der "Räume" welche größere Auflösungen bieten, indem sie mehr Flexibiltät mitbringen und die Kapselung (GUI/CODE) wesentlich transparenter machen. Das ganze mit herkömmlichen Views (für alle Varianten) zu coden ist ein Albtraum.

Zitat

Insgesamt ist das alles nicht so sehr durchdacht, wenn du mich fragst. Das kann ja sogar M$ besser.

<ironie an> deswegen laufen ja die alten Win95/Win98 Anwendungen noch so gut auf Win7 oder was </ironie aus>

Also Android ist ein Betriebssystem für mobile Platformen was sich in permanenter Entwicklung befindet, eben weil sich auch diese Platformen in einem wahnsinnigen Tempo verändern.
Da es kein geschlossenes System wie IOS ist und niemand die Hand auf der Hardware hat muss man halt damit leben das dies hier ein Prozess ist.... das weiss man aber bevor man Software für diese Platform anbietet

Ich bin froh das Android einiges tut um so kompatibel zu sein (Sup lib), bei meinem IPAd1 bekam ich letztens die lapidare Meldung .> du bekommst kein IO6 Update weil deine Platform nicht mehr unterstüzt wird -> einfach so. Ich hab "geschrien und geweint", aber es hat niemanden interessiert....

Anregungen

myWebView.getSettings().setJavaScriptEnabled(true);

Zitat

Also ich persönlich traue dieser Support Library ja so gar nicht über den Weg, aber das ist Geschmackssache.

Worauf fusst den diese Aussage ??? Hattest du schon mal Probleme mit der SupLib ?
Eigentlich kann man die Verwendnung nur jedem ans Herz legen, denn
wer hat schon Bock diverese Code-Base´s für 1 Projekt zu pflegen.

... ich bin da selber etwas nachlässig bzw. steht bei mir gerade die Optimierung für Tablets an, deswegen würde ich immer zur Nutzung von Fragments raten ... (geht ja dank Google Support Lib auch unter ANdroid v4)
das ist für die Zukunft dann wesentlich flexibler.