Beiträge von Marco Feltmann

Viel Spannender ist ja die Frage: woher weißt du, dass du da nicht jemandem die Idee klaust?

Zum Glück hast du auf deine Idee absolut keine rechtlichen Schutzmechanismen, da sich eine Idee an sich in Deutschland nicht schützen lässt.
Also flink das Spiel entwickeln und mit Copyright und Ähnlichem schützen lassen (Stichwort: Anwalt Medienrecht).

Die Frage an sich ist aber schon recht schräg.

Wenn du für die Camera Preview eine eigene Activity bereitstellst, dann kannst du dieser Activity explizit sagen, dass sie sich nur im Landscape Mode befinden soll bzw. sich drehen darf.

Weiterhin kannst du meines Wissens die Layouts auch speziell für Landscape und Portrait definieren. Für Landscape ist es layout-land, für Portrait layout-port.
http://developer.android.com/g…ources.html#Compatibility

Wieso versuchst du, über den LocationManager Annahmen darüber zu treffen, ob du Internet hast?

So geht es.

NetworkInfo connectionServiceState = ((ConnectivityManager) getSystemService( Context.CONNECTIVITY_SERVICE )).getActiveNetworkInfo();
connectionServiceState.isConnected();

Du kannst natürlich noch feiner granulieren.

Ich nutze meist folgendes Konstrukt:

// Check if network connection is available and which.
ServiceState phoneServiceState = new ServiceState();
WifiInfo wifiServiceState = ((WifiManager)getSystemService(Context.WIFI_SERVICE)).getConnectionInfo();
NetworkInfo connectionServiceState = ((ConnectivityManager) getSystemService( Context.CONNECTIVITY_SERVICE )).getActiveNetworkInfo();


// None available, so we won't do anything.
if(connectionServiceState == null)
{
    Toast.makeText(this, R.string.errorStringNoInternetConnection, Toast.LENGTH_LONG).show();
    return;
}


// Got either W-LAN access or network access but not roaming
if((connectionServiceState.isConnected() && ((wifiServiceState != null && wifiServiceState.getSupplicantState() == SupplicantState.COMPLETED) || !phoneServiceState.getRoaming())))
{
    // Here we go with our network stuff
}
else
{
    Toast.makeText(this, R.string.errorStringRoaming, Toast.LENGTH_LONG).show();
}

Ach, was solls. Ich nehm nur die Bound-Variante.
onBind() kann man da als Äquivalent zu startService() und onUnbind() zu stopService() werten.
Dann passt das.

Moin,

ich häng da grad vor einem Verständnisproblem bzw. vor einem Designproblem.

Folgendes sei gegeben:

Ich möchte eine Komponente, die auch dann Dinge tut, wenn meine eigentliche App nicht im Vordergrund ist.
(Also irgendwo so etwas wie 'nicht destroyed')

Diese Komponente soll eigenständig mit ihrer Arbeit beginnen und diese zu Ende führen. Alternativ soll diese Komponente auch von einer Activity aus gestoppt werden können.

Das alles deutet ja auf einen Service hin, der via 'startService' losgetreten wird und entweder beim Erreichen eines Zustandes 'stopSelf()' ausführt oder via 'stopService' beendet wird.

Nun habe ich allerdings ein paar weitere Problemchen:
– ich will dem Service ein paar Parameter mitgeben
– ich will Daten zwischen meiner App und dem Service austauschen
– ich will ein paar Methoden des Services manuell ausführen

Dies geht soweit ich weiß nur über etliche Umwege via bindService().

Irgendwie brauche ich aber 'the best of both worlds'.
Wie gehe ich da am Besten vor?

Am Besten gar nicht.
Wenn der Bildschirm aus geht, dann, weil der User grad nix am Display tut. Wenn der User nix am Display tut, dann braucht man auch nix zu sehen.

Du selbst kannst den Bildschirm auch gar nicht beeinflussen sondern der User muss das einstellen.
(Eventuell könntest du die Settings überschreiben, doch siehe Oben: am Besten gar nicht.)

Warum willst du denn, dass das Display an bleibt?
- es frisst Strom
- Touchevents werden angenommen obwohl die eventuell gar nicht notwendig sind
- aus Versehen kann die App beendet werden

Es spricht echt nix dafür.

Genau das meine ich damit.

Also 'Verein' klingt irgendwie nach 'wir haben kein Geld'.
Und 'wir haben kein Geld' beißt sich mit 'Backend as a Service', da diese soweit ich weiß allesamt kostenpflichtig sind.*
Teils mit dem Freemium-Modell, welches für mich schon fast zu 'versteckten Kosten' zählt.

Natürlich nimmt es dir eine ganze Menge an Arbeit ab. Leider geht das mitunter zu Lasten der Individualität.
Da muss man abwägen.

Ich persönlich bau mir die ganzen Backend Dinger allesamt selbst. Die Freiheit ist mir den Aufwand wert.

*) Oh, es gibt eine OpenSource Variante, die man allerdings vermutlich selbst auf den Server bringen muss.
http://www.baasbox.com

Also solange die Uri und die StartId unterschiedlich sind, dürfte da eigentlich nix bei schief gehen.

Du scheinst nicht korrekt vorgegangen zu sein. Ihm fehlen wohl noch diese Zeilen in der AndroidManifest.xml

<activity android:name="com.google.ads.AdActivity" android:configChanges="keyboard|keyboardHidden|orientation"/>

Ich beschäftige mich auch gerade ein wenig mit Services.
Wieso benötigst du zwei von ihnen?

Benutzt du sie via start(), stop() oder nutzt du bind()?
Und was noch viel wichtiger ist: erstellen die Services ihren eigenen Thread oder lässt du sie nacheinander auf dem MainThread laufen?

Hey Wrigley,

du musst dir den Server und die App losgelöst voneinander vor Augen halten.

Wie viele Leute nutzen deine App? Sicherlich mindestens 28.000.000. Das will doch jeder erreichen.
Doch: wie viele Leute nutzen deine App je Gerät?
Bei dem Spreadsheet ist das schwer zu sagen, aber da alle Browser vermutlich auf ein und dasselbe Dokument zugreifen werden rechnen wir mal ganz optimistisch geschätzt mit 28.000.000 Nutzern, die gleichzeitig auf das Dokument zugreifen.
(Sollte das passieren, plane lieber ein paar Tausend Euro mehr für das Datenbankhosting ein. +scnr+)

Natürlich haben alle 28.000.000 Nutzer auch eine App für iPhone oder Android.
Und hier ist dann der Knackpunkt. Wie viele Nutzer hast du pro iPhone/Android? Exakt: 1 Nutzer. Ein Einziger. In Worten: eins.

Auf dem Server mit 28.000.000 Nutzern fliegt dir die SQLite Datenbank im Idealfall jede Nanosekunde drei mal um die Ohren. Auf den Geräten mit einem Nutzer im Idealfall nie (Man muss es natürlich richtig implementieren, damit nix abschmiert. Ich hätte mich bei Android früher mit den Content Providern auseinandersetzen sollen. +husthust+)

Deshalb hast du auf dem Server eben eine vernünftige Multiuser-Datenbank laufen.
Wie du DIE jetzt einstellst, DAS wird spannend für die Zukunft. Du könntest alles mit einem User machen. Das würde ich nicht tun. Denn ein User kann maximal 1x pro Tabelle agieren, der Gewinn ist nicht viel höher als bei SQLite.
Du könntest für jeden Nutzer einen Datenbankuser anlegen. Dann hast du einen ungeheuren Verwaltungsaufwand aber unglaublich gut granulierte Zugriffs- und Sicherheitsoptionen und jeder könnte prima in deiner Datenbank agieren. Gut, beim Schreiben von Daten kann es unter Umständen zu Problemen kommen, doch die dürften unglaublich selten auftreten.

Der Mittelweg wäre ein User je Gruppe. Wir hatten jetzt drei Gruppen definiert. Webuser, iPhone User und Android User. Nun hast du deine 28.000.000 Nutzer in drei Gruppen geteilt: Web mit 28.000.000, Android mit 21.000.000 und iOS mit 7.000.000 Nutzern.

Puh, das war harte Arbeit.
Und wir haben ein Problem...
Wir haben eine MySQL Datenbank im Netz, auf die dein SpreadSheet zugreift.
Und wir haben 28.000.000 Datenbanken auf mobilen Endgeräten, auf die je eine installierte App zugreift.
Wie kommen jetzt die Daten vom Einen zum Andern?

Dafür ist es zunächst wichtig zu wissen, was genau wie und wo bearbeitet werden soll.
Sind die Smartphone Apps nur für den lesenden Zugriff gemacht und im SpreadSheet wird eingetragen, dann ist es weniger eine Synchronisation als viel mehr ein Datendownload. Der von [matthias] und [Funtik] umrissene Ansatz funktioniert da schon sehr gut.
Eventuell gehst du sogar noch einen Schritt weiter und lässt zu festen Zeiten einfach die Daten vom Server exportieren, so dass die Geräte gar nicht an die Informationen in der Datenbank ran müssen.
(Meinetwegen ein Veranstaltungskalender. Der muss ja nicht minütlich aktualisiert werden. Vor Allem, wenn Änderungen anderweitig zur Verfügung gestellt werden reicht auch einmal täglich. Oder finale Spielauswertungen sind nur nach dem Spiel sinnvoll, müssen also nur ein einziges Mal bereit gestellt werden. Je nach Anwendungsfall)

Vermutlich möchtest du aber, dass auch die Apps in die Datenbank auf dem Server schreiben können.
Hier kommt dann Musik ins Spiel, denn das wird alles Andere als trivial.

Erstens ist JSON, SOAP, REST, XML und keine Ahnung was noch alles ein relativ großer Datenhaufen. Für (nahezu) Echtzeitsynchronisation wird das extremer Overhead.
Zweitens wirst du bei 28.000.000 Usern 19 Stunden am Tag kaum was bekommen und an 5 Stunden überschlagen sie sich fast gleichzeitig mit Einträgen.
Du musst also nicht nur dafür sorgen, dass diese Eintragungen allesamt fehlerfrei durchgehen (Transactions!!!) sondern musst dir auch überlegen in welchem Intervall die Daten auf den Endgeräten aktualisiert werden sollen. Vielleicht wenn eine Minute lang keine Einträge mehr kamen und mindestens 10 Änderungen einflossen eine Push Notification senden oder sowas...
Sagte ich schon, dass Echtzeitsynchronisation alles Andere als trivial ist?

Wie dem auch sei, fang einfach mal an. Datenbank erstellen, Ansteuerungsskript(e) erstellen und mal ein bisschen herumspielen.
Die Komplexität und Probleme kommen dann später von ganz allein. Ich hoffe, ich konnte dir ein bis drei kleine Stolpersteine aufzeigen, auf dass du sie nachher identifizieren kannst, wenn du über sie gefallen bist.

Schön, dass Du Deine Anforderungen relativ gut umrissen hast, sonst hätte ich geschrieben "Nimm ne AS/400, ne geilere Datenbank gibt's nicht."

Für dein Vorhaben wäre das allerdings ungefähr so wie mit einer 50m-Luxus-Yacht durch einen dünnen Seitenarm der Donau zu schippern...

Anyways.
SQLite ist sowohl komplett richtig für dich als auch total die falsche Wahl.
Die Frage ist halt das 'wo'.

Auf dem Android Gerät kommst du nicht um eine SQLite Datenbank herum. Alles Andere wäre jedenfalls hochgradiger Implementierungs-, Test- und Resourcenaufwand.
Für die iPhone App würde ich von SQLite die Finger lassen und Core Data nehmen. Alles Andere wäre jedenfalls hochgradiger Implementierungs-, Test- und Resourcenaufwand.
Diese Datenbanken solltest du regelmäßig mit der Datenbank deines Servers synchronisieren.
Ich persönlich halte jedenfalls nix von Apps mit permanenter Internetverbindung.

Auf einem Server fällt SQLite einfach aus. Es ist ein dateibasiertes Datenbankmanagementsystem, das heißt, es kann maximal eine Person zur Zeit auf die gesamte Datenbank zugreifen - lesend wie schreibend. Bei größeren SQL Datenbanken hingegen können mehrere Leute gleichzeitig lesend nicht nur auf eine Datenbank sondern sogar auf eine Tabelle zugreifen. Schreiben kann natürlich nur einer zur Zeit. Doch dafür gibt es ja glücklicherweise Transaktionen, von denen du rege Gebrauch machen solltest.

Dabei ist es egal, ob das jetzt MySQL, MaxDB, MSSQL, Oracle SQL oder PostgreSQL wird. Hat alles seine Stärken und Schwächen.
Was das kostet hängt stark vom Hoster ab. Und er Hoster hängt stark von der bevorzugten Datenbank ab. Allerdings gibt es von 'für lau' über 2€/Monat bis hin zu ein paar Hundert im Jahr so ziemlich alles. Es ist auch eine Frage des Services, den man wünscht.
Am Verbreitesten ist all-inkl.com mit 4,95€/Monat, soweit ich informiert bin.

Ja, das funktioniert tatsächlich.
Danke für den Tipp.

Ist nur ein bisschen Herumgewandle, das geht in Ordnung.

Keine Ahnung.
Ich habe auch das Problem, dass mir die Maps permanent abschmiert, wenn das Gerät aus dem Standby aufwacht. Und zwar mit irgendwelchen kruden ClassDefNotFound Exceptions, die ich überhaupt nicht nachvollziehen kann.

Ich glaub, ich lass einfach die Finger davon und schau mich auf dem OpenStreetMap Sektor um.
Mit der Google Maps Geschichte bin ich jedenfalls mindestens unzufrieden.

Also wenn ich dich richtig verstehe willst du genau das tun, was Sony, Samsung, HTC und Konsorten seit je her und Facebook seit Kurzem machen.
Nämlich einen eigenen Android Launcher schreiben.

Damit dürfte ein Großteil deiner Fragen beantwortet sein.

Wie das geht: ich habe keine Ahnung.
Immerhin hast du jetzt ein paar Ansätze für Google.

Hast du mal alle Extras des Intents ausgelesen?
Nachher ist da nur ein blöder Tippfehler drin.

Also durch intent.getExtras().keySet() durchiterieren und mal schauen was da mit welchen Werten drin steht.

Bundle extras = intent.getExtras();
Log.d("Extras", "Known Extras in Intent "+intent.getClass().getCanonicalName());
for(String key: extras.keySet())
{
  Log.d("Extras", "<"+key+"> "+extras.get(key));
}

Keine Ahnung von den Broadcasts. Für mich klingt das so, als würde das Intent moveBack als Broadcast herhalten müssen, während das onReceive direkt auf den PendingIntent Zugriff hat.

Insofern würde ich mir einmal die Klasse von intent in der onReceive ansehen.
Eventuell landet dort ja der PendingIntent.

Vor dem Aufruf des Intents hat id einen vernünftigen Wert. Das hast du geprüft.
Nach dem Aufruf des Intents ist das übergebene Extra leer. Das hast du geprüft.

Also wird das Extra nicht korrekt übergeben.
Die einzige Unbekannte in dem ganzen System ist das PendingIntent Dingens, welches ich absolut nicht verstehe.
Eventuell läuft da irgendwas schief.

Ich denke mal der eigene Adapter, der Filterable implementiert, wäre der einfachste Weg.

Alternativ kannst du auch an Stelle der Arrays ein anderes Datenformat wählen. Beispielsweise eine Map mit dem Key des CountryCodes und einer ArrayList der dazugehörigen Objekte.

So kommst du dann über den Key an die Objekte ran. Und da diese in einer ArrayList liegen läuft ja vielleicht dein fertiger ArrayAdapter noch.