Beiträge von Marco Feltmann

Muenchen und Duesseldorf sind ziemlich sinnlose Schreibweisen, danach sucht doch niemand.

Ich habe einige Implementierungen des OnScreenKeyboards gesehen, welche die Umlaute nicht direkt verfügbar machen.
Viele Menschen haben aber keinen Bock ne gefühlte halbe Minute lang auf 'u' zu tippen bis 'ü' kommt sondern verlassen sich auf die Vorschläge der Autokorrektur.
Es wäre nur sinnvoll, bei der Suche entsprechende Nutzungsgepflogenheiten der User zu berücksichtigen.

Schmeiß den Filter weg.
Der Logeintrag kommt vom System, nicht von deinem Code. LogCat ist aber so eingestellt, dass es nur Ausgaben des Packages com.example.test anzeigt.
Sobald du 'All messages (no filters)' anklickst, sollte alles Mögliche auftauchen.

Jip, musst du.
Das kannst du sicherlich am Elegantesten über einen Eintrag 'Settings' im Optionsmenü lösen.

Sehr schön. Ja, daran kann es gelegen haben. Eigentlich soll requestFocus ja bedeuten, dass das Feld automatisch 'angewählt' ist. Vielleicht passierte das aber zu früh und deine Tastatur wurde deshalb nicht eingeblendet.

Hast du die EditTexte programmatisch oder im XML erstellt?

Wie sieht der Code dafür aus?
Eventuell gibt es ja irgendeine Einstellung, die das Aufpoppen der Tastatur verhindert. Mir kommt dieses Phänomen jedenfalls völlig unbekannt vor.

Zitat von Kogoro

Hi,
Wie wäre es wenn die Datenbank keine Umlaute enthalten und bei der Sucheingabe auch alle Umlaute entfernt werden?

Dagegen spricht vermutlich, dass die Inhalte aus der Datenbank auch dargestellt werden müssen. Und da sieht 'Munchen' einfach mal scheiße aus.

Leider fällt mir gerade keine andere Möglichkeit ein, als potenzielle Umlaute zu ersetzen.
Wenn also jemand nach 'Oberhausen' sucht, müssten folgende Schreibweisen berücksichtigt werden:
Oberhausen
Oberhäusen
Öberhausen
Oberhaüsen
Öberhäusen
Oberhäüsen
Öberhaüsen
Öberhäüsen

Mir erscheint das nicht sinnvoll.
Warum die Leute nicht nach den jeweiligen Umlauten suchen lassen?
Warum nicht nach Relevanz Suchvorschläge in einer Liste anzeigen?
'M' -> München, Moers, Mannheim...
'Ma' -> Magdeburg, Mannheim, Mainz...
'Mar' -> Marburg, Marienthal...

Ansonsten wird das sicherlich nur mit Ersetzung der Teilstrings funktionieren.

LogCat löscht eigentlich nix, es scrollt höchstens. Aber wenn du den Detail Level auf 'error' setzt, sollte das eigentlich gehen.

Wie dem auch sei, ich gehe davon aus, dass du nicht einfach mal mitten drin das Layout der Activity ändern darfst. Zugegebenermaßen habe ich das nie probiert, weil es einfach im Hinblick auf Kapselung widersinnig ist.
Du wirst wohl nicht um eine weitere Activity umhin kommen und musst ihr beim Aufrufen die Werte mitgeben.

Du solltest dir in LogCat anzeigen lassen, warum genau er abgestürzt ist. Das ist oftmals sehr informativ.

Vermutlich hast du eine neue Activity angelegt, die du aufrufen möchtest.
Besagte Activity musst du aber im AndroidManifest.xml auch Bekannt machen, sonst geht das nicht.

Nicht RAM, SD.
(also externe SD-Karte oder interner SD-Speicher voll)

Kogoro, ich finde es echt fein von dir, dass du diesen Beitrag ernst nimmst.
Auf mich wirkt das nur nach SEO und Werbung.

Zunächst mal würde ich alle Log-Möglichkeiten starten und schauen, warum der Browser abkachelt.
Wird vermutlich ein Speicherproblem sein.

Bei einer App, die nur Bilder auf einen Server lädt, sollte die Web App eigentlich das Mittel der Wahl sein.
Sonst musst du für eine derartige Kleinigkeit halt Android, iOS, Windows Phone und schlimmstenfalls noch Symbian unterstützen – welch Aufwand.

Spontane Idee in Bezug auf 'ging mal, geht nicht mehr':
Kann es sein, dass besagter Kunde zwar fröhlich Bilder schießt, diese aber niemals löscht?
Deine Web App dürfte ja wie folgt funktionieren:
- Kamera starten
- Kamera schießt Bild
- Bild wird im Gerät gespeichert
- gespeichertes Bild wird hochgeladen

Vermutlich werden die gespeicherten Bilder einfach nicht gelöscht.
Dann will Firefox Daten cachen und ablegen, kann es aus Mangel an Speicherplatz aber nicht und geht dann in die Knie.
Wäre zumindest ein Ansatz, den zu überprüfen ich für sinnvoll halte.

Reine Spekulation:
sollte die LocationClient Bibliothek mit auf den Location Manager aufbauen, dann gibt es da ein 'aber':

Zitat von Dokumentation zu LocationManager

Prior to Jellybean, the minTime parameter was only a hint, and some location provider implementations ignored it. From Jellybean and onwards it is mandatory for Android compatible devices to observe both the minTime and minDistance parameters.

http://developer.android.com/r…android.app.PendingIntent)

Es kann also tatsächlich sein, dass da was ignoriert wird.

Andererseits klingt das Problem mit dem Weglassen des requestLocationUpdates tatsächlich so, als würdest du anderweitig außerhalb des Clients (vielleicht direkt über den LcoationManager, also alter Testcode?) dieselbe Methode aufrufen.

Also im Allgemeinen schwören ja alle auf kleine Bilder.
Du könntest halt wie gesagt 25x 100px nehmen und kacheln. Dann ist es egal, wie groß die Texturen sein dürfen.

Oder du belässt es dabei, fängst die Exception ab, hoffst von der Exception die Informationen für die maximale Größe zu bekommen und lädst dann eine kleinere, passendere Version.

Dein Problem ist, dass die Implementierung deines Android maximal 2048x2048 Pixel große Bilder zulässt.
Das scheint ein 'Feature' von LG zu sein, das Nexus 4 von LG macht es ganz genau so.

Das bedeutet, dass deine Grafik mit den 2228 und 2700 Pixeln Breite einfach zu groß ist, als dass die Implementierung des OpenGL Renderers sie laden möchte.
Und dagegen kannst du nichts machen.

Du musst also irgendwie dafür sorgen, dass deine Grafiken maximal 2048x2048 Pixel groß sind. Eventuell teilst du die Grafiken einfach mit ImageMagick in 2 Hälften oder sowas.

Moin,

es gibt keine fixen Pixelgrößen für diese Graphiken. Die Endgeräte haben nämlich gefühlt 786.923 unterschiedliche Auflösungen.
Es gibt nur Mindestwerte, die bei der Bestimmung der Bilder eine Rolle spielen.
http://developer.android.com/g…ices/screens_support.html

Zitat

xlarge screens are at least 960dp x 720dp
large screens are at least 640dp x 480dp
normal screens are at least 470dp x 320dp
small screens are at least 426dp x 320dp

Weiterhin gibt es auch für andere Bilder keine Infos, da diese Größen einfach deinen Vorstellungen entsprechen.
Es gibt nur Richtlinien, wie die anderen Auflösungen von mdpi abweichen:

Zitat

ldpi Resources for low-density (ldpi) screens (~120dpi).

mdpi Resources for medium-density (mdpi) screens (~160dpi). (This is the baseline density.)

hdpi Resources for high-density (hdpi) screens (~240dpi).

xhdpi Resources for extra high-density (xhdpi) screens (~320dpi).

nodpi Resources for all densities. These are density-independent resources. The system does not scale resources tagged with this qualifier, regardless of the current screen's density.

tvdpi Resources for screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a "primary" density group. It is mostly intended for televisions and most apps shouldn't need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. If you find it necessary to provide tvdpi resources, you should size them at a factor of 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.

Alles anzeigen

Und als wäre das nicht genug:

Zitat

To create alternative bitmap drawables for different densities, you should follow the 3:4:6:8 scaling ratio between the four generalized densities.

Das bedeutet, davon ausgehend, dass deine mdpi-Grafik 48x48 Pixel (bei 160dpi) hat:
- ldpi = 36x36 (120dpi) = 75%
- mdpi = 48x48 (160dpi) = 100%
- hdpi = 72x72 (240dpi) = 150%
- xhdpi = 96x96 (320dpi) = 200%

Für Buttons empfiehlt es sich, mit ninePatch Grafiken zu spielen.
http://developer.android.com/tools/help/draw9patch.html

Da hast du dann eine Grafik, die sich automatisch den Auflösungen gemäß deiner Vorgaben anpasst.
Natürlich nicht zu empfehlen bei Buttons mit Texturen.

(Übrigens: Angaben sollten immer in dp [density-independet pixel; auflösungsunabhängige Bildpunkte] gemacht werden. Denn ein wirklicher Bildpunkt des Displays kann bei entsprechend guter Auflösung meinetwegen 9 dargestellte Punkte aufnehmen. Während anders herum sich bei einem schlecht auflösenden Display ein dargestellter Punkt über 9 Displaybildpunkte erstrecken kann.)

Ich hoffe, du benutzt nicht die SecureRandom Klasse von Android.
http://www.heise.de/security/m…droid-Patzer-1933714.html

Zitat von killphil75

Aeh wenn schon der erhobene Zeigefinger dann bitte richtig.

Ich fand meinen Hinweis auf IntelliJ IDEA schon richtig genug.

Das Studio benutze ich auch nur für kleinen Testkrams um halt auf Fehler zu prüfen.
Produktiv ist IntelliJ IDEA 12 im Einsatz.

Zitat von DNA

Für diejenigen, die den defacto Standard benutzen gibt's eine elegante Lösung für Punkt 1

Defacto Standard ist für mich, was der Urheber liefert.
Steht da etwa "based on IntelliJ IDEA" statt "based on Eclipse"? :o

Allerdings sprach ich nicht von Custom Foldings sondern einer sichtbaren Gruppierung.
Und die blöde Strukturübersicht ist der Meinung alles Top Down nach Alphabet sortiert darzustellen. Es ist also völlig egal, wie ich da meine Methoden im Code gruppiere, es wird nicht übersichtlicher.

Wo war das Problem? Zu früh initialisiert?

Ich benutze für sowas übrigens ACRA.

Meine Meinung soweit:

+ Im Großen und Ganzen tut die App genau was sie soll. Sehr solide.

- Beim Tippen der Nachricht wurde oftmals die Anzeige nach oben verschoben (meist bei einem Zeilenumbruch), so dass ich nicht mehr sehen konnte was ich bereits geschrieben hatte.

- Die Auswahl im ersten Screen finde ich ein bisschen seltsam gelöst. Mag aber Gewohnheit sein.

---

Und noch meine ganz persönliche Note dazu:

- Ich HASSE Passwortabfragen. Damit abstrahierst du nur das ursprüngliche Problem: jemand öffnet das Bild in deiner App und kennt das Passwort nicht.
Mit der App kannst du also folgendes tun:
• du findest heraus, ob ein Bild verschlüsselten Kontent enthält
• du bekommst so lange den Hinweis 'falsches Kennwort', bis du das richtige Kennwort eingibst

Im Prinzip hast du also nur das Problem des 'verschlüsselten Containers' von einem Ordner/Zip/PDF in ein Bild gepackt.

Damals™ hatte ich auf meinem Sony Ericsson Z610 eine App names 'Datentresor', die einen gänzlich anderen Ansatz verfolgte. Du hast deine Daten mit einem vierstelligen Zahlenpin 'verschlüsselt'.

Beispielsweise hast du deinen Eintrag 'Kreditkartennummer' mit Inhalt 5467 7897912 3123 mit der PIN 4711 verschlüsselt.
Wenn jetzt jemand hin ging, die App öffnete und 'Kreditkartennummer' anwählt, wird er nach der PIN gefragt. Gibt er 0815 ein, dann rödelt das Programm eine Weile und spuckt dir beispielsweise 0912 7953721 0931 aus. Und mit 1337 rödelt er wieder und liefert 1254 9873893 8893 zurück. Nur mit 4711 kommt wirklich 5467 7897912 3123 dabei raus.

So etwas finde ich cooler. Klar, jeder Depp erkennt, dass 0912 oder 1254 keine gültigen Kreditkartennummern sind. Bei anderen Daten wie beispielsweise deinem Rechnerkennwort, deiner Geldkarten-PIN oder deiner geheimen Antwort zur Kennwortzurücksetzung bei PayPal ist das nicht so offensichtlich.
Merke: viele nutzlose Informationen sind ein wesentlich besserer Schutz als wenige nützliche Informationen. (Und 'Falsche PIN' ist eine nützliche Information.)

So hättest du 9.999 falsche und 1 richtige Information. Beim Hinweis mit dem Passwort hast du im schlechtesten Fall 9.999 nützliche und eine richtige Information.
Schlimmer noch: dank der nützlichen Information weißt du ganz genau, welche die richtige Information ist.

Also als Feature Request:
* lass die App SÄMTLICHE unterstützten Bilder öffnen, egal ob mit verschleiertem Inhalt oder nicht. Es wird lustig, wenn Hacker versuchen Nachrichten in Bildern zu finden, die keine enthalten.

* Nutze an Stelle eines Kennwortes (welches sicherlich irgendwo in den gespeicherten Daten im Bild stehen wird) lieber eine PIN, die du nicht mit hineinschiebst. Denk dir zu jeder möglichen PIN-Eingabe (sind ja bloß 10.000...) einen Verschiebemodus aus. (Keine Ahnung: 0123 = 1. Zeichen 10 Bit weiter, 2. Zeichen 1 Bit weiter, 3. Zeichen 2 Byte weiter, 4. Zeichen 3 Bit weiter und von vorn).
Dann baust du beim Verschlüsseln die Eingabe entsprechend um und sie sind nicht mehr aus dem reinen Bild extrahierbar. Beim Entschlüsseln drehst du einfach die Richtung je nach Eingabe und zeigst es an. Dann schleppst du das Kennwort auch nicht mehr in der Datei mit.
(Denn merke: Hacker haben die Angewohnheit, erst einmal alles durch einen Hex-Editor laufen zu lassen. Und wenn die dann ein Muster finden haben sie nicht nur den Inhalt sondern auch das Kennwort.)
Natürlich kannst du den Algorithmus verkomplexidieren. Also wenn Position 1 = 0 dann 10 weiter, Position 2 = 0 wären 5 zurück, Position 3 = 0 wären 10 zurück und Position 4 = 0 wären 3 weiter...
Oder Position 1 gibt an in welchem Bit die Daten stehen (auf 4 runterbrechen), Position 2 die Verschiebung des ersten eingegebenen Zeichens, Position 3 die Verschiebung aller geraden Zeichen gemessen an der Startverschiebung und Position 4 die Verschiebung aller ungeraden Zeichen gemessen an dieser Startverschiebung.
Wichtig ist in dem Fall nur, dass du das vernünftig hin und her geschoben bekommst.

---

Soviel zur Kritik.
Die Interaktion mit den Austauschmöglichkeiten Alben/Kamera/Dateisystem/Dropbox finde ich astrein gelöst. Gefällt mir wirklich gut.

[hns]
Ich fürchte eine Offenlegung des Codes wäre nicht so toll. Man würde sehen, an welcher Position das Kennwort gespeichert ist, ob und wo Infos über die Art der Verschlüsselung gespeichert sind und in welchem Bit die Infos stehen. Damit könnte man dann auch problemlos wenigstens die Kennwörter solcher Bilder erschnüffeln oder unter Umgehung dieser 'Sicherheitsmaßnahmen' ein eigenes Entschlüsselungstool verbreiten.

Wenn der Inhalt dieses Bildes hier rauskommt sitz' ich vermutlich im Knast.
Allerdings habe ich mein eigenes Kennwort vergessen, insofern...

// Nachtrag: Och, obwohl das Ding so arg verkleinert wurde ist der Zerg Creep immer noch gut zu erkennen. Na denn. =)