CyK schrieb: Die Android-App benutzt beide Funktionsweisen.
Also, es gibt einen Anmelde-Bildschirm, wo ein WebView und ein Textfeld für den Code ist.
Man kann jedoch, wenn es einem nicht sicher genug ist auf ein Label tippen, dann öffnet sich die Login-Seite im Browser, wo man sich dann komplett unabhängig von meiner App einloggen kann. Danach kann man dann wieder zurück zu meiner App wechseln und den Code eingeben...
Das ist natürlich auch eine Möglichkeit, werde wohl auch beides einbauen
Ist eigentlich eine Mobile Variante der Login-Seite geplant? Finde es ein bisschen hackelig beim Anmelden...
Was ich mir auch überlegt habe ist, den Benutzer die Anmeldedaten einmalig eingeben zu lassen (wird natürlich nicht gespeichert und Nutzer bringt gleiches Vertrauen der App entgegen wie mit integriertem Webview) und die Anmeldung + PIN auslesen per Javascript im Hintergrund laufen zu lassen. War mir aber bisher für die normale Login-Seite zu aufwändig. 1 mal bearbeitet, zuletzt 17. März 2012, 00:24 Uhr
HollaDieWaldfee schrieb: Das ist natürlich auch eine Möglichkeit, werde wohl auch beides einbauen
Ist eigentlich eine Mobile Variante der Login-Seite geplant? Finde es ein bisschen hackelig beim Anmelden...
Was ich mir auch überlegt habe ist, den Benutzer die Anmeldedaten einmalig eingeben zu lassen (wird natürlich nicht gespeichert und Nutzer bringt gleiches Vertrauen der App entgegen wie mit integriertem Webview) und die Anmeldung + PIN auslesen per Javascript im Hintergrund laufen zu lassen. War mir aber bisher für die normale Login-Seite zu aufwändig.
Also ich nutze nen Webview. Der Nutzer muss sich einloggen (bei Apple eh über den Webview nicht wirklich auslesbar) und dann auf erlauben drücken. Webview schließt sich und fertig. Keine Code-Eingabe oder sonstiges, ist gar nicht nötig, wenn man die Token richtig verarbeitet
Ich hab auch im Kopf das Doakes, das automaitsche Auslesen eher nicht will, genau sowas will man ja mit oAuth verhindern und alles transparent machen
Da es schon nen Parameter für eine mobile Seite gibt (noch ohne Funktion) wird das wohl geplant sein 2 mal bearbeitet, zuletzt 17. März 2012, 00:43 Uhr
CyK schrieb: Verrätst du mir, wie du das machst? =)
würde ich wirklich gerne, aber bei mir übernimmt das alles ein Framework (http://code.google.com/p/gtm-oauth2/) ich muss quasi nachher nur die Auth-Daten speichern und bei jeder Abfrage wieder mitschicken, mehr mach ich gar nicht
Aber es müsste sowas in der Art auch bestimmt für Android geben
CyK schrieb: Verrätst du mir, wie du das machst? =)
Das kommt darauf an was du beim Temp-Token-Request dem Parameter "oauth_callback" übergibst. Wenn du "oob" übergibst wird nach dem Klick auf "Erlauben" der PIN angezeigt. Wenn du eine URL übergibst, dann wirst du nach erlauben auf genau diese Seite weitergeleitet - ohne PIN (edit: bzw. der PIN steht als Parameter in der URL). 1 mal bearbeitet, zuletzt 19. März 2012, 20:46 Uhr
Ja, aber auf welche URL soll ich denn weiterleiten? Wenn ich z.B. auf google weiterleite, bekomme ich über den Parameter den Verifier, das ist schon klar. Aber dadurch hat google ihn ja auch XD
Ach, sorry dass ich deinen Thread damit voll spamme =)
Du hast doch in Android bestimmt auch die Möglichkeit beim Webview auf 'onLoadStarted' oder etwas Vergleichbares zu reagieren. Ich lese zu dem Zeitpunkt einfach die url aus und stoppe den Webview dann, die Seite wird dann auch nicht geladen.
Außerdem kannst du ja auch auf ne Seite von xrel weiterleiten.
Mittlerweile unterstützt die App die API zu ca. 95%. Die 0.9.6er Version habe ich auch in den Nokia Store eingereicht, mal schauen ob sie duch die QA kommt
Meego und Symbian sind total tot. Ich würde die Zeit lieber in Android und/oder iOS stecken. Das hat sich durchgesetzt und wird langfristig genügend Userbase haben.
Meego und Symbian sind total tot. Ich würde die Zeit lieber in Android und/oder iOS stecken. Das hat sich durchgesetzt und wird langfristig genügend Userbase haben.
Was natürlich nicht deine Arbeit hieran schmälert
Ach mein N9 ist ziemlich lebendig und totgeglaubte leben länger.
Schon mal Meego, oder besser gesagt Meego/Harmattan benutzt? Also IMHO setzt sich nicht immer das beste durch. Aber Spaß beiseite, jetzt gibts halt auch für den kleinen eingeschworenen Kreis der N9 User eine xREL-App.
Das schöne an Meego ist, dass die Apps auf Qt basieren. Ich kann die App ohne großen Aufwand auf andere Betriebssysteme portieren.
Meego hieß früher Maemo und wird in zukünftigen Versionen eben Tizen oder Meltemi heißen. Basieren alle auf Linux und haben Qt ab Werk sozusagen. Die App wird überall laufen
PS: Eigentlich müsste ich mal zum Spaß noch eine Desktop Version kompilieren ^^
1 mal bearbeitet, zuletzt 22. März 2012, 20:16 Uhr
HollaDieWaldfee schrieb: Ich hab mich in der Beschreibung auch zurückgehalten und Infos über Kinofilme, Serien und irgendwelche "Releases" anzuzeigen ist ja nix verbotenes
ja hab ich bei Apple auch versucht, hab sogar Screen von der Releases-Seite weggelassen, aber leider haben die dann doch genauer geguckt
Changelog:
- Vernünftige Filter für die Scene-Releases (danke nochmal an CrEaK für den Tipp)
- Neue Entertainment Coverflow Listenansicht im Landscape-Modus (siehe Screenshot)
1 mal bearbeitet, zuletzt 29. März 2012, 21:03 Uhr
Die Android-App benutzt beide Funktionsweisen.
Also, es gibt einen Anmelde-Bildschirm, wo ein WebView und ein Textfeld für den Code ist.
Man kann jedoch, wenn es einem nicht sicher genug ist auf ein Label tippen, dann öffnet sich die Login-Seite im Browser, wo man sich dann komplett unabhängig von meiner App einloggen kann. Danach kann man dann wieder zurück zu meiner App wechseln und den Code eingeben...
Das ist natürlich auch eine Möglichkeit, werde wohl auch beides einbauen
Ist eigentlich eine Mobile Variante der Login-Seite geplant? Finde es ein bisschen hackelig beim Anmelden...
Was ich mir auch überlegt habe ist, den Benutzer die Anmeldedaten einmalig eingeben zu lassen (wird natürlich nicht gespeichert und Nutzer bringt gleiches Vertrauen der App entgegen wie mit integriertem Webview) und die Anmeldung + PIN auslesen per Javascript im Hintergrund laufen zu lassen. War mir aber bisher für die normale Login-Seite zu aufwändig.
1 mal bearbeitet, zuletzt 17. März 2012, 00:24 Uhr
#