Beiträge von Marco Feltmann

    Also rein theoretisch müsste das gehen.
    Eine App für das tel:// URL Scheme registrieren, Apps wie NoTelURL erlauben die App zu starten und diese App schaut dann einfach, ob die Telefonnummer die gewünschte Nummer ist. Falls nicht irgendwie an die normale Telefonapp weiterleiten.


    Allerdings weiß ich nicht genau, wie die Weiterleitung an die normale Telefonapp funktionieren könnte.
    Und mein Spieltrieb hält sich auch in Grenzen. ;)


    Eventuell mal den Entwickler von NoTelURL fragen, wie er das mit der Weiterleitung gelöst hat.
    (Einen Sourcecode finde ich nicht.)

    Jip, ISO Standarddatum in die Datenbank packen (dafür ist es ein Standarddatum) und dann via SimpleDateFormat formatieren lassen.
    Aus einem einfachen Grund: SimpleDateFormat erstellt dann die gewünschte Datumsdarstellung gemäß der Landeseinstellung des Gerätes automatisch.


    Ich habe keine Ahnung, wie 2009-05-30 in Arabien, Südkorea, Somalia oder Kleinostheim angezeigt werden soll.
    Die Jungs von Android haben einfach Araber, Südkoreaner, Somali und Kleinostheimer gefragt und das in ihre Systemfunktion einfließen lassen. ;)

    Moin Claus,


    ich glaube Du suchst die android.app.ActionBar, die Du in Deiner Activity via getActionBar() bekommst.
    Zumindest hoffe ich, dass Du ein halbwegs aktuelles Android voraussetzt. ;)


    Wie sich das Ding am Einfachsten manipulieren lässt weiß ich allerdings auch nicht so aus dem Kopf.
    Es bietet zwar eine setBackgroundDrawable(Drawable), allerdings habe ich keine Idee ob sich diese Drawable einfach aus einer Farbe heraus erstellen lässt.
    (In Anlehnung an [UIImage imageWithColor:])


    Ha, grad geschaut.
    Typ android.graphics.drawable.ColorDrawable; Methode ColorDrawable(int color)


    Damit sollte zumindest der erste Teil möglich sein.


    Eventuell kannst Du über eigene Theme Extensions auch noch die Textfarbe beeinflussen, aber das übersteigt meine Erfahrung.


    Die übliche Einstiegsliteratur:
    Action Bar Design Guides
    Action Bar Design Patterns
    Action Bar Basic Training


    Gruß Marco

    Im verlinkten Tutorial wird ungefähr das gemacht, was Du möchtest.
    Halt mit der ListView.


    Wenn Du da lieber selbst auf alternativen Pfaden herumprobieren möchtest, dann kannst Du das gern tun.
    Allerdings werde ich Dir dann nicht weiter helfen können, da ich immer den erprobten Standardweg nehme.

    Klar, eins nach dem anderen. :)


    Mit der Umsetzung des JSON API Standards entsprechend Deiner Anforderungen wirst Du sicherlich schon ein bisschen beschäftigt sein.
    Das ebnet Dir den Weg aber schon ganz gewaltig. :)

    Sehr gut, ich hätte nämlich spontan Weg #4 vorgeschlagen. :)


    Beziehungsweise wäre ich Weg #4a entlang geschlendert: Statt statischer XML Datei eine schöne dynamische JSON Datei.


    Die Anfrage an den Server würde dann lauten: GET https://kantine/tageskarte/?kw=41
    (Davon ausgehend, dass Dein Server automatisch die index.[php|py|rb] ausführt und Dein DNS 'kantine' entsprechend auflösen kann.)


    Hier kannst Du dann schön auf der Website arbeiten. Liegen beispielsweise noch gar keine Werte für KW41 bereit, liefert Dein Server ein HTTP404 zurück, am Besten mit der Fehlermeldung 'Noch keine Daten für KW 41'.


    Weiterhin kannst Du bei jedem Appstart prüfen, ob eine neue KW angefangen hat. Letzte abgerufene KW in den SharedPreferences ablegen, gucken ob bereits 'erster Tag der Woche' ist, und wenn ja und die Kalenderwochen unterscheiden sich, Anfrage starten.


    Und Du kannst zusätzlich das manuelle Update beim Herunterziehen der ListView einbauen. Dann umgehst Du einfach die Prüfung (schreibst die aktuelle KW aber natürlich trotzdem in die SharedPreferences).


    Selbstverständlich kannst Du für die fremdsprachigen Kollegen auch noch einen Parameter 'languageIdentifier' mitgeben und die Daten passend lokalisiert auf deren Telefone landen lassen.


    Der Clou: Orientierst Du Dich beispielsweise am JSON API Standard v.1, kannst Du mit weniger Overhead als im XML wirklich komplexe Objektstrukturen und -graphen übertragen.


    Deine Liste könnte beispielsweise so aussehen:


    Daraus baut Dir beispielsweise der GSON Parser dann eine schöne Mischung aus Dictionaries und Arrays und Du kannst das ziemlich schmerzfrei benutzen.


    Ablegen (wenn Du cachen möchtest) solltest Du sie entweder im öffentlichen Downloads Ordner oder im Datenordner Deiner App.
    Über die Funktionen Context.getCacheDir() und Context.getFilesDir() kommst Du an die internen Ordner, über Environment.getExternalStoragePublicDirectory(type) an die externen Ordner.


    In die res/values kannst Du die Daten jedenfalls nicht packen, da Dein Package digital signiert wird. Spielst Du in dem Ordner rum, ändert sich tatsächlich der Bytecode nach der Kompilierung und Deine digitale Signatur wird ungültig.


    Die Darstellung kannst Du simpel via ListView regeln.


    Die Hauptarbeit besteht hier eigentlich gar nicht so sehr in der App, sondern in den Vorüberlegungen. ^^
    Ein Jahrhundert wirst Du dafür sicherlich nicht brauchen.
    Bei mir wären es ohne JSON API Implementierung auf dem Server mit allen relevanten Tests ungefähr 20 Stunden, wobei natürlich Icon Design etc. fehlt.
    (Außer einem App Icon und weitere Icons wie 'vegetarisch', 'scharf' etc.pp. wie man sie von Lieferdiensten kennt, ist das ja nicht allzu viel.)


    Wichtig: Erleg Dir selbst ein Ziel auf, ab dem die App 'fertig' ist. "Wenn ich damit zufrieden bin" ist kein Ziel.
    Tatsächlich fällt Dir nämlich mitten drin ein, dass Du die Allergene zu den einzelnen Speisen mit ausgeben könntest. Und eine Detailansicht implementieren, auf denen diese Allergene aufgezeigt sind. Mit Icons. In unterschiedlichen Sprachen. Mit TalkBack Support für Blinde. Und einem Rating. Inklusive Kommentarfunktion.


    Irgendwann reichen dann auch drei Jahrhunderte nicht mehr aus. ^^

    Also wenn Du auch noch mehrere unterschiedliche Sportler vorhalten möchtest, sind die SharedPreferences definitiv der falsche Ort.


    Am Besten realisierst Du die Lösung in SQLite mit den entsprechenden Konzepten.
    Das Tutorial Android SQLite database and content provider von Lars Vogel ist da ein prima Einstieg.


    Wenn Du Dich da durchgearbeitet hast, ist das schon mal ganz prima und es sollten sich viele Fragen erledigt haben.


    Vor Allem: Wenn Du einen Content Provider nutzt, ist es ein Leichtes, den gegen einen Content Provider mit Serverzugriff auszutauschen.
    Du kannst auch einen hybriden Content Provider bauen, der erst mal lokal arbeitet und dann mit dem Server kommuniziert – alles ohne Deine funktionierende Demo App anpassen zu müssen.
    (Das sind dann aber schon advanced topics +g+)

    Generell: So ähnlich wie Du die Daten schreibst, liest Du sie auch wieder aus.
    Also statt '.putString(key, value)' auf dem Editor ein '.getString(key)' direkt auf die SharedPreferences.


    Aber: In die SharedPreferences gehören nur Benutzereinstellungen, die über Deine App geteilt werden.
    Daher auch der Name.
    Alter und Geschlecht sind da durchaus speicherwürdige Einstellungen (Wobei ich 'Geburtsdatum' dem 'Alter' vorziehen würde. Letzteres ändert sich jährlich, ersteres eigentlich nie.)


    Startpunkt, Dauer, Geschwindigkeit, Streckenprofil und Distanz dürften sich bei jedem Lauf (oder was auch immer Du da aufzeichnen möchtest) ändern.
    Vermutlich möchtest Du eine Liste vorhalten, in der man sich die Daten jedes einzelnen Laufs ansehen kann.


    Dann solltest Du diese Informationen unbedingt außerhalb der SharedPreferences in einer eigenen SQLite Datenbank aufbewahren :)

    [code=java] public void onItemSelected(AdapterView<?> parent, View view, int position, long id) {
    Alter = parent.getItemAtPosition(position).toString();
    Geschlecht = parent.getItemAtPosition(position).toString();
    Dauer = parent.getItemAtPosition(position).toString();
    }[/quote]Hier setzt Du alle drei Werte auf denselben Wert.
    Welchen Spinner Du auch immer anwählst, alle drei Variablen haben dann den gleichen Inhalt, zum Beispiel 'männlich'.


    Du trägst also einfach für jeden Spinner einen eigenen, anderen OnItemSelected Listener ein oder machst bei Deinem generischen Listener eine Unterscheidung nach dem Spinner.

    Ich würde immer ein paar Euro mehr ausgeben und direkt die Dinger von Google kaufen.
    Erstens hast Du dann ein Android drauf, das nicht durch irgendwelche Samsung/HTC/Sony spezifischen Anwendungen verschmutzt ist.
    Zweitens bekommst Du dafür rasend schnell neue Updates. Marshmallow gibt es beispielsweise bereits als Preview Version für das Nexus 5.

    Seriously?


    Java
    // …
       URLConnection uelCon = url.openConnection ();
       InputStreamReader InputStreamReader = new InputStreamReader (BufferedInputStream (myconn.getInputStream ()));
    //…
       String traverse;
    //…
           builder.append (Traverse);
    //…
    catch (IOException IOE) {
       ioe.printStackTrace ();


    Because of this parts your posted code cannot even compile, so it cannot be executed, so it cannot be the code generating the mentioned exception.


    If you really need help 'asap' you should at least post the real code or, even better, upload a sample project that isolates this issue.
    Nobody will be able to help you with that code snippet.

    Also Sinn macht so etwas immer.


    Wobei ich vielleicht die Sache mit dem VPN nicht selbst implementieren würde.
    Wenns PPTP oder L2TP/IPSec ist, geht das ohne Mehraufwand direkt im Endgerät. Dann kannst Du Dich einfach auf die Netzwerkschnittstelle des OS verlassen bzw. sollten die Server nicht erreichbar sein eine Meldung anzeigen, die bestenfalls in die jeweilige Systemeinstellung führt.
    Meist wird VPN ja auch für Intranet und Konsorten genutzt, deshalb würde ich das OS die Arbeit machen lassen.


    Willst Du aber speziellen Kram unterstützen (Cisco VPN zum Beispiel), dann solltest Du auf jeden Fall mit deren VPN Client für Android agieren.
    Das selbst zu klöppeln wird bestenfalls schwierig.


    Weiterhin wirst Du kein Servlet bauen können. Android nutzt Java nativ, da nen TomCat aufsetzen und ein Servlet basteln ist… suboptimal.
    Also mach es lieber komplett nativ. Natürlich kannst Du ein Servlet ins Intranet setzen und die App holt dann die Daten über den Server ab.
    Das ist allemal besser als direkt auf die Datenbank zuzugreifen und fertige REST Implementierungen für Java gibt es ja zu Hauf.


    Java geht auf Android, aber auch wieder nicht. Swing/SWT/JTable geht auf Android definitiv nicht.


    Wie gesagt basiert Android komplett auf Java, aber eben nicht auf dem kompletten Java.
    Für die dalvik-vm wurden viele Dinge aus Java stumpf nicht übernommen, da sie die Performance der Geräte zu stark ausbremsen.
    Eine Übersicht der existierenden Packages findest Du hier:
    http://developer.android.com/reference/packages.html


    Swing/SWT läuft keinesfalls auf den Geräten. Zwar gab es irgendwo eine JavaFX Demo, die aber mit der heißen Nadel gestrickt und zum Teil nativ in C++ umgesetzt wurde.
    Auch hier bietet Android eine auf einem XML Layout basierende Lösung zur UI Erstellung an. Ein ListView wäre beispielsweise eine gute Möglichkeit zur Tabellendarstellung.
    Die Paradigmen aus Swing und JTable kannst Du aber nicht umsetzen.
    Hier ist Einarbeitung erforderlich.
    Mit existierender Java Erfahrung ist die aber gar nicht so schwierig.
    Android bietet genug Dokumentationen, Tutorials, Hilfestellungen, und Codebeispiele, so dass ein erfahrener Java Entwickler schnell hinein findet.
    http://developer.android.com/training/index.html
    http://developer.android.com/guide/index.html
    http://developer.android.com/samples/index.html


    Für ein Proof-Of-Concept rate ich Dir ganz persönlich: Just Do It.
    Mobile Development macht meiner Meinung nach sehr viel Spaß und man hat schier unendliche Möglichkeiten.
    Davon abgesehen ist es immer schön, mal seinen Horizont zu erweitern. :)