Beiträge von Marco Feltmann

  • Infos zum Bluetooth Buffer und dem Einlesen von Daten

    Grundlagen Netzwerkkommunikation. :)


    Wie groß der Buffer ist dürfte Dir eigentlich vollkommen egal sein.


    Du bekommst es über buffer.capacity() heraus und kannst davon ausgehen, dass es beim nächsten Gerät anders aussieht.
    Im Prinzip ist die Größe des Buffers für Dich also wie gesagt völlig egal.


    Diese Buffer haben die Eigenschaft, nicht überlaufen zu können. Sollten sie 'zu voll' laufen, wird einfach Altes ersetzt.


    Wann immer möglich musst Du den Buffer also auslesen und bearbeitest die Informationen idealerweise auch gleich.


    Zur zweiten Frage: das liegt daran, wie die Daten übertragen werden. Du hast absolut keinen Einfluss darauf, wie diese Daten übertragen werden.
    Eventuell ist Bluetooth so konfiguriert, dass lieber viele viele kleine Pakete als wenige große Pakete verschickt werden.
    Dank TCP/IP wird Dir zwar garantiert, dass die Pakete alle ankommen und zwar in der Reihenfolge, in der sie verschickt wurden, doch über die Art und Weise dieses Ankommens wird Dir nichts garantiert. Es kann also beispielsweise auch einige Sekunden zwischen 'te' und 'st' geben.


    Wie dem auch sei, Du solltest Dir für die Übertragung ein bestimmtes Datenschema ausdenken. Es hat sich eine Kombination aus Startsequenz, Längenangabe, Wert und Endsequenz etabliert.
    Wenn Du eine Startsequenz erhältst kannst Du danach die Längenangabe auswerten, dann den Wert bis zur Endsequenz.
    Natürlich musst Du noch ein paar Logikprüfungen einbauen. Stimmt die Längenangabe mit der Länge des Wertes überein?


    Wann immer Du ein komplettes Paket von Start- bis Endsequenz erhalten hast, kannst Du den temporären Wert als fertigen Wert nehmen und auswerten.
    Natürlich ist das Ganze etwas aufwändig, weshalb so etwas eher in einen Hintergrundthread gehört.

  • Bluetooth Device Liste anzeigen, nach dem Bluetooth einschalten

    Das liegt ganz einfach daran, dass direkt nach dem Einschalten diverse Dinge getan werden müssen, bevor alle Geräte in der Umgebung abgefragt werden können. Die Liste ist also direkt nach dem Einschalten von Bluetooth noch leer und benötigt etwas Zeit, um Inhalte zu bekommen.


    Vergleiche Dokumentation:
    http://developer.android.com/r…apter.html#startDiscovery()


    Der BluetoothAdapter meldet sich dann über Broadcast Actions und teilt Dir mit, wann alles fertig ist.
    Vermutlich möchtest Du auf ACTION_DISCOVERY_FINISHED lauschen, denn das teilt Dir mit, dass alle Geräte im Umkreis gefunden wurden und ihre Namen zur Verfügung stehen.


    Dazu musst Du nur noch wissen, wie man mit Broadcast Receivern arbeitet.

  • GridView: height parameter in onMeasure fehlt?

    Tja, was soll ich sagen? Irgendwas haut mir die Informationen wieder durcheinander:



    Um ein super.onMeasure() komme ich in der direkten Subklasse nicht herum. Wenn ich es weglasse, hagelt es eine NullPointerException in den Tiefen des GridViews.

  • [GAME] 3.2 Seconds

    Schönes Prinzip und recht hübsch umgesetzt.
    Beim ersten Spiel hat es mich verwirrt, dass keine Info darüber kam, dass die nächste Runde begonnen hat.


    Was mich persönlich allerdings tierisch nervt ist die Farbänderung der Appleiste oben. Da bekommen meine Augen jedes mal einen Sekundenaussetzer, weil das so unerwartet kommt und irgendwie stört.


    Ansonsten sehr schön. :)

  • Die rechtlichen Aspekte beim App release

    0) IANAL (I Am Not A Lawyer), sämtliche Aussagen werden also keinerlei Bestand vor Gericht haben.
    Wenn Du es genau wissen willst, frag einen Anwalt Deiner Wahl. :)


    1) Wegen des Impressums sind da diverse Meinungen richtig. Wie Du schon richtig gesagt hast, beziehen sich die meisten Impressumregelungen auf Webseiten.
    Gemäß §312c BGB muss sich der Kunden vor Abschluss eines Fernabsatzvertrages über eine ladungsfähige Adresse informieren können. Fällt also irgendwie flach. ;) Hier solltest Du im Store eine aussagekräfte Website anbieten, die dann gemäß §5 Telemediengesetz ein Impressum darbietet.


    Besagtes Telemediengesetz spricht von geschäftsmäßige, in der Regel gegen Entgelt angebotene Telemedien und hier ist die Definition schwammig. Du bietest Deine App den Leuten ja eben nicht gegen ein Entgelt an und schon gar nicht geschäftsmäßig.
    Wenn man noch genauer darauf rumreitet, dann sind Telemedien klar definiert:

    Zitat von §1 TMG

    (1) Dieses Gesetz gilt für alle elektronischen Informations- und Kommunikationsdienste, soweit sie nicht Telekommunikationsdienste nach § 3 Nr. 24 des Telekommunikationsgesetzes, die ganz in der Übertragung von Signalen über Telekommunikationsnetze bestehen, telekommunikationsgestützte Dienste nach § 3 Nr. 25 des Telekommunikationsgesetzes oder Rundfunk nach § 2 des Rundfunkstaatsvertrages sind (Telemedien). Dieses Gesetz gilt für alle Anbieter einschließlich der öffentlichen Stellen unabhängig davon, ob für die Nutzung ein Entgelt erhoben wird.


    Salopp gesagt: nimm die Werbung und jeden anderen Internetzugriff raus, so dass die App nur offline läuft, schon fällt sie nicht unter das Telemediengesetz und den Quatsch mit dem Impressum kannst Du Dir theoretisch sparen.


    Ansonsten ist der Inhalt eines Impressums ebenfalls klar definiert:

    Zitat von §5 TMG
    • den Namen und die Anschrift, unter der sie niedergelassen sind, bei juristischen Personen zusätzlich die Rechtsform, den Vertretungsberechtigten und, sofern Angaben über das Kapital der Gesellschaft gemacht werden, das Stamm- oder Grundkapital sowie, wenn nicht alle in Geld zu leistenden Einlagen eingezahlt sind, der Gesamtbetrag der ausstehenden Einlagen,
    • Angaben, die eine schnelle elektronische Kontaktaufnahme und unmittelbare Kommunikation mit ihnen ermöglichen, einschließlich der Adresse der elektronischen Post,
      [...]


    Die meisten Impressumgeneratoren erstellen noch einen Haftungsausschluss, welcher mehr in den Bereich der AGB geht. Das wird für Apps problematisch bis unmöglich und braucht auch nicht in das Impressum.


    0) IANAL, alle Angaben ohne Gewähr vor Gericht stand halten zu können.


    2) Das weise Internet hat fast recht. Das BGB gilt immer und wenn die AGB dem BGB widersprechen, sind diese Punkte der AGB (oder je nach Formulierung die gesamten AGB) ungültig. Du hast wieder mehrere Optionen.

    • Pack die AGB auf die Website zur App, welche Du im App Store verlinkst. Dann kann der User sie vor Download/Installation der App lesen und mit der Nutzung der App akzeptiert er sie dann (musst Du so in die AGB hineinformulieren.)
    • Spar Dir die AGB und schreib an erster Stelle in den Beschreibungstext im Store, dass das BGB gilt.
    • Pack die AGB in den Beschreibungstext im Store.


    0) IANAL (ja, das kommt jetzt an jeder Zwischenpassage.)


    3) Datenschutzerklärungen sind immer eine gute Idee. Wieder gilt: Der Nutzer sollte sie vor Installation/Nutzung gelesen haben. Also hilft wieder eine Website mit all diesen Informationen.
    Obacht: pack in die Datenschutzerklärung nur hinein, was Du auch wirklich beurteilen kannst! Nutzt Du Google Ad Services für Deine Werbung, verlinke auch auf deren Datenschutzerklärung etc.pp. Weise auf jeden Fall darauf hin, dass Anbieter anderer Frameworks andere Dinge speichern könnten als Du es tust. Falls nicht und Dein Werbeanbieter verkauft irgendwelche gesammelten Daten, hast Du sonst den Papierkrieg am Hals.


    0) IANAL


    4) Ich würde von diesem 'komplett in Englisch' Abstand nehmen. Das macht die ganze Sache für Dich nämlich um Einiges leichter. In Android kannst Du alle möglichen Ressourcen an Hand der Spracheinstellung des Gerätes erstellen lassen. Ist das Gerät auf Deutsch gestellt, enthält Dein Layout/Menü/Wasauchimmer einen Hinweis auf die AGB und das Impressum. Ansonsten enthält es diese Hinweise nicht.
    Dann bietest Du die Datenschutzerklärung einmal in Englisch und einmal in Deutsch an. Das Impressum und die AGB hingegen bietest Du nur in Deutsch an, da sie in anderen Sprachen ja nie angezeigt werden können.
    Lokalisieren ist immer eine gute Idee, steigert den Wert der App und ist nun wirklich nicht allzu kompliziert.


    0) IANAL


    5) Die Gewerbeanmeldung halte ich für eine einzelne werbefinanzierte App im Store für absolut überzogen. Selbst wenn es statt 5€ im Monat 250€ im Jahr werden (ich halte die 5€/Monat schon für zu hoch gegriffen), kannst Du das bequem über deine Einkommenssteuer verwursten.
    Selbst wenn Du einmal im Auftrag eines Anderen etwas programmierst (also im rechtlichen Sinne eine Dienstleistung erbringst) und Dir damit 250€ verdienst, benötigst Du dafür noch kein Gewerbe. Sobald das Ganze eine gewisse Regelmäßigkeit besitzt, mit der Du diese Programmierdienstleistung erbringst bzw. sobald Du kostenpflichtige Apps in den Store stellst, die einen höheren Umsatz bringen als erwartet, solltest Du über die Anmeldung eines Kleingewerbes nachdenken.
    Sollte es natürlich absehbar sein, dass Du mit diesem Programm regelmäßige Werbeeinnahmen in Höhe von mindestens 50€/Woche hast, wäre eine Gewerbeanmeldung allerdings eine sehr gute Idee. ;)
    Die Eintragung ins Handelsregister ist für Kleingewerbe (zumindest hier in Hamburg) nicht notwendig, aber freiwillig möglich.


    0) IANAL


    6) Nö, auf die Werbefinanzierung brauchst Du nicht hinweisen. Das wird er ja sehen. Vielleicht sogar schon auf den Screenshots, wenn Du so richtig fair bist.
    Vielleicht wird er es sich auch denken. Du musst halt damit leben, dass der User beim Anblick der Werbung die App sofort schließt und wieder runterschmeißt. Würde ich zumindest tun. ;)

  • Nach Bildwechsel View/Activity aktualisieren

    Spontan würde ich darauf tippen:

    Zitat

    Change the desired orientation of this activity. If the activity is currently in the foreground or otherwise impacting the screen orientation, the screen will immediately be changed (possibly causing the activity to be restarted). Otherwise, this will be used the next time the activity is visible.

  • Wohin mit dem Code? In die Activity oder in die Fragment Klasse?

    Also grundsätzlich für diesen speziellen Fall: gar nicht.
    Es ist eigentlich nicht im Sinne der User Experience, wenn man auf einem Fragment einen Button drückt der auf einem anderen Fragment die Darstellung verändert.
    Aber ich denke mal, Du machst das symbolisch beispielsweise als Navigationselement links und Contentarea rechts.


    Wie dem auch sei, Dir fehlt scheinbar noch eine ganz wichtige Verständniskomponente für die Fragmente.
    Mit den Fragmenten kannst Du User Interfaces unterschiedlich zusammen bauen, ohne dass Du die Logik mehrfach implementieren musst.


    Am Liebsten wird das für die Unterscheidung Tablet - Phone genutzt.


    TabletLayout wäre dann sinngemäß


    Und das PhoneLayout wäre ungefähr


    Du siehst also: auf dem Tablet präsentiert eine Activity zwei Fragmente, auf dem Phone präsentieren hingegen zwei Activities jeweils ein Fragment.


    Insofern wird die Sache hoffentlich etwas klarer: die Activity sollte immer die Interaktion zwischen den Fragmenten steuern. Denn die Fragmente selbst wissen im Allgemeinen überhaupt nichts voneinander. Die Activity hingegen weiß alles von den Fragmenten, da sie diese ja anzeigt.


    Der komplett richtige Weg wäre also:
    • Dein Button-Fragment implementiert die OnClick für den Button. (Das Fragment verwaltet ALLE seine UI Elemente selbst – dafür ist es da.)
    • Dein Button-Fragment speichert sich eine Referenz auf die aufrufende Activity, welche ein paar Callbacks definiert. (onAttach() im Fragment gibt einen Parameter auf die Activity mit, welche Du casten kannst.)
    • Deine OnClick Implementierung für den Button ruft irgendwann besagtes Callback der Activity auf.
    • Die Activity regelt dann den Rest.
    Pro-Tipp:
    • Definiere für die Callbacks ein ButtonClickCallbackInterface.


    Wenn Du nun eine 1-Activity-Tablet-Lösung hast, dann wird in dieser Callback-Methode Deiner einen Activity das andere Fragment entsprechend bearbeitet.
    (Hier also: eine Methode aufgerufen, die den Text des TextView ändert. Im Navigationsfall: das Fragment gegen ein Anderes austauschen)
    Wenn Du eine 2-Activity-Phone-Lösung hast, dann wird in dieser Callback-Methode Deiner ersten Activity alles für den Aufruf der zweiten Activity vorbereitet, der zu setzende Text übergeben und die zweite Activity setzt dann den Text im TextEdit des Fragments auf den gewünschten Wert.

  • GridView: height parameter in onMeasure fehlt?

    Wie viele GridViews hast Du erstellt, bei deren Subviews Du die OnMeasure überschrieben hast?


    Ein GridView ist (wie der Name schon sagt) ein View, kein Layout.


    Code
    java.lang.Object
   ↳	android.view.View
 	   ↳	android.view.ViewGroup
 	 	   ↳	android.widget.AdapterView<T extends android.widget.Adapter>
 	 	 	   ↳	android.widget.AbsListView
 	 	 	 	   ↳	android.widget.GridView


    Selbst Überschreiben war nur bedingt erfolgreich, da zwar einmal meinen manuellen Measure-Werte an die Subviews weitergegeben wurden, onMeasure aber mehrfach aufgerufen wird und entsprechend n-1 mal mit einer MeasureSpec von 0 als Höhenwert aufgerufen wird.


    Ich versuche dann als Nächstes mal das GridLayout.

    Code
    java.lang.Object
   ↳	android.view.View
 	   ↳	android.view.ViewGroup
 	 	   ↳	android.widget.GridLayout

  • Nach Bildwechsel View/Activity aktualisieren

    Schwer zu sagen. Normalerweise sollte es möglich sein. Wenn Du sicherstellen kannst, dass Deine Message auf demselben Thread ausgeführt wird.
    Gegebenenfalls solltest Du noch ein Flag in Deiner Activity setzen, dass beim Wechsel dort hin zurück durch den Activity Life Cycle abgeholt wird.
    Ansonsten kann es nämlich durchaus sein, dass beim Aufruf der MainActivity diese auf einen Standardwert zurückgesetzt wird und es daher nur für Dich so aussieht als hätte sich das Bild nicht geändert.

  • EventBus.getDefault() wird zur Laufzeit nicht gefunden - Kein Fehler beim Erstellen

    Es gibt keinen Ersatz für das NSNotificationCenter.
    Tu Dir selbst einen Gefallen und mach es gleich richtig anstatt zu versuchen auf Biegen und Brechen die iOS App zu portieren. Einerseits wird es nicht klappen und andererseits ist die User Experience eine völlig andere. Du machst die Dinge also nur schlimmer statt besser.


    Dein EventBus wird offenbar nicht mit ins fertige APK geschnürt. Deshalb ist es zur Compilezeit da, auf dem Gerät aber nicht mehr.

  • Nach Bildwechsel View/Activity aktualisieren

    Die Frage ist, wo Du Dein Bild geändert haben möchtest. Wenn Deine ConnectionActivity vorn ist, kannst Du hinten rum so viel an den Bildern ändern wollen wie Du willst. Die Activity ist hinten, also dürfte da nicht allzu viel Leistung darauf verschwendet werden dort irgendetwas anzupassen.


    Der Toast hingegen ist ein ganz anderes Prinzip und funktioniert auch activityübergreifend.


    Ich vermute, Du möchtest irgendwelche Bilder aus dem Internet laden und nach erfolgtem Download anzeigen.
    Dafür wäre vermutlich ein passender Loader die bessere Herangehensweise.

  • GridView: height parameter in onMeasure fehlt?

    Moin,


    ich verzweifel hier gerade an einer Kleinigkeit.
    Beim Bauen und testen eines neuen Layouts war ich mit dem Ergebnis ganz zufrieden, bis ich das Layout in einen GridView gepackt habe.


    Hier wird mir in der onMeasure() eine komplett sinn- und inhaltlose heightMeasureSpec übergeben. (Höhe: 0, Typ: UNKNOWN)
    Das zerschießt mir natürlich das komplette Layout.
    Kennt das jemand und hat sich da schon erfolgreich gegen wehren können?