Beiträge von Marco Feltmann

Eyup. Bei gleichberechtigten Rechenoperationen (Punktrechnung) wird explizit von links nach rechts durchgerechnet.
Und 480/100 ist als Integerwert 4.
4 * 10.42 ist dann 41.68
480/100.0 (oder 480/100f) hingegen wird zu 4.8 und 4.8 * 10.42 zu 50.016

Die Ungenauigkeit von Floats wirst du in diesem Fall noch nicht zu spüren bekommen.
Das bekommst du erst bei Entfernungsberechnungen im Kilometerbereich aus GPS Koordinaten oder bei Kreisberechnungen in ähnlich großen oder noch größeren Dimensionen.

Auch spaßig: Vergleiche, beispielsweise if(floatValue == 1.0).
Geht fast immer schief, weil floatValue irgendwas bei 1.00000000000009345 ist.

Moin nach NRW.

Zitat von Kogoro

Auch würde ich für sowas dann ein privates Unterforum mit einer Gruppe vorschlagen(Nur Gruppe sieht das Forum) müsste man mal nachfragen, wenn wir sowas starten wollen

Das klingt sinnvoll.

Zitat von Kogoro

Also ich bin meistens für das Auslassen und dann aber eine "ExtraActivity" als Shop gewissermaßen.

Sehr guter Kompromiss.

Zitat von Kogoro

Auch würde man gucken müssen, wie evt. Gewinne aufgeteilt werden, welche Lizenz angewendet wird,...

Naja, wie gesagt: Gewinne zur Finanzierung des Forums. Als Lizenz wäre doch die LGPL prima. Offener und freier geht es nicht.

Zitat von Vyax

Das Problem ist, ich habe kein Android Gerät.

Das Problem ist, dass der Emulator eine Katastrophe ist. Er verhält sich komplett anders als ein Gerät, ist bis zu 10x langsamer und bietet für Sensoren keinerlei simulierten Werte.

Weiterhin unterscheiden sich die Bedienkonzepte sowie das Look'n'Feel von Android und iOS doch gewaltig.

Wenn du nicht zufällig total auf Java stehst und dich gern weiterbilden möchtest, solltest du eventuell überlegen das Projekt an einen findigen Android-Entwickler zu übergeben.

Ansonsten kann es durchaus sinnvoll sein, den UI-Ansatz für Android zu überdenken.
Brauchst du die Sections dringend? Ist ein Grouped ListView wirklich von Nöten?

Apps funktionieren besser, wenn sie den Konzepten des OS folgen. Und die Standardkonzepte haben weder Sections noch Gruppen...

Natürlich ist das ein großes Projekt. Deshalb sprach ich ja von einem Community-OpenSource-Projekt.

Auslassen vs. Sperren, das alte Spiel.
Vorteil beim Auslassen: man wird nicht durch nicht anwählbare Elemente erschlagen.
Nachteil beim Auslassen: man sieht nicht, was die App noch so alles kann.

Vorteil beim Sperren: man sieht, was die App noch so alles kann und kann interessante Dinge herunterladen.
Nachtei beim Sperren: man wird durch nicht anwählbare Elemente erschlagen.

Natürlich ist Planung das A und O. Das ist sie immer.
Zum Glück gibt es ja Scrum, so kann die Planung gleichermaßen strikt und flexibel sein.

Sehe ich ganz genau so.
Allerdings ist das für mich eher eine Herausforderung als ein Grund es zu lassen.

Beispiel Raumplan:
Schülerliste gibt es: man kann den Namen der Schüler aus der Liste holen.
Schülerliste gibt es nicht: man tippt den Namen der Schüler händisch ein.
Perfekterweise alles in einem Control. Man tippt also 'L' und es wird einem aus der Liste 'Lucas de Vil' vorgeschlagen. Wenn es die Liste nicht gibt, gibt es auch keine Vorschläge.

Die Serienbrieffunktion könnte beispielsweise ausgegraut mit schwarzem Ausrufezeichen auf gelbem Dreieck versehen sein, wenn es keine Schülerliste gibt.
Ein Touch darauf erklärt dann: "Gibt keine Schülerlisten-App. [Herunterladen!] [Dann halt nicht...]". Und das natürlich für die anderen Module analog.

Du brauchst eh pro App mindestens zwei Activities. Liste und Eingaben. Es wäre natürlich super, ließe sich die Liste für die App und auch für activityForResult() mit unterschiedlichen OnClickListenern versehen...

So langsam wird das Thema spannend.

[Kogoro]
Ich bin in diesem Falle komplett anderer Meinung als du. Tatsächlich halte ich für diese undefinierten und irgendwie auch wirren Anforderungen für prädestiniert für den modularen Aufbau.

Beispiel:
- Sitzpläne
- Notenberechnung
- Stoffplanung
- Tagebuch
- Klassenlisten
- Mitarbeitsnotizen

Hier sieht man beispielsweise, dass man noch mehrere zusätzliche Informationen benötigt - oder eben auch nicht.
- Raumplan (Für Sitzplätze)
- Schülerliste (Für Sitzplätze, Notenberechnung, Klassenliste, Mitarbeitsnotizen, Tagebuch)

Es wäre also perfekt, wenn man für jede Sache eine eigene App und damit eine eigene Activity anbieten könnte.
Natürlich müsste man die Activity Actions ordentlich benennen.

Man könnte und sollte also regen Gebrauch von activityForResult() machen.
Also quasi:

Intent intent = new Intent(Intent.ACTION_LIST_ALL_ROOMS);
context.activityForResult(intent);

Es würde auch dafür sorgen, dass jeder Lehrer beispielsweise seine eigene Raumlisten-App nutzen kann, so er denn möchte.

[maalbert]
Dort, wo ich her komme, sind Lehrer keine Beamten.
(Gut, dort, wo ich wohne, schon.)

Was meinst du mit 'andere Exoten'? Waldorfschule mit Klassenbuch aus selbst geschöpftem Papier gebunden in selbst gegerbtes Wildleder und beschrieben mit selbst gewonnener Tinte?
(Ich sollte aufhören darüber zu lästern. Immerhin können sie Gerüchten zufolge ihren Namen tanzen, was ich definitiv nicht kann.)
Jedenfalls verstehe ich nicht ganz, inwieweit sich die Anforderungen eines Gymnasiallehrers bezüglich einer Kalenderapp von denen eines Gesamtschullehrers, Grundschullehrers, Berufsschullehrers oder Fahrlehrers unterscheiden...

Nun, BirgitLachner meinte, ihre Konzepte würden bereits existieren. Deine Hoffnung ist also nicht ganz unbegründet.

Ich fürchte, ich verstehe das Grundproblem nicht so ganz.

Wenn du deine Befehlsliste erweitern willst/musst, dann musst du das sowohl im Client als auch im Server machen.

In deinem Fall hätte ich (verdammter C-Hintergrund. ^^) statt einer Klasse für jeden Befehl einfach ein Enum für die Befehle gebaut.
Die IFs wird man ja nicht los, aber man kann sie kurz halten.

Als grobes Beispiel:

enum Command {
  int CONNECT = 0;
  int DISCONNECT = 1;
  int RECONNECT = 2;
};


void handleCommand(Command c)
{
  switch(c)
  {
    case CONNECT:
      connect();
      break;
    case DISCONNECT:
      disconnect();
      break;
    case RECONNECT:
      reconnect();
      break;
    default:
      alertNotSupported(c);
      break;
  }
}


void reconnect()
{
  disconnect();
  connect();
}


void disconnect()
{
  // Übertragung killen, Socket freigeben 
}


void connect()
{
  // Neuen Socket anlegen
}


void alertNotSupported(c)
{
  // Natürlich sollte das anders erfolgen als über eine schöne Konsolenausgabe. ;)
  printf("Command %i not supported by now.", c);
}

So hast du einerseits die Hilfe, dass dir ein nicht implementierter Befehl sofort auffällt.
Andererseits musst du noch immer an drei Stellen pro Seite anpassen: ENUM, Switch und eine neue Funktion.
Nur wirst du ohne Anpassungen niemals neue Befehle hinzugefügt bekommen.

Dein Objektansatz ist zwar recht schön, doch verstößt er für mich gegen das Prinzip der Kapselung. Es sollten ja Daten und Logik getrennt sein.
Wirklich übersichtlicher wirkt es übrigens auch nicht.

Ginge statt Übergabe von Context auch einfach ein getBaseContext() in der Static Methode?

Die "Dokumentation" für das Widget ist ja schon recht kurz gehalten, aber interessant.
Von Wegen 'keine API'... Was glauben die, wie deren Widget angesteuert wird? +augen roll+

Also entweder jemand hat gelogen oder hatte keine Ahnung.
Richtig wäre 'Wir geben die API nicht außerhalb des Widgets frei.'.

Wenn du die API Seite direkt aufrufst, bekommst du immerhin einen gekürzten HTML-Wust.

http://ergebnisdienst.fussball.de/api/fbed/fussballdeAPI.php?Saison=1213&WettbewerbID=014201

Schwierig wird nur das Herausfinden der WettbewerbsID. Jedenfalls gibt der Krams auch nur das komplett fertige Widget als HTML aus, allerdings ohne Abfrage der Website.

Das ist zwar weniger dunkelgrau als vielmehr Anthrazit, weshalb ich lieber die Website 'meines' Vereins direkt fragen würde als über einen Zusatzanbieter wie Fussball.de zu gehen.

distanceTo(Location) ist eine Methode von Location.
Das bedeutet, dass centerLocation (getreu des Namens) wohl eine Location sein muss, die sich in der Mitte (also bei der Annotation) befindet.

Moin Vyax,

also meine Kontakte-App kann das nicht. Aber meine Settings können das.
Ich selbst musste mir den Kram selbst basteln. Vergleiche hier.

Allerdings kann man wohl schick mit den Separatoren machen:
http://bartinger.at/listview-with-sectionsseparators/

Also was Fertiges sieht eher mau aus.
Es sei denn, du versuchst das ExpandleListView und schaffst es, ihm das Ein- und Ausklappen zu verbieten

Zitat von CdWechsler

Hallo an alle,

ich habe eine frage zum folgenden code:

Code

VisibleRegion vr = myMap.getProjection().getVisibleRegion();


double left = vr.latLngBounds.southwest.longitude;
double top = vr.latLngBounds.northeast.latitude;
double right = vr.latLngBounds.northeast.longitude;
double bottom = vr.latLngBounds.southwest.latitude;

...

meine frage ist, wie weit die spannweite des boundingboxes vom zentrum ist? also jetzt mit dem oben dargestellten code.

Alles anzeigen

vermutlich (vr.latLngBounds.northeast.longitude+vr.latLngBounds.southwest.longitude)/2, (vr.latLngBounds.northeast.latitude+vr.latLngBounds.southwest.latitude)/2

Muss aber nicht. Du kannst ja soweit ich weiß für northeast und southwest beliebige Koordinaten an den Konstruktor übergeben.

Auch gehen dürfte centerLocation.distanceTo(northeast); sowie centerLocation.distanceTo(southwest); für die Entfernungen zu den jeweiligen Eckpunkten.
(Obacht: Erdkrümmung wird nicht mit berechnet.)

Mit anderen Worten: reine Mathematik.

Das folgende Wissen stammt aus der Objective-C Welt und muss so nicht zu 100% auf Java portierbar sein. Ich finde es aber logisch und es funktioniert ähnlich, deshalb tue ich es dennoch.

Zum Einen gibt es zwei Arten von Objekten in Java: Klassenobjekte und Instanzobjekte.
Was immer man als Klasse erstellt ist an und für sich schon ein Objekt, denn es reagiert auf Nachrichten.

new Class() ruft den Konstruktor des Klassenobjekts auf und legt ein Instanzobjekt nach den Vorgaben des gewählten Konstruktors an.
Weiterhin verstehe ich 'static' als Klassenmethoden und non-static als Instanzmethoden.

Das heißt, die als static gekennzeichneten Methoden benötigen zum Aufruf ausschließlich das Klassenobjekt.
Deshalb gehen Dinge wie Collections.reverse(List<T>);

Alle anderem Methoden benötigen zum Aufruf ein Instanzobjekt.
Deshalb geht nicht Array.add(object);, sondern nur (new Array()).add(object);

Demnach hast du zwei simple Möglichkeiten.
Wann immer du dein Tools-Objekt benötigst, baust du dir ein Instanzobjekt davon.
Also quasi (new Tools()).vibrate(500);

Sinnvoll kann es aber auch sein, vibrate als Klassenmethode zu implementieren.
Salopp:

public class Tools...{
   public static void vibrate(int laenge) {
    /* Well, it's Java. 
    Das Device muss keinen Vibrator-Service haben, irgendwas könnte schief gehen etc.pp. 
    Errorhandling und Exceptionhandling sind also im Produktivcode angebracht. ;) */
    ((Vibrator)getSystemService(Context.VIBRATOR_SERVICE)).vibrate(laenge);
   }
}

Es kann natürlich durchaus passieren, dass du aus einer Static-Methode auf eine Non-Static Methode zugreifen möchtest, was dann zu Problemen führen kann.
Aber ich denke, der generelle Ablauf dürfte erkennbar sein.

Was mir bei solchen grandiosen megatollen nie dagewesenen App-Ideen immer wieder fehlt ist die genaue Definition der User Experience.
Sprich: wie will ich das Ding bedienen können.
(Dass der von Frau Lechner genannte iOS Entwickler sein Programm nicht auf Android bringen will kann ich übrigens komplett nachvollziehen.)

Entweder sind derartige Anwendungen zu starr und nicht intuitiv genug oder so flexibel, dass die Bedienung auf Grund der ganzen Optionen irgendwann ein Informatikstudium voraussetzt.
Es wäre also sehr wichtig zu wissen, wie das fertige Produkt nach Ansicht der Lehrkörperschaft zu bedienen sein soll.

[Kogoro]
Du hast völlig recht, dass da Informationen fehlen. Offenbar hatte titus sich ja mal gemeldet, eventuell hat er da mehr Hintergrundinfos.
Ein stehendes Konzept ist schon mal ein guter Anfang, es muss nur noch funktionieren.
Und die Einschätzung mit dem großen Projekt sehe ich genauso. Das wird nicht mal eben an einem Wochenende fertig.

Aber vielleicht ließe sich daraus ja ein OpenSource Community Projekt machen?
Dann hat erst einmal niemand was davon (obwohl: das Teil für Geld in den PlayStore stellen und damit dann das Forum mitfinanzieren wäre doch eine Option), aber vielleicht fetzt das ja.

[maalbert]
Mag ja sein, dass ich im falschen Beruf bin, aber ich persönlich ziehe Papier jeder elektronischen Lösung vor.

Ja, tote Bäume wiegen. Nur: die Schüler müssen auch schleppen.
Notizen kritzeln sich um gefühlt 80% schneller auf ein Blatt Papier als dass sie sich auf eine virtuelle Tastatur tippen lassen.
Zumal das Blatt Papier (sofern in einem vernünftigen Umfeld gehalten) ungefähr 350% schneller zugreifbar ist.

Sicherlich mag die Suchfunktionalität eines Papierkalenders eingeschränkt sein. Doch wird man ja ungefähr das gewünschte Datum wissen...
Ein meiner Meinung nach sehr schöner Blogeintrag zum Thema 'Elektronik statt Papier:
http://apfelzlog.de/1384/fur-d…rr-der-digitalen-fliegen/

Ich persönlich habe keine Ahnung, wie sich komfortable Kalenderanwendungen erstellen lassen könnten.
Allerdings sehe ich nur meinen Anwendungsfall mit täglichen To-Do-Listen, die auch mal flink verschoben werden können sollen.
Da gibt es offenbar keine vernünftige Lösung für.
Klar, man könnte via Rechtsklick ein Kontextmenü aufrufen und sagen 'Erledigt - Verschoben - Abgebrochen'. Und wenn ich dann verschiebe - wohin?
Auf morgen? Super, wenn ich nicht aufpasse, ist meine To-Do-Liste unschaffbar voll geworden. Baue ich aber ein elektronisches Kontrollmuster ein, dann kann es sein, dass ich dem Muster widersprechen möchte und die Aufgabe nicht erst übermorgen erledigen kann. Dann muss ich also etwas Anderes vom morgigen Tag nach übermorgen verschieben. Mit Pech ist da ne Deadline, die unmöglich verschoben werden kann... Horror!

Oder als Anwendungsfluss:
heute 'Meditation' nicht geschafft. Kontextmenü->Verschieben auf morgen
Alert 'Mittwoch bereits voll. Umsortieren oder weiter verschieben?' -> weiter verschieben, so wichtig ist die Meditation doch nicht
Alert 'Donnerstag bereits voll. Umsortieren oder weiter verschieben?' -> umsortieren, 'Lunch mit Ex-Kollegen' zum Verschieben auswählen
Alert 'Freitag bereits voll. Umsortieren oder weiter verschieben?' -> umsortieren.
Mist, wichtige Deadline drin. Umsortieren abbrechen und statt dessen weiter verschieben.
Nein, das Lunch verschieben bringt auch nix, es sollte diese Woche noch sein. Ex-Kollege ist ja ab Samstag Abend für 3 Monate in Kanada. Noch einmal zurück.
'Vortragsvorbereitungen für den 20.02.' klingt nach etwas gut verschiebbarem. -> verschieben
Alert 'Freitag bereits voll. Umsortieren oder weiter verschieben?' -> weiß ich doch schon. Nervensäge. Weiter verschieben.
Alert 'Es folgt ein Wochenende. Auf Montag verschieben oder am Wochenende durchführen?' -> Vorbereitungen sind gut für's Wochenende. Durchführen.
'Vortragsvorbereitungen für den 20.02.' also auf Samstag, 16:00 bis 19:00 gesetzt. Passt.

Jeder Vorgang muss also erst einmal von mir erfasst werden und erfordert dann auch noch eine haptische Reaktion: den Touch an der korrekten Stelle.
Ich habe also bereits midestens 5x2 Sekunden für die Dialoge zum Verschieben zweier Aktivitäten gebraucht. Die Überlegungsarbeiten kann ich da natürlich nicht berechnen.

Auch einen Drag'n'Drop Ansatz halte ich für schwierig. Wenn ich aus Versehen los lasse? Wenn ich abbrechen will?
Das UI Design für derartige Anwendungen ist echt schwierig bis unmöglich.

Apple bekommt es in seiner Kalender App nicht auf die Reihe. Die Android Kalender Apps, die ich bisher gesehen habe, bekommen das nicht auf die Reihe.
Googles Kalender bekommt es nicht auf die Reihe. Microsofts Kalender in Windows Mobile 2003 bekam es schon nicht auf die Reihe.

Papierlösung:
heute 'Meditation' nicht geschafft. - hinter für 'Verschoben'.
umblättern.
Mittwoch schon alles dicht. Umblättern.
Donnerstag schon alles dicht. Egal, Meditation hin schreiben.
Kurz umblättern und den Freitag prüfen. Auch dicht und eine Deadline. Gut, Lunch lässt sich also nicht verschieben, da der Ex-Kollege Samstag Abend nach Kanada fliegt und erst in 3 Monaten zurück kommt.
Zurückblättern. - hinter 'Vortragsvorbereitungen für den 20.02.' zur Markierung als 'Verschoben'.
Direkt zum Samstag blättern und die verfügbare Zeit prüfen.
Für die Zeit von 16:00 bis 19:00 Uhr 'Vortragsvorbereitungen für den 20.02.' eintragen.
Das Ganze Hin- und Hergeblättere hat mich maximal 6 Sekunden gekostet. Die Überlegungsarbeiten kann ich da natürlich nicht berechnen.

Fazit: für mich gibt es keine besseren Kalender als die papiernen Dinger. Und mit elektronischen Kalendern scheint jeder unzufrieden.

Ich denke, ich verstehe.
Nein, für diese Art Tests ist JUnit nicht gedacht.

JUnit ist ein Framework zur Durchführung automatisierter Unit Tests. Das heißt grob zusammengefasst:
JUnit prüft, ob ein erstelltes Objekt seine versprochenen Methoden einhält und auch bei Fehleingaben stabil bleibt.

Du möchtest, wenn ich das richtig verstehe, eher Benchmarks deines Algorithmus durchführen.
Meines Wissens gibt es da nix Fertiges.

Aber wenn du was gefunden (oder selbst erstellt) hast, dann ist das Erstellen der Vorab-Activity eigentlich kein allzu großes Problem mehr.

Also ich persönlich als computeraffiner Nichtlehrer stehe ja total auf so Papierkalendergedöns.
Die sind einfach um Längen praktischer als die digitalen Dingse.

40h Vollzeit Softwareentwicklung Mobile und Desktop.

Ich nutze für sowas Array Lists, die sich schick sortieren lassen.
Vermutlich ist es bei dir sogar noch einfacher:

Collection.reverse(list);
setList(list);

Viel Erfolg fürs Studium und ne Menge Spaß mit Android!