Selber mit Pfaden zeichnen und prüfen, ob innerhalb dieser Pfade berührt wurde.
Aber ich sehe gerade, das ist unter Android gar nicht so einfach…
Du kannst Dir das ein bisschen zurecht mogeln:
http://stackoverflow.com/a/2597702
Selber mit Pfaden zeichnen und prüfen, ob innerhalb dieser Pfade berührt wurde.
Aber ich sehe gerade, das ist unter Android gar nicht so einfach…
Du kannst Dir das ein bisschen zurecht mogeln:
http://stackoverflow.com/a/2597702
Ich verzweifle grad mal wieder hieran.
Ursprünglich habe ich einfach die 0 Werte ignoriert, auf sinnvolle Werte gewartet und bin dann erst das Layout durchgegangen.
Nun habe ich aber das Problem, dass beim Wechsel vom Landscape in den Portrait Modus für einige Elemente onMeasure() nur ein einziges mal mit den unsinnigen Werten aufgerufen wird. Meine aktuelle Implementierung nutzt dann natürlich den letzten bekannten Wert, also die Höhe aus dem Landscape Modus.
Und die ist für den Portrait Modus natürlich um Längen zu niedrig. +seufz+
Dabei will ich doch nur fullscreen und möglichst ohne eigenen Aufwand je nach Modus 2x6 bzw. 3x4 Views darstellen.
Offenbar ist GridView da aber doch das völlig falsche Element für.
Ich versuche es mal mit dem Dashboard Layout…
Es ist mit dem Pseudo-Code ein bisschen schwierig, da Du zwei mal von xy schreibst.
Da weiß man irgendwie nicht so recht, was was ist.
Theoretisch geht das so, ja.
Praktisch brauchst Du den korrekten Pfad zum Bild, und der kann tatsächlich je Gerät unterschiedlich sein.
Soweit ich weiß gibt es auch keine HTML-Kürzel zum Abfragen des Speicherortes.
Was ich mir aber vorstellen kann (ist alles Andere als sicher…), ist, dass Deine App den Speicherort ihres Assets selbst herausfindet und den als Parameter an Deine Website übergibt, die dann nichts weiter macht, als diesen Speicherort vor den Bildnamen zu setzen.
Irgendwie so:
<!DOCTYPE HTML>
<?
// Default image path if no path was provided. Should be the online image directory.
$imagePath = './images/';
if(is_set($_GET['image_path']) {
$imagePath = $_GET['image_path'];
}
?>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Hallo</title>
</head>
<body>
<center><img src="<? echo $imagePath; ?>test.jpg"></center>
</body>
</html>
Alles anzeigen
Eine andere Idee habe ich gerade nicht.
Perfekt. Gern.
Das ist zwar nicht unmöglich, aber nahezu ausgeschlossen.
Zumal es gemäß Log ein Problem in den Tiefen von Eclipse gibt, das nicht auf fehlende/defekte Ressourcen zurückzuführen scheint.
Das ganze Layoutwegzuwerfen bringt nicht viel, auch wenn ich in einem ganz neuen Projekt nen Textfeld einfüge tritt der Fehler auf.
Für mich ein eindeutiges Zeichen, dass irgendwas mit Eclipse nicht stimmt.
Also da dürfte kein Fehler sein.
Kannst Du den kompletten Inhalt der activity_main.xml posten?
Kannst Du notfalls das graphische Layout wegwerfen und neu schreiben?
('Layout lässt sich nicht bearbeiten' klingt sehr nach einem Eclipse Fehler. Läuft das auf dem Gerät oder im Simulator? Hast Du IDE und SDK aktualisiert?)
Wenn die Chinesen eines können, dann hochwertige Ware um teure Komponenten zu kürzen und billig zu produzieren.
Gefühlt 80% aller Akkus werden in China produziert, ungefähr 60% aller Mobiltelefone auch.
Warum sollten sie also nicht ein HTC kopieren und einen kopierten Samsung-Hochleistungsakku rein setzen?
Hast Du auch irgendeinen Code geschrieben? Von allein sollte jedenfalls java.lang.System.arraycopy nicht aufgerufen werden.
Ich glaube, ich verstehe Deine Frage nicht.
Natürlich sind 5000mAh Akkus möglich. Gibt es beispielsweise auch fürs Galaxy Note.
Es gibt beispielsweise fürs Galaxy SIII auch einen 7200mAh Akku.
Ich bin mir nicht sicher, dass 'static' das richtige Schlüsselwort für Deine PreferencesActivity ist…
Ja, das Packen ohne zlib ist auf Unix Systemen nicht so ganz simpel.
Warum gibt es denn davon keine 64 Bit Version?
Abschnitt Task Gallery vergessen oder falsch implementiert?
Beachte vor Allem:
ZitatNote: If you saved your photo to the directory provided by getExternalFilesDir(), the media scanner cannot access the files because they are private to your app.
Ich kürz Dir das mal auf Pseudocode entsprechend zusammen:
solange eventType nicht Ende vom Dokument
falls Start vom Dokument
// neuen Platzhalter für die kommenden Objekte zusammenschustern.
falls StartTag
wenn name ist gleich 'notification'
// erstelle neues Notification Objekt
ansonsten
wenn name ist gleich 'id'
// id des Notification Objekts setzen
sonst wenn name ist gleich 'title'
// title des Notification Objekts setzen
sonst wenn name ist gleich 'description'
// description des Notification Objekts setzen
sonst wenn name ist gleich 'type'
// Ab hier spare ich mir die Kommentare…
sonst wenn name ist gleich 'creator'
// …
sonst wenn name ist gleich 'time'
// …
sonst wenn name ist gleich 'date'
// …
falls EndTag
wenn name ist gleich 'notification'
// aktuelle Notiz hinzufügen
Alles anzeigen
Vielleicht wird Dir jetzt etwas klarer, was der Code ungefähr tut und wo Du eingreifen solltest.
Saubere App-Vorstellung, gefällt mir.
Ein Freund von mir ist bei der Organisation eines Fun-Events etwas außerhalb des nahen Zürichs (also in Hamburg ^^) beteiligt.
Für ihn ist das bestimmt was.
Offensichtlich ist das Ganze ja eine Kombination aus Webauftritt und App.
Wickelt Ihr die Ticketverkäufe direkt über eure Plattform ab, oder lasst ihr das von einem TÜV-zertifizierten Partner erledigen?
Wie oft und wie viele Anfragen Du schicken möchtest bleibt Dir überlassen.
Natürlich kannst Du aus den Eingaben des Benutzers jedes Mal beim Erreichen einer Zielposition die nächste Route berechnen lassen.
Interessant ist in dem Zusammenhang eigentlich nur, wie Du herausfindest, ob das Ziel erreicht wurde.
NFC wenn es eine Schnitzeljagd App werden soll) wäre auf jeden Fall genauer, aber für den Nutzer auch unbequemer als GPS.
Moin N.!
Ich habe Dein Spiel mal angetestet und muss sagen, für mich ist es nichts. Ich bin VIEL zu langsam.
Auf meinem 'kleinen' Display sah der Highscore von '11' ein bisschen albern aus, da beide 1 untereinander standen.
(1920x1080 XHDPI)
Die Info bezüglich des Scheiterns sieht als Alertbox aus ziemlich gewöhnungsbedürftig aus.
Mir persönlich wäre da ein an das Spieldesign angepasstes Interface lieber.
Allerdings weiß ich auch gar nicht, ob und in wie weit das mit Xamarin Studio überhaupt möglich ist umzusetzen.
Moin,
mir ist keine Funktionalität in der Google Maps v2 Android API bekannt, mit der sich Routen planen lassen.
Eventuell wirst Du da was mit der Google Maps v3 Javascript API. Allerdings kann diese jeweils nur einen Start- und einen Endpunkt entgegen nehmen.
Dementsprechend musst Du aus Deiner einen Route mit insgesamt 3 Zwischenzielen drei Routen mit je einem Ziel machen.
Also statt
standpunkt -> uni -> mensa -> kneipe;
eher ein
standpunkt -> uni; uni -> mensa; mensa -> kneipe;
(Die Google Maps API v3 gibt es [noch] nicht als Bibliothek für Android, v2 ist da leider die aktuelle Version.)
Ich möchte mir an dieser Stelle ein bisschen Luft machen über die Unsäglichkeit des App Exportes via Eclipse.
Mein Projekt, das gerade in einer Betaphase steckt, wird über den Google Play Store vertrieben und benutzt zwei Komponenten, die in C geschrieben und über das Java Native Interface mit dem UI verbunden sind.
Beta #1 – alles läuft
Beta #2 - UnsatisfiedLinkError auf einigen Geräten
Lange Rede gar kein Sinn: 'einige Geräte' waren alle ARMv7 Varianten, also ungefähr alles so ab Galaxy SIII abwärts…
Da ich hier einerseits viele ARMv7a Geräte habe und andererseits natürlich auf allen möglichen Geräten das Debug-Build teste, ist mir dieser lustige kleine Fauxpax natürlich auch gar nicht aufgefallen.
Ende vom Lied: der lustige Eclipse Exporter packt in mir völlig unerklärlichen Anwandlungen nicht immer alle aus dem Native Development Kit gebauten Libs mit in seine resultierende App.
Das hatte in dem Fall zufolge, dass eine der zwei Bibliotheken nur für ARMv7 (Unterordner libs/armeabi/) fehlte. Dementsprechend konnte die auf dem Gerät natürlich bei Programmstart auch nicht geladen werden.
Also, wenn ihr mit dem NDK und Eclipse entwickelt:
immer schön die Augen aufhalten, ob auch wirklich alle eure kompilierten Bibliotheken ihren Weg in das fertige APK gefunden haben.
Damit erspart ihr euch sicherlich mindestens zwei Stunden Herumgesuche.