Beiträge von UweApps

Du kannst auch die ArrayList mischen mit Collection.shuffle(allItems) - wenn du es einfach haben willst.

@Lucas:
In Java ist fast alles ein Zeiger - außer den Basis-Typen. Darum braucht man nicht extra davon zu reden, das spart viel Verwirrung beim Erklären von Java... *g*

ok - dann werde ich den Satz oben mal etwas entschärfen, statt "Niemals" jetzt "Möglichst nicht". *g*

Klappt es auch beim scrollen und wenn du die Orientation änderst?

Ich finde eine Lösung ohne ListView besser, wenn man mit Eingabefeldern arbeitet.

ListView ist perfekt bei sehr großen Listen oder wenn man vorher nicht weiß, wieviel Einträge da sind.

Noch mal eine kurze Antwort:

Möglichst nicht den EditText in einen ListView packen!

Oder viel Hirmschmalz auf ständige Sicherung und Wiederherstellung des Inputs verwenden (onKeyPress auswerten und Input zusammenbasteln).

Gilt ähnlich auch für andere Eingabefelder mit Tastatur oder Dialog (Spinner, DatePicker etc.).

Der ListView erzeugt seine Teile sehr häufig neu, z.B. beim scrollen, Tastatur oder Dialog ein-/ausblenden etc.pp...

Besser mit ScrollView / LinearLayout oder anderen Widgets das Layout zusammenbauen.

Wenn du unbedingt 'nen ListView haben willst, brauchst du auf jeden Fall eine ArrayList<String> o.ä. zur Zwischenspeicherung der Eingaben.

Ich hab mir die Seite da mal angeschaut - das scheint ja ein größeres Paket zu sein. Durchaus möglich, dass für die Funktionalität auch das NDK gebraucht wird. Aber schau noch mal dort die Tutorials an - vielleicht hilft dir das weiter...

Hallo Lucas,

zunächst brauchst du natürlich ein Test-Projekt, normalerweise sollte dir die IDE ein "Android Test Project" als Auswahl für ein neues Projekt anbieten. Das ist dann eine fast normale App, der das zu testende App-Projekt zugeordnet wird. Dies Test-Projekt muss aber über "Android JUnit Test" gestartet werden - nicht als "Android Application", ist ja keine App.

In dem Projekt musst du die Klassen dann selber anlegen - automatische Test-Klassen- oder -Methoden-Erzeugung in Android hab ich bisher nicht gesehen.

Wenn es um Tests für einfache Klassen geht, dann ist TestCase die Klasse, von der du erben solltest. Und da läuft eigentlich alles wie bei normalem JUnit-Testing. Vielleicht noch MoreAsserts für etwas mehr Komfort.

Wenn du einen Context brauchst (z.B. Datenbank), dann ist AndroidTestCase deine Eltern-Klasse.

Und falls du eine Activity oder App testen willst, dann ist ActivityInstrumentationTestCase2<DeineKlasse> nötig. Um mit der UI umzugehen, empfehle ich dringend Robotium, da die UI-Zugriffe sonst etwas unhandlich sind.

Falls du später mal gucken willst, ob deine Tests auch den Code abdecken - dafür ist Emma bereits in dem Android-SDK eingebaut.

Speicherverbrauch und Timing sind eigentlich über andere Klassen abzurufen - musst halt gucken, was du auswerten willst.

Viel Erfolg!
Uwe

Wenn du mit 'ner eigenen App an die Sache rangehst, ist es natürlich einfacher. Dann kann dir der TelephonyManager die Info über die aktuelle Netzanbindung liefern.

Vielleicht ist im aktuellen JS auf dem Smartphone ja auch ein Parameter oder eine Methode dazu zu finden, viele andere Sachen lassen sich auf HTML5/JS-Basis ja auch nutzen...

Nachtrag:
zuerst hatte ich "sum += j % 10 + 1;" - muss natürlich "sum += j % 9 + 1;" sein, ich hab es im vorigen Beitrag auch korrigiert.

Und noch was zum Thema Sonderzeichen: einmal gibt es die Umlaute, wobei ein ß im Namen eher selten ist - eher taucht schon mal ein é auf (z.B. René). Da wirst du dann wohl keine so schöne Lösung finden.

Am besten geht da wohl eine Ersetzungstabelle als HashMap<Character, Integer> mit den Sonderzeichen und den Werten, die du dafür einsetzen willst.

Übrigens braucht HashMap Objekte, darum Character statt char und Integer statt int - aber die sind mit Character.valueOf(char) und Integer.valueOf(int) schnell erzeugt - das Addieren geht aber problemlos mit gemischten int und Integer.

Vor einigen Jahren hat die Europäische Kommission mit großem Tamtam die Gerätehersteller aufgefordert, kompatible Ladegeräte herzustellen (EN 62684). Leider ist die Aktion nicht unbedingt von allgemeinem Erfolg gekrönt.

Wenn das Aufladen am USB-Port des PC klappt, dann sollte es auch mit anderen Varianten funktionieren - aber ich wäre da auch lieber vorsichtig...

Sonst google mal nach "ladegeräte kompatibilität" - vielleicht hilft dir das weiter.

@Lucas:
Es gibt auch lustige Schaltungen, die einfach mal aus 12V= runtersetzen auf 5V= und das auch mit geringen Verlusten. Übringes geht so was sogar umgekehrt, mehr dazu auf Wikipedia.

So eine Formulierung findet man öfters, meistens genügt es dann, den normalen Download zu installieren - nach Anleitung! Wichtigster Schritt dabei ist das Kopieren der .jar-Datei in das libs-Verzeichnis deines Projekts (evtl. anlegen) und die .jar-Datei zum Build-Path zufügen. Für deine Zwecke sollte diese Variante passen.

Wenn du aber noch was am Alljoyn verändern oder verbessern willst, kannst du den Quellcode auch gerne bearbeiten und kompilieren - darauf bezieht sich der zweite Teil. Typisch bei OpenSource-Projekten!

Stimmt - sieht zwar nicht so schön aus, aber müsste funktionieren.

Vielleicht hilft noch ein anderer Ansatz: der Modulo-Operator!

Dann wäre das ungefähr so (ungetestet):

//String arbeitsname wird übernommen
int j;
int sum = 0;
String myString = arbeitsname.toUpperCase(); // nur Großbuchstaben
for (int i=0; i < myString.length();i++)
{
    j = (int) myString.charAt(i) - (int) 'A'; // auf 0-25 reduzieren
    if ((j >= 0) &&  (j < 26)) // 
    { 
        sum += j % 9 + 1; // dies ist die Tabelle - mathematisch gesehen. *g*
    }
}

Ob du die (int)-Casts in der j = ...-Zeile brauchst, weiß ich nicht, ich hab's mal drin gelassen.

Für die Quersumme hilft dir auch der Modulo-Operator:

while (sum > 10) {
    sum = sum / 10 + sum % 10; // Quersumme der letzten Stelle - while für den Rest
}

Hallo Lucas,

meine erste Idee ist, die SupportLib in dem Library-Projekt zu installieren und für die anderen Projekte mit "Verknüpfung anlegen" im Dateimanager eine Referenz erzeugen und diese in die anderen Projekte kopieren und den Namen korrigieren.

Aber es ist wirklich so - entweder SupportLib in Library-Projekt und App-Projekt mit derselben Version überall oder ganz ohne SupportLib arbeiten.

Ich kopiere die Datei immer in die Verzeichnisse rein und packe sie dann auch in das Versionsmanagement (Subversion), dann hab ich zwar manchmal etwas Kopierarbeit, wenn die SupportLib eine neue Version bekommt, aber das ist dann doch relativ schnell erledigt.

Gruß Uwe

Hi Lucas,

LinearLayout als allgemeine Aufteilung für die Seite ist schon der richtige Ansatz - aber für variable Listen immer den ListView verwenden.

addHeaderView bei ListViews ist problematisch, da der Header in die Zählung der Items mit einbezogen wird - darum lass lieber die Finger davon, besonders wenn du einen eigenen ListAdapter definierst.

Die Kurzbeschreibung besteht m.E. aus zwei TextViews: dem Titel und dem ausklappbaren Infotext. Dieser Infotext-TextView braucht noch einen ScrollView als Container mit fester Höhenangabe. Und mit setVisibility den ScrollView im onClickListener des Titel-TextView umschalten zwischen View.GONE und View.VISIBLE.

"Variable Liste" - ist das eine Überschrift? Dann auch ein TextView im LinearLayout.

Und dann halt ein ListView für die Liste...

Grüß Uwe

Für mich ist beim Testen immer mein billiges Galaxy Y das Maß der Dinge - meine Apps sollen ja auch auf langsamen Geräten gut laufen.

Aber die Zahl der AsyncTasks ist wirklich eine Sache, wo man experimentieren sollte - auch wenn nur ein Prozessor da ist. Beim Zugriff auf die SD-Karte macht das vielleicht nicht so viel Unterschied, aber bei Netzwerkzugriffen kann das schon mal viel ändern (lange Reaktionszeit des Servers bei kleinen Datenmengen).

Ih stimme auch für "Datei" zum Datenaustausch.

Nur beim Format würde ich noch mehr investieren, wenn du den Nutzern das Ändern per Hand etwas erleichtern möchtest. Formate wie JSON oder XML sind besser lesbar und auch in der Verarbeitung etwas sicherer.

Denn wenn jemand was ändert oder mit Copy/Paste arbeitet, könnte mal etwas zu viel oder zu wenig mitkommen und dir deine internen Daten zerbröseln. Dann schon lieber eine Exception vom Parser abfangen und einen Fehler-Toast anzeigen.

Häufig wird bei so was ja auch ein Dialog mit Checkbox und OK eingeblendet - aber statt eines Flags würde ich eine Versionsnummer speichern, dann kannst du deinen Inhalt auch mal ändern und die Leute müssen es dann erneut bestätigen.

Zum Speichern würde ich auch auf jeden Fall die SharedPreferences nehmen - dann bleibt die Einstellung erhalten, außer die Nutzer klicken in den Einstellungen für die App auf "Daten löschen". Ein Eintrag in einer PreferenceActivity / menu.xml braucht aber nicht implementiert werden - macht ja nicht so viel Sinn, daran noch was rumzustellen.

Bei Begrüßungsmeldungen könnte man dagegen schon mal eine Einstellung in einer PreferenceActivity spendieren nach dem Motto "show startup message".

Den Link werde ich mir auch noch mal genauer anschauen - so ein ähnliches Problem hab ich auch, aber mit meiner Lösung bin ich noch nicht zufrieden.

Aber einen Hinweis zum Stichwort "AsyncTasks": wenn du gleichzeitig alle Tasks startest, dann werden die wohl alle ziemlich beschäftigt sein und irgenwann mal fertig werden. Da solltest du lieber eine AsyncTask machen, die eine Warteschlange benutzt um eine Liste von Bilder zu verwursten. Dann kommen die alle der Reihe nach und es sieht flüssiger aus.

Wenn du dann noch die Zahl der Prozessoren abfragst, kannst du ja ein paar mehr AsyncTasks machen, um die Last zu verteilen - da kannst du gerne rumtesten, was am schnellsten läuft.

Sehr interessante Frage - musste ich gleich mal die Doku wälzen und bin auf zwei Punkte gestoßen, die dir vielleicht weiterhelfen:

Application ist auch eine der vielen Context-Klassen, aber mit sehr wenig Eigenschaften, außer dass sie gerade mal eine Application ist, die von ein paar Sachen erbt, die von außen interessant sind. Und die Doku sagt dazu:

Zitat

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

Der zweite Punkt ist aber der spannende: es gibt eine Klasse die von Application ableitet, und zwar die MockApplication. Und die ist für Testzwecke sehr sinnvoll, weil sie eine andere App simulieren kann. Damit kann deine App dann gucken, ob die MockApplication da ist und ein paar Sachen von ihr abfragen. Die MockApplication hat nämlich einiges geerbt, aber schmeißt für alles Fehlermeldungen, außer du hast die Methoden selber implementiert. Die Doku zu Testing Fundamentals gibt leider nur sehr knappe Hinweise zu dem Thema.

Benutzt hab ich das zwar noch nicht, aber mir kommen da gerade mal ein paar Ideen, weil ich in einigen meiner Apps auch mal Mails verschicke oder Telefonnummern per Intent verschicke - aber beim Testen will ich ja gar nicht telefonieren...

Gibt auch eine schöne App mit vielen Beispielen und den Code dazu kann man auch gleich laden: Android UI Patterns.

Mir fehlt in der Diskussion noch das Stichwort "Service" - wo schon dauernd von Hintergrund gesprochen wird.

Ist zwar immer in bisschen kompliziert, sich mit dem Service zu verbinden, aber dafür hat man eine Instanz die sich um den Hintergrundkrempel kümmert und auch noch aktiv bleibt, wenn die Activity durch z.B. eingehenden Anruf mal vom Schirm verschwindet.

Außerdem kannst du den Service dann mit einem Timer versehen, der die verschiedenen Start- und Stop-Zeiten alle kennt und damit den Gesamtüberblick über den Zietablauf hat.

Bei Layouts geht das erst mal nicht so ganz - normalerweise wirst du auch nicht die Layouts aus der Lib im App-Projekt einbinden, sondern die darüber liegenden View-Klassen (bei Custom Components) oder die Fragments / Activities aus der Library.

Aber es gibt was anderes, was dir bei Layouts und deren Flexibilisierung helfen kann:

<include layout="@layout/layout_resource"/>

Damit kannst du Layout-Schnipsel in verschiedenen Layouts einbinden (z.B. Werbeeinblendung) - aber wenn du dafür Einstellungen machen möchtest oder auf Inhalte zugreifst, musst du das in den Activities / Fagements / Custom Views jeweils wieder einbauen - aber dafür könnte man sich auch noch eine Hilfsklasse bauen, die diese Aufgaben übernimmt.

Für solche includes kann man in der layout_resource.xml als oberstes Container-Element auch <merge...> verwenden - dann spart sich das System eine Ebene im Layout-Baum. Dazu gibt's auch was von Google.

Ansonsten kannst du auch viele Sachen, die in dem Lib-res-Ordner gespeichert sind, einfach überschreiben im App-Projekt, aber nicht alles. Normalerweise sollte dir Eclipse Bescheid geben, wenn du was Unerlaubtes machst. Die aktuelle Version vom Android-SDK prüft viel besser als frühere Versionen (Android-SDK-Manager nach Updates suchen lassen!).