Beiträge von Marco Feltmann

Moin,

das Problem ist this(ctx);, wie Du Dir sicher schon gedacht hast.
(Nachdem der Compiler ja so explizit darauf hingewiesen hat...)

Hauptantwort
Du übergibst dem Konstruktor this nur einen Kontext und keinen Sensor. Deshalb findet der Kompiler keinen Sensorwert.
Die Zuweisung der Membervariable findet unterhalb dieses Konstruktoraufrufes statt und ist da auch völlig unerheblich.
Es hilft auch nicht, den Sensor da einfach mitzugeben - dann rufst Du den Konstruktor in einer Endlosschleife auf.

Zusatzantwort
Wenn ich mich recht entsinne sucht this(arg,...) nach passenden anderen Konstruktoren der aktuellen (this) Klasse. Deine Klasse hat nur einen einzigen Konstruktor, der zwei Argumente erfordert. Da einen Konstruktor mit nur einem Argument aufzurufen kann nicht klappen. Ergo liefert die Methode gar nichts zurück, da sie nicht ausgeführt werden kann.
Man könnte denken: 'Heeeeey, Dialog hat einen Konstruktor, der nur einen Kontext verlangt!'
Faktisch richtig. Aber der Konstruktor heißt Dialog, nicht SensorDialog.
Wie aus diesem StackOverflow Kommentar hervor geht, werden Konstruktoren nicht mitgeerbt.
Du musst also irgendwie den Konstruktor Deiner Superklasse aufrufen, damit der Dialog weiß, wohin er angezeigt werden soll.

Einfacher Lösungsweg:
Tausche this(ctx); gegen super(ctx);.

Schönerer Lösungsweg:
Füge folgende Zeilen hinzu, am Besten in die Nähe Deines Hauptkonstruktors:

public SensorDialog(Context ctx) {
  super(ctx);
}

Vielleicht hilft dieses Tutorial weiter?
http://www.mkyong.com/gradle/g…r-file-with-dependencies/

Nimm auf jeden Fall erst einmal alle konfliktträchtigen Abhängigkeiten komplett raus, sonst machst Du Dir keine Freude damit.

Irgend ein Redirect zeigt auf example.com.

Durchsuch mal das gesamte Projekt nach dieser Domain und passe es an.

Federführend und in der Apple-Entwicklerszene inspirierend sind die Schulungen der Big Nerd Ranch [0].
War nicht nur jahrelang der einzige Anbieter auf dem Gebiet (est. 2001), die sind auch sehr sehr gut.

Für die iOS Jungs sind Mark Dalrymple und Aaron Hillegass nicht nur Namen sondern Götzen.
Die Android Jungs und Mädels sagen mir gar nix, ist aber auch nicht mein Metier.

Bei der geballten Ladung an Leuten kostet das natürlich.
$4.500 für knapp 5 Tage (iOS) klingt erst mal viel. Ist aber inklusive Übernachtungen und Verpflegung mit Coding und Trainings von 09:00 morgens bis 22:00 abends.
Und natürlich nur in den USA.

Wenn Dir das zu viel ist kann ich an Hand der Tutorials noch die Schulungen von Lars Vogel [1] empfehlen.
Ist mit 1950€ für 2 Tage Einstieg bzw. 4 Tage Advanced wesentlich günstiger und er lässt sich auch in Deutschland fürInhouse Schulungen buchen. Wäre allerdings Android Only.

Links:
0) https://www.bignerdranch.com/we-teach/
1) http://www.vogella.com/training/android/index.html

Da kann ich helfen.

Die SharedPreferences sind ein reiner Key-Value-Store.
Es werden also Werte zu Schlüsseln abgespeichert und ausgelesen.

Hier gibt es beim Auslesen eigentlich zwei Zustände.

• Der Schlüssel exisitiert nicht.
  Die Abfrage liefert ein null Objekt zurück.
  Im weiteren Verlauf zu Problemen führen, weshalb es sachdienlich ist, einen sinnvollen Defaultwert beim Auslesen zu setzen.
  (String: "", Ziffer: 0...)
• Der Schlüssel existiert.
  Du bekommst einen irgendwie gültigen Wert zurück.

Beim Lesen musst Du beachten, dass Du die gleiche Lesemethode verwendest, wie Du sie zum Schreiben verwendet hast. Und natürlich musst Du denselben Key verwenden. (static const final String kann helfen.)
Sofern Du also putString("Foo", "Bar") aufrufst, wird ein getBool("Foo") ebenso wenig bringen wie ein getString("Fubar").

Obacht
Den Pin so im Klartext da rein zu werfen ist eine sehr sehr sehr schlechte Idee.
SharedPreferences sind geteilt und können von potentiellen Angreifern gelesen werden. Damit ist Deine Sicherheitsfunktion hinfällig.
Lieber ein SHA128 mit dem Salt der Usermail, der aktuellen Telefonnummer oder anderen Dingen, die nicht durch die SharedPreferences ersichtlich sind, ablegen.
MD5 ist mittlerweile auch unsicher geworden.

Zitat von Kiodok

am besten mit Code.

Ich denke nicht.

Du solltest einmal Breakpoints setzen und durchgehen, wie weit Deine Implementierung kommt.
Der Grundsatz onPause() speichern und onResume() laden klingt erst einmal ganz einleuchtend.
Wo der Fehler liegt kann mit diesen Informationen aber nur von Dir selbst herausgefunden werden.

Du hast eine PlugIn App ohne PlugIns?
Wie konntest Du denn die PlugIn App auf Funktionalität prüfen, wenn Du keine PlugIns dafür hast?

Im Übrigen sind das keine PlugIns. Das sind Schnittstellen für WebServices.
Also wirst Du Deine Sportveranstaltungen wohl auf einem WebService anbieten müssen.
Vielleicht in WordPress oder über irgend einen Clouddienst.

Moin!

Schieß' los. Mit den Fragen, meine ich.

Moin!

Moin!

+hm+
Wenn ich mich recht entsinne kann in Android nur einer ViewGroup ein anderes View zugeordnet werden.
Wenn R.id.container nicht gefunden wird, dann existiert es wohl nicht. Ich glaube, dass es das auch gar nicht muss, wegen Context und so.

Mutmaßlich musst Du Dir einen ViewGroup bauen, der einerseits Dein CustomView darstellt und andererseits an den gewünschten Ecken die Buttons anflanscht.

Jain.
Thou shall not access /sdcard manually.

Niemand kann Dir sagen, wie die einzelnen Hersteller da rumhantieren.
Du sollst über getExternalFilesDir() und Konsorten auf die SD Karte zugreifen (wenn sie existiert) und über getFilesDir() auf den internen Speicher.
Alles Andere ist Implementierungsdetail teils der Hersteller und teils des OS und kann deshalb stumpf zu Fehlern führen.
Steht auch in den jeweiligen Android Dokumentationen.

Also:
Ja, das ist auch bei einigen realen Handys so.
Nein, das kannst und sollst Du nicht abstellen.

Bevor ich da anfange mich durch die Implementierung von getByName() zu wühlen:
Hast Du geprüft, dass Dein Android Deinen PI auch als (ersten/einzigen) DNS Server konfiguriert hat und der DNS Search Path stimmt?

Zunächst einmal passt der Ansatz nicht ganz.
Du möchtest in der OnCreate den String aus dem Async Task empfangen. Da der Task asynchron läuft, ist das in 99,99% der Fälle nicht möglich, weil der String leer ist. (In der unglaublich kurzen Zeit bekommt Dein Task noch keine Info zurück und kann dementsprechend nix anzeigen. Und die OnCreate wartet auch nicht auf Deinen Task, er ist ja asynchron.)

Sinnvoller wäre es, Du definierst eine Callback Methode in Deiner Activity, die Dein AsyncTask im onProgressUpdate aufruft.

Am Besten ein Interface definieren:

interface StringDownloadDelegate
{
    public void taskReceivedStringComponents(AsyncTask sender, String[] components);
}


public class connectTask extends AsyncTask<String,String,TCPClient>
{
    private StringDownloadDelegate delegate;
    
    // Setter dazu schreiben...


    // Rest der Klasse einfügen...


    protected void onProgressUpdate(String[] values)
    {
        super.onProgressUpdate(values);
        // NULL Check etc needed
        delegate.taskReceivedStringComponents(self, values);
    }
}

Jede Activity muss dann dieses Interface implementieren.

public class ControlActivity extends AppCompatActivity implements StringDownloadDelegate {


  // Krams wie gehabt einpflegen.
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    // Eigene Vorbereitungen und so einbinden...


    connectTask  = new connectTask();
    connectTask.setDelegate(self);
    connectTask.execute("");
  }


  public void taskReceivedStringComponents(AsyncTask sender, String[] components) {
    /* Hier kommt dann der GUI Krams rein.
     * Obacht: Kann (und wird vermutlich auch) mehrfach hintereinander aufgerufen werden.
     * Einerseits also darauf achten, dass das alles hier nicht zu lange dauert und andererseits die Werte zwischenspeichern.
     * Also am Besten eine andere Methode der Activity aufrufen, die meinetwegen die Strings kombiniert und dann die Methode zur Anzeige aufruft.
     */
  }
}

Das heißt, dass Du vor Veröffentlichung schon Testversionen Deiner App bereit stellen kannst.
Jeder, der als Tester für Deine App eingetragen ist, bekommst sie also (kostenlos) vor Release und kann Fehler melden etc.

Alpha und Beta sind hier die Unterschiede in Stabilität und Fertigungsgrad.
Alpha ist mehr so prove-of-concept mit wenigen gut getesteten Funktionen und hoher Absturz- und Fehlerrate.
Beta hingegen ist von Dir als 'quasi fertig' eingestuft worden und Du willst kurz vor Release nur sicherstellen, dass Du keine gravierenden Probleme und Fehler übersehen hast.

Hui, spannendes Projekt.
Eigentlich muss das irgendwie gehen, es gibt ja viele Android Remote Control Apps.
(Also welche, die Android bedienen, keine Fernbedienung auf Android…)

Tools wie FreeRDP [0] machen das ja. Eventuell kannst Du dort in den Sourcen 'schnüffeln'.

Problem: Du brauchst irgend einen dazugehörigen Server, der im Hintergrund auf den Geräten läuft.
Diese benötigen meist Root Rechte.

Vielleicht findest Du ja heraus, ob es irgend ein System (RDP, VNC…) vorinstalliert gibt und strickst Deine Remote Control App drum herum.

Oder Du versuchst es wirklich via adb über WiFi.

0) https://github.com/FreeRDP/FreeRDP

Zu den grundsätzlichen Fragen:
Da hilft glaube ich nur Prototyping.
Also: Dummy bauen, testen, gute Dinge beibehalten, doofe Dinge verbessern, Dummy bauen, testen, gute Dinge beibehalten, doofe Dinge verbessern, Dummy bauen, testen, gute Dinge…

Wobei ich mir wirklich nicht vorstellen kann, wie Du dem Benutzer Eingaben für diese Funktionen abnehmen willst.
Eventuell an Stelle des Alerts ein eigenes Keyboard einblenden?

Zur Animation:
Da gibt es eine Library für. Vielleicht hilft die.
https://github.com/konifar/fab-transformation

Interessantes Problem.
Vielleicht hat Lollipop irgendwelche neuen Sicherheitsfeatures, die das Einspielen 'gefälschter' Apps verhindern?

Nachgucken kann ich nicht, da mir kein unrar Tool vorliegt.

Über den DATA+ kannst Du senden was Du möchtest.
Das Senden sollte asynchron erfolgen, du kannst also beispielsweise einen Bytestream starten, der eine 1 nach der Anderen durch die Leitung pumpt.
Ein Timer beendet dann nach 100ms diesen Bytestream sauber.

Alternativ berechnest Du Dir die vermutliche Übertragungszeit des Bytestreams.
Theoretisch hat USB 2.0 eine Geschwindigkeit von 480MBit/s, also 480.000.000 Bit pro Sekunde.
(Hier handelt es sich nicht um Megabyte, sondern um Megabit, also nicht mit 1024 rechnen!)

Du brauchst nur 1/10 einer Sekunde, also 48.000.000 Bit.
Entspricht also einem Bytestream von 48 Millionen true Werten, also einem ungefähr 45,8MB großes Dokument…

Ich weiß allerdings nach wie vor nicht, wie groß der High Pegel (in Spannungs– und Stromwerten) sein muss und was so ein TRUE auf dem DATA+ (in Spannungs– und Stromwerten) liefert. Eventuell musst Du noch einen Spannungswandler zwischen klemmen, der aus einem 100mV/10mA Signal etwas für den MOSFET verständliches baut.
Hinzu kommt, dass ich absolut keine Ahnung habe, wie zuverlässig USB im Hinblick auf Datenoptimierungen, verlorene Datenpakete oder Latenzen ist, sprich: Wenn mein Port fleißig Einsen sendet, feuert das System sie dann so raus, wie sie rein kommen? Schickt es den Kram byteweise? Schickt es einzelne Pakete erneut? Wartet es auf Antworten von der Gegenstelle?
Hier musst Du Dich ganz genau mit der Spezifikation von USB auseinandersetzen, um abklären zu können, ob das überhaupt das kann was Du gern hättest.
Ein einfaches Stromkabel mit einem Schalter dran ist es halt nicht. Mehr so ein Morsedings. Solange Du die Morsezeichen nicht verstehst, kannst Du da nicht viel machen. Wenn alle maximal 3 Zeichen pro Buchstaben mit fest definierten Pausen verwenden, kannst Du da auch nicht ohne Weiteres ausbrechen.

Eventuell brauchst Du wirklich eine zwischengeschaltete Logik, die noch auf 'Mach auf!' und 'Mach dicht!' reagiert. Oder auf 'Mach auf!' hört und eigenständig nach 100ms zu macht.

Du bewegst Dich hier in einem Schattenbereich zwischen Software– und Hardwaredevelopment.

Bevor Du jetzt hier anfängst nach allen Richtungen zu suchen, würde ich wie folgt vor gehen:

• Altes passendes USB Kabel suchen
• Altes unwichtiges Android Gerät suchen
• Kabel aufschneiden und +5V an das Gate legen
• Anderes Ende ins Gerät stecken (Hoffentlich das Kabel am richtigen Ende aufgeschnitten… ;))
• Manuell den Host Modus aktivieren und wieder deaktiveren

Wenn's dann klackt kannst Du in der Richtung weiter recherchieren. Wenn nicht, musst Du Dir was Anderes überlegen.

Aber wie gesagt geht das schon fast in den Bereich Microcontroller/Embedded Development.
Denn eigentlich ist so ein USB nur zur Kommunikation gedacht, mit diesen Kommunikationen irgendwas anfangen sollte die Gegenstelle.
Und das ist dann Embedded Development und wohl auch das Haupt'problem' bei diesem Projekt.

Denn wenn das erst mal steht (Power via USB [oder extern], Ansteuerung via DATA+ von USB, eine USB Nachricht reicht zum Öffnen) kannst Du da nachher ranpappen was Du willst. Arduino mit Bluetooth oder NFC, eine alte Microsoft Tastatur, EveryKey, einfach alles, wenn es denn irgendwie USB spricht.

Deshalb ja auch mein Abschluss:

Zitat von Marco Feltmann

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

Damit stimme ich Dir also voll und ganz zu, beziehe mich nur nicht auf die verlinkte Implementierung im Speziellen sondern auf den theoretischen Ansatz im Allgemeinen.