Beiträge von Marco Feltmann

Die Frage ist hier, was genau Du mit einem 'Alarm' meinst.
Im typischen Sinne ist es genau das, was Du nicht möchtest: jemand definiert einen Zeitpunkt, zu dem die bevorzugte Wecker-App Lärm macht.
Eben deshalb ist es gut und richtig, wenn die Person ihren Alarm selbst speichert. Dann braucht sie sich nicht wundern, dass da plötzlich ein Alarm existiert, den sie nicht zuordnen kann.

Wenn Deine App aber zu einem bestimmten Zeitpunkt/nach einem bestimmten Zeitfenster auf sich aufmerksam machen soll, dann würde ich das eher über einen Timer im Hintergrund (oder einen Service) lösen.

Mir fällt jedenfalls kein Grund ein, warum man dem User einen vorgefertigten Weckeintrag ohne sein Zutun unterjubeln möchte.

Zitat von ChampS

Ich sagte nur das es die Möglichkeit gibt mittels CatLog einen Debug anzuzeigen.

Und Google sagt, dass das bei Apps aus dem Store nicht möglich ist, da die Logging Ausgaben nicht stattfinden.
Ihr habt vermutlich beide recht. Nur ist Ersteres völlig unerheblich.

Für einen Chat würde ich ein fertiges Framework nehmen. Am Besten auf der XMPP Architektur aufbauen und gut.
Auch da solltest Du auf jeden Fall die Finger vom Socket lassen.

Ich persönlich bin übrigens der Meinung, dass das ein ziemlich umfangreiches Projekt für einen Einzelkämpfer wird.

Keine Ahnung ob catlog irgendwas in die App injiziert oder ob Du schlicht und einfach mit einer App mit Debug-Keysign getestet hast.
LogCat kann jedenfalls keine Debug-Logausgaben meiner fertig exportierten .apk anzeigen.

Du willst keine permanente Verbindung zu einem Webserver. Ganz sicher nicht.

Das möchtest Du schön über Push Notifications regeln. (auch keine dauerhafte Verbindung!)

1) Im Prinzip sollte jede Teilkommunikation einen Service haben. Da Du aber keine dauerhafte Verbindung brauchst, reicht auch ein etwas generalisierter Netzwerkservice.

2) Vermischen sollte man das nicht. Socket-Verbindungen sind eh nur gut bei bidirektionalen dauerhaften Verbindungen, die Du ja (wie bereits mehrfach erwähnt) einfach nicht brauchst. Bei einer Socket-Verbindung bist Du permanent am aufbauen, senden, empfangen, zusammenschustern, auswerten und abbauen. Ein HTTP-Request nimmt Dir da einen ganzen Haufen nerviger (und unnützer, da Du ja keine dauerhafte Verbindung brauchst) Arbeit ab.

ChampS
Ich denke, das hat zu Bauernfängermethoden geführt.
Damals™ war es so, dass Du Apps kostenlos einstellen und laden konntest. Wenn Du dann einen Preis eingetragen hast, waren die Updates plötzlich kostenpflichtig. Du musstest also zur Nutzung Deiner bereits legal erworbenen App plötzlich noch was dazu zahlen.

Die Aktionen sind Rabattaktionen. Du kannst von allen eingestellten Apps die Preise permanent anpassen. Und es spricht nichts dagegen, die App für eine Woche für 0,00€ anzubieten. (Außer, dass der PlayStore gegebenenfalls einen Mindestpreis für ein Land definiert hat)
Wenn Du dann die Preise anziehst, interessiert das die Kunden nicht, die sie für 0,00€ erworben haben. Sie bekommen trotzdem alle Updates, da sie die App ja regulär gekauft haben.

Mir ging es nur darum aufzuzeigen, dass sich eine App nicht von 'kostenlos' auf 'kostenpflichtig' umstellen lässt.
Ich hatte bei einem Projekt noch keine Preisvorgaben vom Marketing erhalten und dachte mir: "Hey, machste den Käse während der Beta Phase halt kostenlos."
Ende vom Lied: App unter anderem Package neu hochladen, weil ich es nicht umstellen konnte.
In Zukunft kosten meine Betas für kostenpflichtige Apps einfach 0,00€ (oder 0,50€ Mindestpreis? IDKRN…) und ich setz den Preis dann hoch, wenn ich ne Info habe.

Es ist nicht möglich, eine einmal als kostenlos veröffentlichte App kostenpflichtig zu machen.

Ich kann hier leider nur aus dem Apple iOS Store berichten, aber das Verhältnis dürfte dasselbe sein.

1) Gar nichts mehr. Da wir fast ausschließlich Auftragsarbeiten ausführen, darf der Kunde sich selbst um das Bewerben kümmern.
Es hat sich aber bewährt, mit Promocodes um sich zu schmeißen, jedem Blogger mit Kusshand einen Promocode zur Verfügung zu stellen und bereitwillig und freundlich deren (An)Fragen zu beantworten. Nichts, absolut gar nichts wirkt so gut wie Mundpropaganda*.

2) Lass die Finger davon und investier' die Kohle lieber als 'Verlust' in Promocodes. Geschaltete Werbung wird zwar zur Kenntnis genommen und bei Gelegenheit wird darauf zurückgekommen, doch meist hast Du keinen Einfluss auf Positionierung und Drucklegung der Werbung.
Wenn Du eine spezielle App vermarktest (Handball-Spiele auswerten oder Hundefutter-Verträglichkeitsübersichten) und es gerade perfekt zum Zeitpunkt passt (Neue Saison beginnt, neuer Gammelfleisch–/Tierfutterskandal) kann Werbung in dem der Zielgruppe entsprechenden Publikationen (Handballzeitschrift, Tierzeitschrift) durchaus einen Zugewinn an Downloads und Nutzern bringen. Gezielte Werbung ist auf jeden Fall eine Idee und Investition wert, kostet aber eine gewisse Menge an Energie und Aufwand. Und es ist eine saisonale Lösung, kein Dauerzustand.
Meiner Erfahrung nach werden Werbungen in Android- und anderen Fachmagazinen einfach stumpf ignoriert. Und wenn jemand auf Dich direkt zu kommt und sagt 'Ey, 100€ und ich verbreite Deine App auf allen Kanälen!' sag dankend ab. Das nervt den Endanwender nur.

3) Ja. Die Downloads springen in ungeahnte Höhen. Und flachen danach auch sofort wieder ab. Übrigens das Einzige, was kurzfristig wirklich besser läuft als Mundpropaganda. Ist nur leider nicht sehr planbar.

4) Zusätzlich zum in 1) erwähnten fällt mir nur ein: mach die App großartig. Geile Graphiken, super Usability, sinnvolle Funktionalität, Einzigartigket. Dann spricht es sich schon früher oder später rum.

Also ich habe ja festgestellt, dass so ein Programmiergehirn komplett anders tickt als ein Graphikergehirn.
Sprich: egal wie ich mich anstrenge und was ich versuche, sämtliche meiner visuellen Gehversuche sind eine mittelschwere Katastrophe.

Da ich das Problem nur im privaten Umfeld hatte, habe ich mich da bekannten Graphikern bedient.
Von 'Kostenlos' oder zumindest 'Günstig' würde ich auf jeden Fall die Finger lassen.
Für so ein Icon würde ich ungefähr 100€ rechnen. Das ist übrigens nahezu geschenkt (Stundenlohn wäre gemäß AGD Vergütungstarif 75€).

Also wenn Du eine Firma bist, solltest Du das Ganze definitiv an regionale Designer abtreten. Kurze Wege und schnelle Reaktionszeiten sind bei stark gestiegenen eigenen Ansprüchen unumgänglich. Eventuell könntest Du auch daran denken, einfach einen frisch gebackenen Graphiker/Designer einzustellen.

Wenn Du das ganze natürlich aus Spaß neben dem Studium realisierst, lässt sich vielleicht über die Uni jemand finden, mit dem sich eine Zusammenarbeit realisieren lässt.

Man muss sich bei derlei Zusammenarbeiten immer folgende drei Fragen stellen:
1) was kann der Andere für mich tun?
2) was kann ich für den Anderen tun?
3) wie ausgewogen ist das Ganze?

1) ist in diesem Fall glasklar: er kann Dir ein Icon bauen, damit das Ansehen Deiner App (zumindest auf dem ersten Blick) im Store stark erhöhen und entsprechend direkt (wenngleich nicht messbar) zu einen größeren Erfolg beitragen.

2) ist hingegen schwerer abzuschätzen. Vielleicht braucht die Person Referenzen, dann wäre das natürlich ein Zugewinn für ihn. Oder er sucht noch ein Projekt für sein Studium. Vielleicht gibt es auch eine Absprache, dass er dringend eine App für sich braucht, die Du ihm dann schreiben müsstest. Eventuell braucht die Person auch einfach nur Geld.

3) ist der mit Abstand schwierigste Punkt. Mag sein, dass Du damit leben kannst, dass sich Deine App besser verkauft und der Designer nur am Rande ganz klein dort erwähnt wird, wo es eh keine Sau mitbekommt. Mir wäre das zu wenig Gegenleistung für ein ordentliches App Icon.
Andererseits hätte ich auch keine Lust meine Seele zu verkaufen, indem er mir ein Icon für meine Notizapp erstellt und ich ihm dann für sein Tablet ein kompliziertes CRM/Buchhaltungs/Auftragstool baue. Die sagen wir 8 Stunden, die er dann für Graphiken gebraucht hat, wiegen die zu erwartenden drei Monate Vollzeit für die App echt nicht auf.

Solche Designwettbewerbe wie 99designs.de sind sicherlich ein guter Mittelweg. Und 149€ in der günstigsten Kategorie sind ein absoluter Schnapper.
Ich persönlich hätte damit das Problem, dass mir dann sagen wir 15 Entwürfe präsentiert würden, von dem ich einen Gewinner auslosen muss.
Ich habe keine Möglichkeit zu sagen, dass ich das Grün gern etwas sanfter hätte, die Spielerei mit dem Fischchen dort albern aussieht oder was weiß ich.
Aber eventuell reicht Dir das ja schon.
(Wobei ich die 149€ dann echt lieber einem lokalen Designer in die Hand drücken würde… Ich bin da halt ein bisschen anders als Andere.)

Ich habe ja versucht mich bei der Frage nach der Datenbank eher zurückzuhalten.
Doch da ich die Frage fast schon frech finde, kann ich mich hier nicht zusammennehmen.

1) Was ist so verdammt schwer an einer Datenbank? Das Verständnis. Und das kann Dir kein Framework abnehmen. Da musst Du schon selbst mit klar kommen.
2) 'völlig neue Kategorie' vs. 'eine Art remake' – ja, was denn nun?
3) das Angebot von 'Dropbox oder ähnliches' lässt vermuten, dass Du von verteilter Programmierung absolut keine Ahnung hast. Du hättest nach SVN, git, mercurial oder Ähnliches fragen sollen.

Setz Dich auf Deinen Hosenboden, geh die offiziellen Trainings bis hin zu Saving Data in SQL Databases durch, probiere, probiere, probiere (und verstehe), nutze dann notfalls die gefühlt drölfhunderttausendzwünfundelfzig spezielleren Tutorials und versuche zumindest, es selbst zu schaffen.

1 Monat ist nichts. Gar nichts. Überhaupt nichts. Das reicht mal gerade für die allerallerfundamentalsten Grundlagen.
Lass und nimm Dir Zeit, übe Dich in Geduld und versuche allein voran zu kommen. Greif notfalls zu einem Fachbuch. Frag gezielt bei komprimierten Verständnisproblemen nach.

Ansonsten schreibt Dir jemand Deine App, Du wirst damit garantiert unzufrieden sein (weil es nicht Deinem Wunsch entspricht und es auch nicht von Dir stammt) und reich wirst Du damit so oder so nicht.

Hallo aus Hamburg,

viel Spaß hier und viel Erfolg bei Deinen Projekten.

Zitat von Blitzblaster

Ich denke das ist ähnlich wie im Radio die 80er, die niemals aussterben werden.
Ich denke das man dabei an früher (gute alte Zeit) erinnert wird, wenn man heutzutage solche Spiele spielt.

Wenn es danach geht: es gibt durchaus auch 70er, 60er und 50er, die niemals aussterben werden.
Sollten wir deshalb zurück zu Nadeldruckern und Lochkarten gehen?

(btw, einige Dinge wie Beethovens Neunte Symphonie oder Die Halle Des Bergkönigs sind aus den Jahren 1820 bis 1870 und immer noch gern gehört…)

Um die Horrorpops zu zitieren:

Zitat

She's got the 80s metal down
I don't get why anyone would wanna repeat this more than once

Aber gut, ich bin in den 80ern geboren, eventuell finde ich es deshalb uncool.

ChampS
Unity ist ausgesprochen beliebt bei den Casual Gaming Developer, da Du ziemlich viel plattformübergreifend realisiert bekommst ohne Dich mit den Besonderheiten des Systems auskennen zu müssen.
Hinzu kommt, dass Du bei Games sowieso Dein eigenes UI zimmern musst und dementsprechend kaum Vorgaben der Hersteller zu beachten hast.

Blitzblaster
Kannst Du mir diesen 'Retro Look' Hype erklären? Will damit jeder auf den Minecraft Zug aufspringen?
Ich persönlich fand es damals™ schon immer sehr geil, wenn es den Entwicklern möglich war, mit Tricks und Raffinessen die 2D Pixelgraphik realistisch und pixelfrei aussehen zu lassen. Ich denke da an Klassiker wie Diablo I oder Starcraft I oder Command & Conquer I oder Baldurs Gate I oder auch Metalizer (falls das überhaupt irgendjemand kennt)

Gerade mit der ultramäßigen Auflösung der heutigen Geräte stelle ich mir die Möglichkeiten für richtig genial dargestellte 2D Modelle gigantisch vor.
Und alles, was einem vorgesetzt wird, ist dieser Retro-Look. Meine Güte, selbst mein guter alter Gameboy hat nicht so viele so derbe große 'Pixel' wie der Retro-Look…

Ich meine, heutzutage ist es doch sicherlich mindestens genauso schwer eine gute verpixelte Graphik zu erstellen wie eine gute pixelfreie Graphik.
Warum macht man sich also die Mühe, etwas hässlich darzustellen?

Zitat von SeeeD

CSV benötigt am wenigsten Speicher und ist imho am besten geeignet.

Dem widerspreche ich vehement. Zumindest dem Punkt mit der Eignung.

Dir wird irgendwann auffallen, dass Du das Ausgabeformat umstellen möchtest. Ein Datenfeld hat darin nichts mehr verloren, zwei neue sollen dazu. Schon schauste blöd, wenn Du eine indexbasierte Speicherung via CSV benutzt hast. Schwierig anzupassen.
Verirrt sich ein UTF Zeichen in Dein CSV oder änderst Du den Separator oder kapselst Du die einzelnen Felder statt in doppelte nur noch in einfache Anführungszeichen oder enthalten Deine Felder dummerweise einen Separator – echt schwierig umzusetzen.
(Schau Dir mal den Excel CSV Import an – gefühlte Millionen Möglichkeiten)

XML und JSON bieten mehr Bequemlichkeit beim 'Durchnehmen' für den geringen Preis von etwas mehr Speicherplatz.
Selbst wenn das Mehr an Speicherplatz sagen wir 100% betrüge, so hätten wir einen Unterschied von 50kb zu 100kb – das ist nichts und 50kb sind schon ne Menge Text.

Die beste Optimierung hierfür wäre ein serialisiertes JSON/XML Format, wie beispielsweise Apples 'Binary Property List'.
Ungefähr 25% größer als CSV und damit absolut zu vernachlässigen, doch relativ schwierig in der Implementierung.
Also alles in Allem eine Optimierung, die absolut keinen Sinn für einen derartigen Anwendungsfall ergibt.

Zitat von SeeeD

Die beste Vorgehensweise ist hier, dass du nach dem Login ein Token (UUID/Guid) zurückliefern lässt die eine bestimmte Dauer gültig ist und bei jeder Aktion mitgeschickt und validiert wird

Auch hier widerspreche ich vehement. Datenschutz ist eine Sache, die man keinesfalls auf die leichte Schulter nehmen sollte.
HTTPS als 'Requirement' zu definieren ist seit Heartbleed auch so ein bisschen leichtsinnig.
Statt dessen solltest Du lieber die Google+ API oder die Twitter OAuth API oder eine Facebook OAuth API oder eine OpenID OAuth API oder weiß der Geier was nutzen. (Je mehr desto besser für den Nutzer)
Zum Einen sparst Du Dir den Ärger mit den ganzen Zertifikaten, zum Anderen bietest Du den Leuten das Gefühl, etwas Bekanntes und Vertrautes zu nutzen.
Und drittens: wenn irgendwas schief geht ist das nicht Dein Bier, da Du die Nutzerdaten ja überhaupt nicht in die Hände bekommst.

Fast richtig.
Debug Meldungen sind ausschließlich für die Entwickler gedacht und werden beim normalen Lauf der App nicht mit ausgegeben.
Verbose Meldungen sollten gar nicht erst in der fertigen App landen.

Zitat

Verbose should never be compiled into an application except during development.
Debug logs are compiled in but stripped at runtime.
Error, warning and info logs are always kept.

http://developer.android.com/reference/android/util/Log.html

Interessant ist hier die Frage, wie genau Du die TextViews anzeigst.

Im Allgemeinen überschreibst Du ja pro TextView den OnLongClickListener, welcher einen Parameter vom Typ 'View' besitzt.
Dieser Parameter ist meistens ein Zeiger auf dein Textview. So kommst Du also an das Textview.

Die ID des Eintrags wird ein bisschen schwieriger, aber nicht viel.
Denn Du kannst jedem View einen Tag mitgeben. (ID wäre eine blöde Wahl, da diese eindeutig sein muss – ein Tag jedoch nicht.)
Setzt Du also das Tag eines Views auf die ID des Eintrags, dann wird das ziemlich simpel:

onLongClick(View v) {
  int entry_id = (int)v.getTag();
}

Wenn Du natürlich mit dem ViewHolder Pattern arbeitest, sollte 'getTag()' schon mit dem ViewHolder vergeben sein.
In dem Fall lässt sich der ViewHolder um eine Instanzvariable 'entryID' erweitern.

onLongClick(View view) {
  ViewHolder holder = (ViewHolder)v.getTag();
  int entry_id = holder.getEntryId();
}

Zu viel Logging?

Hast Du Dir die Guides durchgelesen und das Sample angeschaut?
http://developer.android.com/t…ragments/fragment-ui.html

Nun die unweigerliche Frage: wozu das Ganze?
Es gibt absolut keinen plausiblen Grund ein Gerät eindeutig zu identifizieren.
Bei mir werden Apps mit 'kann auf ihre Geräteidentifikation zugreifen' stumpf nicht installiert.

Zur Funktionsweise
Du generierst Dir eine UUID aus einer Zeichenkette, die aus drei Teilen besteht:
Device ID des Herstellers (IMEI/MEID), Seriennummer der SIM (ICCID) und Android ID.

Packt der Benutzer seine Zweit-SIM rein oder aktualisiert sein Android System, sprich: ändert sich irgend etwas an der Konfiguration des Gerätes, dann bekommst Du eine neue UUID. Das ist (meiner Meinung nach) totaler Bullshit.

Zur eindeutigen Identifikation eines Gerätes reicht die IMEI/MEID, die Du via telephonyManager.getDeviceId() bekommst.
Alles Andere ist der Versuch der eindeutigen Benutzeridentifizierung und es gibt viele Möglichkeiten, das Ergebnis zu verfälschen.
(Einige custom roms wie cyanogen bieten beispielsweise die Möglichkeit, Fake-Informationen zurückzugeben.)

Der von Google empfohlene Weg zur eindeutigen Identifizierung des Anwenders ist die Nutzung der Google+ API.
Vergleiche dazu die Diskussion auf einer entsprechenden StackOverflow Frage (Englisch)

Aber nach wie vor lautet die Frage: warum möchtest Du ein Gerät eindeutig identifizieren?