Beiträge von Marco Feltmann

Initiales Repository ist erstellt:
https://bitbucket.org/mafe/freifunknotifier/overview

(Nein, macht noch nix.)

Tickets für das ToDo Gelöt pflege ich gerade ein.

Ich kann ja mal schauen, ob ich da was hin bekomme.

Also das soll nur plöngen, wenn man definitiv gerade im Freifunk eingebucht ist?
Funktioniert ja aber nur, wenn das Gerät entsprechend konfiguriert ist, sich automatisch mit Freifunk zu verbinden.

Für den weniger bedarften oder sicherheitsfanatischen Anwender (a.k.a. 'mich') wäre es nett ein pling zu bekommen, wenn ich ein Freifunk WLAN in der Nähe habe, in das ich mich einwählen kann (gefolgt von einem plöng, nachdem ich mich eingewählt habe).

Ich persönlich mag es einfach nicht, wenn mein Endgerät sich erdreistet sich nach eigenem Ermessen mit irgendwas zu verbinden.

Muss mal sehen, wann ich dazu komme.

Wie gesagt, bei der Erstellung muss ja bei einigen Views (Spinner) eine Auswahl getroffen werden, damit überhaupt was angezeigt wird.

Das hängt aber sicherlich nicht mit dem Auswählen aus der Liste zusammen.

Leider ist die Darstellung zerrissen.

Vermutlich

TextView test = (TextView) findViewById(R.id.textView_test);

Zu dem Zeitpunkt hast Du noch kein Superview, weshalb es 'null' ist. Und null.findViewById(…) führt zum Absturz.

Ich denke mal, das ist nur ein Funktionstest.
Meiner Meinung nach ist es sinnlos einen Text zu nehmen, in irgendwas zu wandeln und dann wieder in einen Text zu wandeln – man hätte ihn ja gleich als Text nutzen können.

Wenn Deine App anhält, dann hast Du im Fenster 'LogCat' sicherlich diverse Einträge stehen, davon einige in roter Schrift.
Was steht da bei Dir?

(Vermutlich eine NullPointerException.)

Tja, zu spät gelesen.

Dein Problem ist, dass Du onCreate() benutzt hast, um das View zu setzen. Das funktioniert aber nicht, da eigene Fragmente ihr View selbst erstellen.
Kurz gesagt: in der onCreate() geht setContentView() nicht, da das dazu notwendige superview noch nicht gesetzt wurde.

Dein Ansatz war schon ganz richtig, gehört aber entweder in die onCreateView() oder onViewCreated().
Den Umweg über ein öddeliges leeres XML brauchst Du gar nicht.

Pack Deinen Code in die onCreateView(), aber rufe nicht setContentView(ll) auf, sondern return ll.

Das sieht sehr gut aus.
Was es insgesamt noch etwas schwieriger macht.

Die nächste logische Idee wäre, dass Du Dich im betreffenden onItemSelected() mit einem Breakpoint reinhängst und jeweils schaust, welchen Typ und Wert arg0 hat.
Eigentlich kann es nur noch sein, dass sich Spinner und Drawer einen Adapter teilen, aber das wäre unrealistisch.

Dann hoffen wir mal, dass AT&T Apple auf die Finger klopfen wird, wenn sie ein ähnliches Feature anzubieten in Erwägung ziehen.

PS: Wer zählt denn bitte die Löcher? Es geht doch hier primär um den Käse!

Moin,

soso, ein Freifunker.
Bis dato bin ich nicht dazu gekommen, mich mit dem Verein im Allgemeinen und der Hamburger Zelle im Speziellen zu beschäftigen.
Naja, vielleicht morgen.

Die Idee an sich klingt super und auch recht simpel umzusetzen.
Das ließe sich beispielsweise über einen Service realisieren und über ein Widget/eine App konfigurieren und steuern.

Es gibt da allerdings auch ein paar ungeklärte Fragen.

• Gemäß den Erkenntnissen aus diesem Thread bieten einige Android-Versionen wohl die Funktion auf das mobile Netz umzuschalten, wenn es schneller ist als die aktuelle WLAN Verbindung.
  Was soll die App in einem derartigen Fall tun?
  – Sich merken, dass wir gerade mit einem Freifunk verbunden waren, feststellen, dass es derselbe ist und auf das 'auto network selection' Problem hinweisen?
  - Sich merken, dass wir gerade mit dem gefundenen Freifunk verbunden waren, aber die Klapp halten?
  – Sich nicht drum scheren sondern einfach immer und immer und immer wieder plöng machen?
  

  
  

• Das ultimative Freifunk-Ziel dürfte es ja sein, dass man an jedem Standpunkt der Stadt mindestens zwei Freifunk Zugangspunkte in der Nähe hat.
  Plöngt die App dann andauernd?
  Gar nicht, solange mit $irgendeinem Freifunk verbunden?
  Sobald ein besserer Freifunk verfügbar ist? (Wobei das Roaming ja automatisch passieren sollte – es aber halt nicht immer tut…)
  

  
  

• Wie wichtig ist die Akkulaufzeit? Im Normalfall funkt die WLAN Schnittstelle ja nur die Daten an den verbundenen Endpunkt. Rumgefragt wird nur bei der WLAN Suche oder nach Abbruch. Die App müsste dieses Verhalten umgehen und über ein (idealerweise einstellbares) Polling immer mal wieder sämtliche WLAN in der Umgebung abfragen. Und das frisst Strom.
  

  
  

• Gibt es neben der SSID noch weitere eindeutige Merkmale eines Freifunk WLAN?

Ich denke, das war es erst mal an Fragen.

Ah, ein Android Issue.
Danke für's Teilen, mal beobachten, wie die darauf reagieren.

Mal interessehalber: verhalten sich Apple Geräte da ähnlich?

Eventuell ist Dir aufgefallen, dass das hier ein deutschsprachiges Forum ist. Insofern wäre es vielleicht hilfreich, Deine Fragen auch auf Deutsch zu formulieren – nur um Missverständnisse zu vermeiden.

Werden die Call Data Records nicht von den Mobile Service Providern verteilt?
Liegt Dein Problem jetzt darin, dass die Dinger in Datenverbindungen auftauchen, wo sie überhaupt nicht hineingehören?

(Srsly, wenn Du wirklich ein 'analys at Germanys leading mobile service provider' bist, müsstest Du doch eigentlich diverse interne Ansprechpartner in den diversen Firmen haben…)

Im Prinzip hast Du TestActivity1, TestActivity2 und TestActivity3, die ausschließlich die jeweilige Activity testen.

Grundidee dahinter: Wenn jede Activity für sich perfekt läuft, ändert sich das auch nicht, wenn sie von irgendwo aufgerufen wird.

Anschließend musst Du natürlich selbst mal schauen, ob die Verbindungen der Activities laufen.
Entweder per Hand oder automatisiert, beispielsweise mit Appium.

Auf jeden Fall musst Du die Abläufe auch von Hand durchgehen, damit Du auch siehst, wie das Ganze auf dem Gerät aussieht.

Jeder Test sollte nur einen speziellen kleinen Teil Deiner App testen.

Idealerweise testest Du jedes Objekt einzeln (gebenenfalls mocken, falls Abhängigkeiten bestehen)
Dann jedes UI einzeln (Activity, Fragment…)
Anschließend solltest Du dann noch die Integrität der App testen, also das auch ja das UI mit allen Objekten vernünftig arbeitet.

Viele sind aber der Meinung, lieber schlechte und ungünstig geschriebene Tests als gar keine.

Also in dem Fall muss irgendwas mit Deiner DrawHolder.Spinner Verdrahtung kaputt sein.

Lass Dir mal ausgeben, was genau DrawHolder.Spinner für ein Objekt zur Laufzeit ist.

Wegwerfen != ändern.

Die R.java ist wichtig. Wenn die fehlt, wird sie neu angelegt. Wenn sie falsch ist, geht meist alles in die Grütze.

Ich fürchte, den wichtigen Codeteil enthältst Du uns vor.

Irgendwo sagst Du dem Spinner sicherlich, was er vorausgewählt haben soll. Vermutlich via 'setSelectedItem'.
Und das ruft dann den OnSelectedItemListener auf. Also alles so wie es sein soll.

Eine (gute) Möglichkeit wäre es, 'setSelectedItem' des SpinnerAdapters aufzurufen bevor Du den Listener registrierst.
Meines Wissens wird die Selektion nicht nachträglich aufgerufen.

Zitat

Kann es sein das in der "R" Datei irgendwelche Referenzen zu allen Dateien angelegt wird?

Jip.

Zitat

und diese nun evtl zu einem anderen Pfad zeigt?

Jip.

Zitat

Gibt es im Android Studio eine Funktion die die Projektstruktur neu scant und Änderungen erkennt?

Jip.
Die einfachste Möglichkeit ist das Löschen der R.java: einfach das komplette Build-Verzeichnis wegwerfen und neu übersetzen.
(Im Allgemeinen befindet es sich im Projekt unter app/build)
Alternativ sollte auch Build->Clean Project und anschließendes neubauen gehen.

Machbar ist es.
Ob es empfehlenswert ist hängt immer von der App ab.
Möchtest Du die komplette Aufmerksamkeit des Nutzers auf Dich ziehen, ist es sinnvoll, in eigenen Activities zu arbeiten.

1) Klingt fantastisch. Ja, es ist ein bisschen mehr Aufwand. Aber genau dafür sind die Fragmente ja gedacht: Alles, was logisch zusammenhängt, steckt in einer Activity. Unabhängig davon, was da so angezeigt wird.

2) Ich denke, da wirst Du auf Probleme stoßen. Du müsstest entweder einen Setter in der neuen Activity aufrufen nachdem sie erstellt wurde – wird aber schwierig, weil Deine MainActivity dann schon nix mehr zu melden hat. Oder Du müsstest das Ding irgendwie packen und dem Intent übergeben, was meiner Meinung nach zu viele Ressourcen verbraucht.
(Oh welch Vorteil von Java, dass es ohne sichtbare Zeiger arbeitet und eine Garbage Collection bietet. +scnr+)

Alternativ kannst Du aber auch den NavigationDrawer in einer Subklasse von Application definieren und von jeder Activity darauf zugreifen.

Und natürlich kannst Du das Ding via Copy'n'Paste in jeder Activity entsprechend implementieren.

Ich tendiere jedenfalls zu den Fragmenten.
BTW: Du brauchst die Navigation aber nicht immer. Wenn Du beispielsweise Details anzeigen lassen möchtest, die in einer neuen Activity aufpoppen, dann kann es durchaus sinnvoll sein, den Nutzer das Ding erst beenden zu lassen, bevor er wieder navigieren kann.

BitBucket kann auch Mercurial.