resizable Widget

Hallo Danie,

a) du hast in deinem Layout ja ein Imageview oder ein Imagebutton.

b) dann nimmst du dir ein Handle darauf
z.b. ImageView myIView = (ImageView) findViewById(R.id.myIViewimLayout);

c) dann hast du dir unter /res/drawable images hinterlegt ( z.b. myimage_ein.png / myimage_aus.png)

und wenn du beides gemacht hast , kannst du z.B. das Image setzen mit

if (a == foo)
myIView.setImageRescource(R.drawable.myimage_ein);
else
myIView.setImageRescource(R.drawable.myimage_aus);

— geändert am 27.07.2016, 22:56:16

Hallo Daniel,

nimm doch einfach mal einen ganz normalen Imagebutton und toggle selbst .

Image : die Größe der Images kannst du frei wählen , sollen halt nicht zu exorbitant sein.

Siehe Beispiel.

Auch mit Buttons...

Reagiere auf den Klick , ändere jeweils die IMages..

Das was du machen willst ist ein "FlipFlop" .....

Daniel,

ich würde dir erst einmal empfehlen, mit einer Standard App mit den Grundlagen der Android-Programmierung
zu experementieren, bevor du mit einem Widget beginnst.

In dieser App setzt du dir erst mal zwei Buttons und arbeitest dich in die Funktionsweise von Layout, Farben und
Reagieren auf Clicks ein ..

Erst dann kannst du dich an Widgets trauen.

Farbcode : mach einen screenshot , füge es in ein Grafikprogramm ein und ermittel dann den HEX Code deiner Wunschfarbe.

— geändert am 29.07.2016, 00:44:13

Hallo Daniel ,

ich komme auch aus der C++ Ecke und mache das seit über 20 Jahren hauptberuflich und in Selbständigkeit.

Ich denke schon , dass du die notwendige Basis hast - du musst halt bei Java nicht besonders umdenken.

Einige Sonderheiten hat aber Android /resp Java schon und ich sitze manchmal heute noch hier und verzweifle,
weil ich halt überwiegend in C++ programmiere und in einigen Sachen komplett umdenken muss.

Globale statische Variablen sind z.b. bei Android nicht gerne gesehen , im Gegensatz zu reinem C.
Der Aufbau der GUI ist auch gewöhnungsbedürftig und vor allem muss man sich vorher mit der Eigenart des Betriebssystems auseinander setzen und verstehen , was im Hintergrund passiert. (z.b LifeCycle)
Die bei C/C++ gerne eingesetzten Getter und Setter sollten wiederum bei Android aus PerformanceGründen nicht
eingesetzt werden usw usw.

Gehst du da wie ein normales C Program ran , wirst du im Punkto Instabilität leider ein wahres Wunder erleben.

Aber du brauchst halt Zeit , wie bei jeder neuen Plattform auch.

Habe mal was für dich gegoogelt , sieht auf den ersten Blick recht fundiert aus
http://www.programmierenlernenhq.de/android-app-programmieren-tutorial/

— geändert am 29.07.2016, 00:38:19

Im Gunde gleich aber ich rate dir installiere direkt AndroidStudio.
Da hast du keinerlei Probleme im gegensatz zu eclipse. Auserdem ist unklar wielange Google Eclipse noch unterstützt. Noch ein vorteil ost Gradle mit welchem du externe Lib einfach einbinden und Updaten kannst.

AndroidStudio kann auch eclipse einbinden. Das ist kein Problem.

In das Package kannst du ja noch eine Application(Activity) einfügen, welche für die Einstellungen gut ist, das geht alles in einem Projekt und ist auch das einfachste.
Wenn alles weiterhin abgefragt sein soll auch wenn App zu oder widget nicht aktualisiert (da nciht angezeigt), dafür nimst du am besten einen BackgroundServcie der dir die Daten in einem bestimmten Intervall abfragt und dann bereitstellt oder gleich verarbeitet.

Also Background Service läuft auch wenn die App zu ist ( wenn alles ruchtig eingestellt!)
Pollen ist so eine sache. 100ms würde gehen ist aber nicht ganz nach dem Konzept und belastet den Akku stark.
Eigentlich brauchst du ein externes Gerät dass dir eine Zustandsänderung per Push o.ä. zukommen lässt..
Ansonsten abfragen und verarbeiten und ja Lubs sind auch verfügbar ist ja nicht so als würden die nur für Activities funktionieren

Lubs=Libs; einfacher Tippfehler
Eigentlich brauchst du ein Gerät dass dir den Schalter überwacht und eine Push (fcm o.ä.) schickt. Da das schlecht geht kannst du es ja per Bluetooth machen bei permanenter Verbindung hast du ja auch eine art push.

— geändert am 02.08.2016, 10:31:18

Nur so ein Gedankengang :
(Selbst schon mehrfach realisiert (Raspberry)

a) TCP-Socket-Server (c++) auf den Arduino & ggf. WLAN Accesspoint (Edimax)
b) TCP Client inside App

Dann könntest du Pushen und Pollen nach herzenslust

— geändert am 02.08.2016, 11:04:02

Das stimmt, nur geht eine dauerhafte TCP Verbindung auch auf den Akku, abe das lässt sich in diesem Fall wahrscheinlich sowieso nicht vermeiden.

— geändert am 02.08.2016, 10:49:47

Sehe ich auch so.
Sein Stromverbrauch hängt von dem ab , was er wirklich tut.

Er könnte in der Richtung Ardunio -> App natürlich auch noch einen TCP-Server auf App seite implementieren (anderer Port)
Das simple "listen" auf dem Socket wäre stromsparender.

— geändert am 02.08.2016, 10:58:06

Das geht per:
Seriell,
Bluetooth,
Usb( Seriell)
Du musst den Adruino halt irgendwie mit dem Handy verbinden können.

Hallo Daniel,

nun , nimms mir nicht übel , aber so langsam verstehe ich es nicht mehr

Du hast z.b einen Ardunio mit dem du alle Überwachungen , Messungen usw durchführst.
Mach da ein Standard abgespecktes Linux drauf - Images gibt es genug.

Dann weis ich ja nicht wie deine Umgebung ist, ich schätze mal , dein Ardunio ist irgendwie im Netz.
(Völlig schnuppe ob per WLAN oder LAN - vergib feste IP's auf allen Devices)

Eingangs hast du erklärt , du bist des C/C++ mächtig - ergo kannst du GPIO/RS232 und was auch immer auf
dem Ding abfragen, setzen , ändern und wenn es nur die Überwachung der Klospülung ist.
(Das Netz von voll von C/C++ Beipielen)

Wäre das mal geschafft, baust du dir auch da rein eine TCP - Client und ServerKlasse auch in C/C++.
(Das Netz ist voll von C/C++ Beispielen)

Was soll denn daran aufwendig sein , dann deine Smartphone App via Netz mit dem Ardunio kommunizieren zu lassen ??

Wenn es hochkommt ist der Ardunio/Raspberry innerhalb einer halben stunde incl der gesamten Complier-Binaries aufgesetzt.
C/C++ source drauf , make ausführen und schon wackelt das Ding

Nimms mir auch nicht übel : aber es erweckt den Eindruck , dass Du "hinten" anfängst.
Eines ist fakt : du wirst an der Einarbeitung mit ANdroid-Programmierung NICHT vorbeikommen.
(Siehe original-thema diese Threads)
Dass du dir jetzt schon Gedanken um den Service / resp LiveCycle auf dem Smartphone machst - ist
absolut verfrüht ...
Diese Fragen/Antworten ergeben sich von selbst , wenn es soweit ist.

Bring das Ganze erst mal in Laborversion zum Laufen. Erst dann kannst du dran schrauben.

— geändert am 02.08.2016, 21:09:43

Der Odroid mit Android ist ein Exot - deshalb hast du auch jetzt die Probleme.

Für dauerhafte Überwachungen/Messungen ist das allerbeste immer ein nacktes Linux System OHNE GUI
dass mit maximal 70-100 mA vor sich hindöst, bis was passiert.

Android hat nun mal die Eigenschaft , alles das abzuschiessen , was nicht benötigt wird .
Es ist ein GUI orientiertes DAU-Betriebsystem und nicht für Messtechnik gedacht.
Man kann hier und da ein paar Klammergriffe machen und in die Trickkiste greiffen - aber für dein Vorhaben der dauerhaften Überwachung (besonders im 10 ms Poll bereich) ist das System eindeutig falsch.

Android selbst greifft von sich aus selbst in seine Trickkiste, um dich an polling-Verfahren zu hindern und nun möchtest du hingehen und genau dieses "Feature" wieder umgehen ??
Du bist definitv auf dem falschen Dampfer - versuche nicht krampfhaft etwas zu basteln , was nicht richtig funktionieren wird .

P.S. Ein paar Klicks auf den "Danke" Button bei Pascal , wären angebracht .. der kniet sich nämlich auch sehr tief in dein Problem rein ... - Bringt dich bestimmt nicht um

— geändert am 03.08.2016, 07:58:56

Noch nen Nachtrag :

http://odroid.com/dokuwiki/doku.php?id=en:odroid-c2#software_release

Ein schönes nacktes Linux - Ubuntu Image für deinen C2

Moin Daniel,

dann machen wir jetzt mal ein Reset. Die ganze Zeit kam hier an , dass du Messaufgaben durchführen müsstest.
Oben schreibst du nämlich , dass du im 10 ms Verfahren einen Alarmtrigger starten möchtest

Eine Abfrage über einen Service, der vom Alarmmanager sagen wir alle 10ms ausgeführt wird geht nicht?

Ergo hast du uns schon hier aufs Glatteis geführt.

Es wäre jetzt erst einmal angebracht , dass du genau erklärst , was du denn , nachdem du einen Button gedrückt hast, passieren soll. Bitte Schritt für Schritt - nicht das , was irgendwann mal sein soll

Willst du GPIOS abfragen ? willst du eine Loop laufen lassen und eine Zeitlang werte auslesen ?
Was willst du GENAU machen ???

Ich bin mir nämlich nicht sicher , ob du einen Service benötigst

— geändert am 03.08.2016, 08:23:48

Hallo Daniel,

na das sind schon mehr Infos, um dir Helfen zu können

Ich kenne die Library nicht, habe nur eben quer gelesen und ich habe auch noch nie GPIOS unter Android abgefragt.
Interessant : In der Beschreibung wird kein Wort über den Servicebetrieb verloren , ich gehe einmal davon aus, dass diese Lib auch hoffentlich in Services/Processes verwendbar ist .

Gehen wir einmal davon aus , so gäbe es Ansatzmöglichkeiten:
.
.
Alternative A
Du baust Dir für die (kontinuierliche) Abfrage deiner GPIOS's mit der Lib einen Service, der am besten beim Booten
(Broadcast) gestartet wird.

Dieser Service wird dann eine zeitlang aufrecht erhalten , bevor er von Android abgeschossen werden kann .
Wann das sein wird, kann ich Dir nicht beantworten , hängt von deinem C2 in Verbindung mit Android ab ...
Also bitte evt. selbst ermitteln.

Um diesen DauerTot zu vermeiden, kann man diesen Service selbst beenden lassen (stopSelf) und mittels AlarmManager triggern. Dies kann aber unter Android nicht im Millisekunden-Bereich geschehen , sondern eher im 2-5 Sekunden-Bereich.

Umgangsprachlich Jojo oder Heartbeat genannt.

http://informationideas.com/news/2012/03/06/how-to-keep-an-android-service-running/

Es wird also sein , dass in der Leerlaufphase ( die 2-5 Sekunden) keine Reaktion auf die GPIO's erfolgt.
.
.

Alternative B
Du kannst aber auch mit Background-Processes arbeiten

http://www.vogella.com/tutorials/AndroidServices/article.html
.
.

Nächster Schritt :
Hast du dann im Service/Process den Zustand "Schlüsselschalter-ein", kannst du wieder alles mögliche machen:
Deine App wieder zum Leben erwecken (Intent), die dann den Keyguard steuert und deinen Bildschirm einschaltet (Mosfet).
(oder auch direkt aus dem Service - musst du ausprobieren - aber so wenig wie Möglich in den Service packen !!)

Lebt deine App wieder (OnResume/OnCreate) , kannst du wieder nach Herzenslust wurschteln
.

Hier solltest du nach Möglichkeit alles messtechnische in einem AsyncTask laufen lassen - (AUCH im Service)
https://developer.android.com/reference/android/os/AsyncTask.html

Hinweis : Loops/TimeTasks - auch im AsyncTask unter 150ms Luft, sind unter Android nicht zu empfehlen !

Die GPIO zustände, die der Service/Process ermittelt , könntest du dann per Broadcast/Receiver an die App schicken
.
.

Noch ne Idee : Keine Standard App bauen , sondern eine FullScreen-Launcher-App mit Tasten - dann brauchst du keine
Keyguard. (Wenns eh das Einizge ist , was auf dem C2 bedienbar sein soll)

.
.

P.S Ohne dich de-motivieren zu wollen : für diese oben genannten alternativen und die restliche Vorgehensweise , ist natürlich leider fundiertes Wissen in Java/Android Voraussetzung.
Aus diesem Grunde kam ich auf die Raspberry/TCP Client Geschichte - dann hättest du dich lediglich unter Android mit einer Standard-App und TCP auseinander setzen müssen. Dabei würde die gesamte Mimik von Service / Alarmmanger / Broadcast und Lib entfallen - denn die muss man erst mal zu 100% im Griff haben.

Stellt sich die Frage, ob Du Dir nicht mit den zusätzlichen 30 Eus das Leben einfacher machst.

.
.

Legende für dich als C'ler

AsyncTask = Ähnlich einem Thread unter C
Broadcast = Sytemweites eindeutiges Trigger-Event
.
.

— geändert am 03.08.2016, 15:24:55

Hallo Daniel,

zu a : Nein / Ja
zu b : Das ist LifeCycle abhängig - ich arbeite nicht mit ausgelagerten Processen , deshalb kann ich keine 100% Aussage dazu treffen - vielleicht hier jemand anderes - ich wollte dir lediglich die Möglichkeit aufzeigen.

zu TCP :
"Ob was interessantes dabei ist ?" Ich habe daran eher an eine ständige TCP Socket Verbindung gedacht - beide befinden sich in der gleichen IP Range und somit kannst du eine ständige Verbindung aufrecht erhalten - jede Seite schickt dann was , wenn sie was hat und die Gegenseite weis es dann innerhalb von Millisekunden.
Du benötigst dabei kein Push & Poll verfahren .... die Peeks reichen.
In der Read-Socket Funktion kannst innerhalb eines AsyncTask wunderbar darauf reagieren ....... Nein , es gibt kein Broadcast Event für deine Zwecke. Es gibt zwar etwas, das dir mitteilt , dass etwas über WLAN reinkommt. aber der kommt ständig, weil der allgemeine Overhead der Verbindung das auch auslöst.

Und damit hier etwas kontinuierlich überwacht wird und nicht beendet wird : Du kannst dir ZWEI services bauen , jeweils mit einem TCP Client, der die Verbindung zum Server aufbaut - . Lass sie parallel laufen und setze die Alarmmanger auf verschieden Zeiten. Ergo : es läuft immer einer zuverlässig , wenn der andere Pause hat.

Ob du einen Ardunio/ Rasberry oder einen anderes Singleboard nimmst, ist schnuppe ... Der Raspberry (3) ist halt mE vielschichtiger einsetzbar - meine Ardunios liegen bei mir mittlerweile ungenutzt in der Schublade.

Hallo Daniel,

ich kann Dir natürlich nur das empfehlen , was ich schon einige male erfolgreich umgesetzt habe ...

Nimm es mir nicht übel , aber an dieser Stelle klinke ich mich verständlicherweise aus, wünsche Dir jedoch
viel viel Erfolg bei deinem Projekt ..

lg

— geändert am 09.08.2016, 09:53:38