Beiträge von Marco Feltmann

Ich fürchte, das wird so nicht ausreichend sein.
Einerseits kannst Du nicht Appseitig vom Host in den Accessory Modus wechseln. Für den Schlossöffner benötigst Du die Spannung ja im Normalfall nur ganz kurz. (Unter 1 Minute)
Der USB Host Modus legt ja aber nicht nur die Spannung an, er konfiguriert das komplette Gerät einmal durch, um als Host zu agieren.
Wenn man den Modus verlässt, konfiguriert sich das komplette Gerät wieder durch, um als Client zu arbeiten.
Diese Vorgänge benötigen Zeit und mit Deinem Ansatz kann es durchaus passieren, dass die Wechsel schneller erfolgen als diese Konfigurationen abgeschlossen werden können.

Hinzu kommt, dass die gängigen USB Schnittstellen ~5V bei 100/500/900mA liefern.
(Gibts da schon USB 3.0 drin?)
Bessere Versorgung bekommst Du mit USB 3.1 Typ C, je nach Typ von 5V 2A bis hin zu 20V 5A.
Allerdings speist das Telefon die Schnittstelle, über 5V/2A wirst Du da nicht kommen.
Ich kann nicht beurteilen, ob das Deinem MOSFET reicht um auf zu machen und ob es dem Schloss genügt, um sich zu entriegeln.
Da müsstest Du entsprechend die Spezifikationen vergleichen und gegebenenfalls einen Hochleistungs-MOSFET an der Steckdose nutzen, um den Steuerstrom entsprechend hochzupushen.

Wie dem auch sei, die Spannungsversorgung des USB Host Modus ist eben genau dafür gedacht: Zur Spannungsversorgung.
Damit würdest Du also Deinem MOSFET erst einmal nur die SOURCE Spannung zur Verfügung stellen. Ob es eine gute Idee ist, ihm diese wieder zu entziehen, kann ich nicht beurteilen. So viel Hardware habe ich nicht gemacht. Ich kann es mir aber nicht vorstellen.
In jedem Fall benötigst Du aber auch einen Steuerstrom GATE, sonst passiert gar nix. (Ich gehe mal von einem selbstsperrenden MOS aus, wäre sonst blöd für ein Schloss.)

Natürlich könntest Du jetzt die Spannung auf auf GATE legen, aber das halte ich für völlig falsch.
Zwirbel lieber das USB Kabel auseinander, leg die Spannung auf SOURCE und nimm ein Steuerkabel für GATE.
(Also ROT auf SOURCE, SCHWARZ sowie PIN 4 auf N, GRÜN auf GATE)
WEISS dürftest Du nicht brauchen, da Du ja keine Antworten vom Gerät erwartest.
(Natürlich könntest Du das Ding an DRAIN klemmen und signalisieren: OFFEN (Strom fließt))

Dann implementierst Du gemäß des USB Host Guides der Android Seite die Kommunikation und es sollte soweit alles laufen.
(WENN denn die Spannung der Steuerleitung für den GATE Deines MOSFET ausreicht. Ich finde keine Informationen darüber, wie viel da so bei rum kommt.)

Noch zu beachten wäre allerdings, dass Dein MOSFET nicht zu viel Strom zieht.
Gemäß Standard sollte das Ding maximal 100mA ziehen und bei einem Mehrbedarf fragen. Du müsstest also im Idealfall einen USB Controller vor Dein MOSFET setzen, dass sich um die Aushandlung des Stroms kümmern und in dem Zusammenhang auch gleich die Steuerung des MOSFET übernehmen kann.

So würdest Du die Sache jedenfalls 'richtig' im Sinne von 'dem USB Standard entsprechend' machen.
Wenn Dein MOSFET zu viel Strom zieht, kann es nämlich passieren, dass Dir das Energiemanagement Deines Smartphones durcheinander kommt oder, schlimmer noch, es Dir Deinen Port zersemmelt.
(Also immer schön auf einem ganz alten und unwichtigen Testgerät, bestenfalls mit abgelaufener Gewährleistung rumprobieren.)

Wenn Du dann noch einen Microcontroller zwischen setzt, kann der Dir vielleicht noch tollere Informationen auf Deinen USB Controller schieben.
'Habe geöffnet' und 'Habe geschlossen' statt 'OFFEN' zum Beispiel.

Die Frage ist natürlich, was man sich davon verspricht damit selbst loszulegen.
Es ist ungeheuer spannend, sich in das Thema einzufummeln.
Aber auch mindestens genauso frustrierend.

Es ist dann immer noch nicht sicher, aber das Mitschneiden erfordert mehr Aufwand.

Zitat von ChampS

Eine Taschenrechnerapp ist halt keine 0815 frickelapp. Da gehört halt viel rein, von grafischer Oberfläche bis Rechenfunktionen. Sowas ist eben sehr umfangreich und bedarf komplexen codegebilden.

Das kommt immer darauf an.
Im Prinzip besteht so ein Taschenrechner ja (wie jedes Programm) eher aus drei Komponenten: Eingabe Verarbeitung Ausgabe.

'Mathe–Classe' liest sich für mich so, als sei da eine schicke Implementierung für die Verarbeitungsschicht gesucht.
Da ist es erst einmal egal, ob nachher die Eingabe und Ausgabe über das Display passieren, in einem Terminal oder es sogar komplett abgespalten ist: Eingabe via Terminal und Ausgabe auf dem Drucker oder sowas. (Einige Lagersysteme arbeiten so. Eingabe der Kommissionierung via Terminal und Ausdruck der Transportbelege, ohne dass die Ergebnisse auf dem Terminal jemals sichtbar waren.)

Naja, und jede dieser drei Komponenten ist halt schon eine Herausforderung für sich.
Mein Lieblingsbeispiel ist da ja der Taschenrechner von Windows, der je nach Ansicht unterschiedlich rechnet(e: zuletzt getestet unter XP…)

Standardansicht: 2 + 2 * 2 = 8
Wissenschaftliche Ansicht: 2 + 2 * 2 = 6

Was ist nun richtig und warum?

Die Klasse zur Berechnung ist schnell erstellt. So viel Voodoo ist das mit der rechnenden Mathematik ja zum Glück nicht.
(Sofern man nicht Geschichten a lá 'Gegeben sei x als Element der positiven ganzen Zahlen' implementieren will… Wusstet Ihr, dass es einen Unterschied zwischen 'positiven ganzen Zahlen' und 'nichtnegativen ganzen Zahlen' gibt? Er heißt '0'…)

Wenn man PEMDAS befolgt, hat man das ziemlich zügig durch.
(Reihenfolge der Rechenschritte: Klammern (Parantheses), Exponentialfunktionen, Multiplikation, Division, Addition, Subtraktion.)

Immerhin hat die Mathematik den Vorteil, dass der ganze Computerscheiß darauf basiert.

Das wirkliche Problem ist die Umwandlung der Eingaben (hier als String) in etwas Ausrechenbares, das im Idealfall der PEMDAS Regelung folgt.
Wie das ganz einfach möglich ist? Gar nicht.

Ich denke, am Sinnvollsten wäre die Nutzung der durch die Mathematik vordefinierten DSL (Domain Specific Language). Dazu benötigst Du ein paar Lexer, Tokenizer, Parser und Syntaxbäume. Trivial ist anders.
Gibts aber auch Frameworks für, wenn man sich das basteln lassen möchte.
Beispielvortrag:
https://macoun.de/video2013/tssa1.php

Da wird lediglich die Kunst, die DSL so einzugeben, dass daraus generiert wird, was man gern hätte.
Spannendes Thema. Und kompliziert.

Ein weiteres Problem sind die fies geringen Wertebereiche. So ein Integer reicht in Java von -2^31 bis 2^31-1
Oder in Zahlen:

Zitat

-2.147.483.648
2.147.483.647

(https://docs.oracle.com/javase…pi/java/lang/Integer.html)
2,1 Milliarden scheint jetzt nicht sooo wenig. Wenn man bedenkt, dass wir Hochrechnungen zu Folge 7,2 Milliarden Menschen auf diesem Planeten haben – tja, reicht nicht.

Natürlich könnte man mit Double rechnen. Die haben ja einen unglaublich hohen Wertebereich.
Geht von 2^-1074 bis (2-2^-52)·2^1023

In Zahlen?

Zitat

4,9 E-324
1,7976931348623157 E308

Hilfreich, was? Zum Vergleich:

Zitat

-2.147.483.648 = -2,147483648 E9
2.147.483.647 = 2,147483647 E9

Also 324 Stellen hinter dem Komma bei Zahlen kleiner 1 und 308 Stellen hinter der Zahl (gegenüber 9) bei Zahlen größer 1.
Großer, sehr sehr großer Wertebereich.
Also immer schön Doubles nehmen? Nope.
Die sind wirklich sehr sehr sehr ungenau.
Es kann durchaus passieren, dass 1.000000 + 1.000000 nicht unbedingt 2.000000 ergeben müssen. Kommt immer darauf an, woher die 1.0 kommt.
Wenn die 1.0 in Wirklichkeit eine 0.999999|583 ist, kommt plötzlich und völlig unerwartet 1.999999|166 bei rum.
(| ist der Trenner, bei dem die Zahl bei der Ausgabe normalerweise abgeschnitten wird. 1.0 wird hier bei der Ausgabe auf 2 aufgerundet, was bei 1.9… nicht der Fall ist.)

Du siehst also: Das sieht nur deshalb so kompliziert aus, weil es so kompliziert ist.

Kiodok
Deine PN ist zwar angekommen, aber das Forum lässt sie mich immer noch nicht lesen.
Du müsstest also hier rein schreiben.

Ich weiß ja nicht ob die Idee so gut ist, in einem neuen Thread auf eine UI Komponente zuzugreifen…

Interessant wäre zu wissen, wie das zu Grunde liegende Datenmodell aussieht.
Du kannst Deiner Activity in einem Intent den anzuzeigenden Wert als Extra übergeben.
Oder Du trägst den Wert in eine Datei/Datenbank ein und Dein anderes Intent lädt diese Daten einfach.

Oder oder oder.

Am Besten umreißt Du einmal kurz, was genau Du eigentlich vor hast und wie weit Du Dein Datenmodell geplant hast.

Deine  this.create_newProfile_Button Methode crasht, weil da irgendwas NULL ist.
MainActivity.java Zeile 170.
Steht doch im Log…

Ja, funktioniert.
Ist allerdings manchmal blöd, wenn sich alles aufgehängt hat und Du das Mistding nicht mehr ausgeschaltet bekommst.

Mal eine Frage zur Umsetzungsmöglichkeit, die ich von BlackBerry OS 10 kenne und liebe:

Wenn man dort angerufen wird, gibt es die Möglichkeit im 'Klingelscreen' auf ein Nachrichtenicon zu tippen.
Dann wählt man eine bestimmte Nachricht aus.

Dadurch wird der eingehende Anruf abgelehnt und der Anrufer bekommt die ausgewählte Nachricht ('Bin im Meeting, melde mich später.') via SMS zugestellt.

Ließe sich Phreasy auch um diese Funktionalität erweitern?
(Ja, mir ist klar, dass das eher ein extended feature request ist.)

Verstehe. Manchmal rede ich arg wenig umständlich, das stimmt.

Genau so einfach wie AFP, FTP, SMB, WebDAV und wie sie alle heißen.

Ein bisschen mehr als ein symbolischer Link ist das schon.

Ich dachte, der Sinn hinter CardBoard ist die räumliche 2D Ansicht?

Keine Ahnung, was Du mit Kisseneffekt meinst.
Aber das Prinzip der Stereoskopie [0] ist schon nahezu antik.

0) https://de.wikipedia.org/wiki/Stereoskopie

Jain.
Die können ja auch mit CloudDrive synchronisiert werden.

Ja, Pointer mitschleppen ist ein gängiger Weg in iOS.
Korrigier mich, aber: In Android ist das der komplett falsche Weg.

Was genau ist an meiner Aussage unklar?

Zitat

Du kannst halt keine komplexen Objekte einfach so als Extra übergeben.

Das Ganze hat natürlich einen Grund: Es bringt Dir nix. Dieses ganze Serialisieren und Deserialisieren macht einen gewaltigen Overhead und verbrennt wertvolle Resourcen.

Nimmst Du statt Deines Helpers einen Content Provider für Deine Datenbank, kannst Du mit der ID eines Objektes eine ganze Menge anfangen.
In Deinem Fall wird das Objekt ja erst hinzugefügt, Du brauchst dann also gar nichts übergeben und Dein add_item Intent gibt einfach die ID des angelegten Items zurück – was Du aber auch nicht brauchst, wenn Du die Datenbank beim Anzeigen der Übersicht neu abfragst.

Nur der Vollständigkeit halber: Der Absturz passiert, weil irgendwas in der Implementierung Deiner Serializable Methoden in Deinem DataBaseController schief läuft, also weit bevor Dein zweites Intent angezeigt werden soll.
Da musst Du halt mal ran.

Joah, Du kannst halt keine komplexen Objekte einfach so als Extra übergeben.

Übergib lieber die ID des Eintrags in Deiner Datenbank als Integer und hol' Dir den Eintrag dann in dem anderen Intent.

(BTW: 'Mobile(s)' bedeutet die Art der Geräte, nicht die Mobilnummer.

Eventuell helfen Dir diese Tutorials zu den Intents weiter:
http://www.vogella.com/tutorials/AndroidIntent/article.html

Okay, Dein Problem scheint zu sein, dass dieses Google Play Games Gelöt in Java realisiert ist und auf ein Resultat wartet, welches Du ihm nicht gibst.
Du kannst es ihm auch nicht ohne Weiteres geben, da die Native Activity das Callback gar nicht bereitstellt.

Da Du dafür keine Java Activity anlegen willst, gibt es wohl nur eine Möglichkeit:
– Die Anzeige der Games Activity aus dem Games SDK irgendwo als Variable merken.
– Im onResume, die gemäß Dokumentation weitergegeben wird, schauen, ob in der 'GamesActivity' Variable eine Referenz auf die Games Activity existiert
– Falls ja dahin den Callback absetzen und die Variable leeren.

Eventuell könnte es noch wichtig zu wissen sein, wie Du die einzelnen NativeGames Activities startest.

Nein, Du sollst die Methode nur aufrufen.
Es ist eine Callback Methode, um deren Implementierung Du Dich nicht kümmern musst.
Einfach nur aufrufen.

Aber das macht doch Dein Beispielcode schon:

gpg::AndroidSupport::OnActivityResult(
        env, activity, request_code, result_code, data);
  }

Was genau funktioniert denn daran nicht?

(Ob Du dafür jetzt in Java eine native Methode definierst oder das direkt in Deiner nativen Methode machst ist ja gehuppt wie gesprungen.)