Beiträge von Marco Feltmann

Klingt wirklich cool.
Schöner Spielkram. Ich wüsste grad nur nicht, wem ich damit Nachrichten schicken sollte. Aber ich probier's definitiv mal aus.

Definiere doch einfach mal 'näheren Umkreis'.

Also mit Frau und zwei Kindern hätte ich sehr wenig Freizeit für derartige Projekte.

Und Deadlines finde ich ziemlich sinnvoll, da sie verhindern, dass ein unbeliebter Teilpunkt endlos aufgeschoben wird.

Ja. Ich empfehle Dir bei dem zu bleiben, das Du relativ gut kannst und das dir Spaß macht.

So wirst du eher ermutigende Erfolge haben und die Motivation bekommen, dich tiefer auch in Unbekanntes einzuarbeiten.

Willkommen in der Community, Robin.

In dem Fall sollte sich ein Service in einem eigenen Thread um die Verbindung zum WLAN Modul kümmern.
Deine App(s) kommunizier(t/en) dann über Broadcast Messages mit dem Service und vice verda.

Klingt spannend.
Hast du als Datenformat für die Bilder auch BMP genutzt, oder unterstützt du auch andere Bildformate?

Hi Holger,

willkommen in der Community.

Leider ist der ROM-Bereich hier sehr dünn besiedelt und die letzten aktuellen Threads sind auch schon zwei Jahre alt.
Der Großteil hier schlägt sich eher mit der Erstellung von Spielen und Apps herum.

Die Idee ist spannend, ich weiß nur nicht, wie sich die Administration einer "Hobby Schmiede" gestalten soll.
Sprich Projektplanungen, Teammeetings, Meilensteine etc.pp.

Übernimmst Du Dich da vielleicht ein wenig oder hast Du da schon die passenden Konzepte bei der Hand?

Lohnen...
Also ich behaupte ja, dass man mit mobiler App-Entwicklung keinen Blumentopf gewinnen kann.
Da lohnt es sich eher, einen sinnvollen Beruf zu wählen.

Zynismus bei Seite.

Wenn Du mit der App Entwicklung reich durch viele verkaufte Apps werden möchtest, dann lass es einfach bleiben.
Vor Allem auf Android scheint mir die Bezahlmentalität (auch wegen des nicht ganz so guten Rufs Google Checkouts) eher bescheiden gering auszufallen.

Ansonsten mach einfach das, was Dir Spaß macht.
Du kannst Spiele auf dem PC mit Unity machen? Perfekt. Dann versuch doch mal eins auf Android zu portieren.
Die CommUnity +grins+ ist sehr groß und hilfsbereit. Und der Aufwand zum Umlernen hält sich auch arg in Grenzen.

Willst Du hingegen Apps erstellen, weil Du der Meinung bist, DIESE eine App fehlt noch: mach Dich auf einen langen Weg gefasst.
Visual Studio wird dir vermutlich nicht helfen, da es meines Wissens weder Java unterstützt noch eine Android Toolchain dafür existiert.
Du musst also auf Eclipse, NetBeans, IntelliJ oder Android Studio umsteigen. Und dann ganz viel neu lernen.

Sicherlich kannst Du echt geniale Gassenhauer entwickeln, die so richtig downloadstark sind. Nur ist downloadstark nicht gleich umsatzstark.
Am Besten hast Du es eigentlich, wenn Du Menschen findest, die Dich dafür bezahlen ihre Apps zu erstellen. Allerdings ist das alles dann nicht mehr Dein Projekt und macht Dir gegebenenfalls auch weniger Spaß.

(Und glaub mir: Apps ohne Freude am Projekt erkennt man 20m gegen den Wind)

Die meisten Unternehmen sehen Apps nur als Erweiterung ihres Online-Portfolios. Leider...
Und die sind meist mit einem guten Webdesigner, der Response Web Development versteht, wesentlich besser und umfassender bedient.
Also fühl Dich ruhig frei, Aufträge an Dir bekannte gute Webdesigner zu delegieren. So verstößt du keinen Kunden und bekommst im Gegenzug vielleicht mal eine App-Anfrage des Webdesigners zugeschustert.

Anderer Thread, obwohl das ne UI Sache ist?
Na meinetwegen, Hauptsache es klappt.

http://stackoverflow.com/quest…-activity#answer-15946106

Natürlich musst du in dem Fall einen Breakpoint setzen, am Besten bei der parentActivity.startChildActivity.
Wenn du an dem Punkt angelangt bist, dann wartet der Debugger auf dich und du kannst dich schrittweise durchhangeln.

Ich habe damit noch keine Erfahrungen gemacht, aber Das Internet™ spricht von vielerlei Problemen.
Da du einen StackOverflow Post zu dem Thema 1:1 übernommen hast ging ich davon aus, dass du die bekannten Quellen genutzt hast ohne zu einer Lösung zu kommen.

Insofern wird wohl erst einmal nur das Debugging hilfreich sein können.

Hast du irgendwelche Log-Ausgaben oder Crashes?
Falls nicht, dann wird dir wohl nur der Schritt über den Debugger bleiben.

0) Ganz sicher nicht. Eclipse ist Teufelswerk ohne irgendwelche Benefits...

1) Keine Preprozessor Direktiven ist ja schon mal ausgesprochener Mist. Code mittels Kommentaren zu gruppieren finde ich sehr sinnlos. Kommentare sollen erklären, WARUM man etwas tut, nicht WAS man tut. WAS man tut sollte der Code erklären. Dennoch könnte die IDE ruhig eingebaute Direktiven mitbringen, welche die Darstellung komfortabler gestalten. (#pragma mark ist eine ziemlich sinnlose Preprozessor-Direktive. Sie wird vom Preprozessor komplett ignoriert und nur von der IDE ausgewertet.)

2) jUnit ist ein Framework für Unit Testing. Wie ich damit die Integrationstests hinbekomme weiß ich aber immer noch nicht.

3) Also eigentlich interessiert es mich recht wenig, wie viel Code ich geschrieben habe. Ich finde es interessanter, ob meine Tests alle Codezeilen des jeweiligen Pakets abdecken. Dafür sehe ich allerdings keine Option in den Eclipse Metrics.

Zitat von killphil75

Seit dem es Volley von Google gibt kümmere ich mich gar nicht mehr um diesen Mist.

Und seit wann ist das?

Ich hatte mir auch vorgenommen, seitdem es Objective-C gibt mich nicht mehr um diesen Java/C#/C++ Mist kümmern zu müssen.
Erstens kommt es anders und Zweitens als man denkt.

Solange du nur ein Socket Objekt erstellst (oder ein Netzwerkobjekt im Allgemeinen) dürfte soweit ich weiß keine Exception gefeuert werden.
Erst wenn du die Verbindung startest, solltest du dich außerhalb des UI Threads befinden.

Zu deinem theoretischen Ansatz:
Neuen Task starten und da die Socketverbindung erstellen klingt gut.

Doch warum willst du die Buffererstellung in einem weiteren Task ausführen?
Da jeder Task wohl sequentiell abgearbeitet wird bringt dir das relativ wenig. Wenn du auf parallele Ausführung bestehst, bringt dir das ebenfalls wenig, da jeder Thread seinen eigenen Speicherbereich zugeteilt bekommt. Hin und her referenzieren wird da also schwierig.

Wofür du jetzt die Referenz auf die Buffer brauchst erschließt sich mir nicht. Doch mit meinem Beispiel hast du sie ja.
(Natürlich sind die irgendwann fertig und könnten geschlossen werden. Ein read auf einen solchen Buffer zu werfen würde dann schwierig und vermutlich in einer Exception enden.)

Aber so ganz konkret habe ich keine Idee was genau du eigentlich bezweckst.
Eventuell wäre es hilfreich, du würdest dein Vorhaben konkreter beschreiben anstatt deines Lösungsansatzes.
Dann kann man dir nämlich nicht nur sagen, ob dein Lösungsansatz der richtige ist, man könnte dir auch sagen, wie du ihn optimiert bekommst.

Wenn du das verständlicherweise nicht in öffentlichen Foren machen möchtest, dann geht das sicher auch per PN.

Bei mir ist es im Allgemeinen so, dass ich mich um Timeouts, fehlerhafte Statuscodes etc.pp. nicht sonderlich kümmere.
Ich meine, der Task ist asynchron, wen kümmert da ein Timeout? Entweder ich bekomme Daten, oder ich bekomme keine Daten.
Warum ich keine Daten bekomme, ist mir relativ Lachs.

Im Großen und Ganzen gefällt mir der Code.

Das Problem mit den 'mehreren Async Tasks' bin ich umgangen, indem ich keine mehreren Async Tasks mehr habe.
In meinen Fällen musste ich feststellen, dass alle anderen Async Tasks vom Erfolg eines bestimmten Async Task abhingen.

Da offenbar ein 'first come, first serve' bei den AsyncTasks gilt, wird eben dieser zwingend notwendige Task zuerst gestartet und erst nach dessen Ende die abhängigen Tasks. Ich priorisiere die Tasks also quasi manuell, da sie im Allgemeinen eh seriell abgearbeitet werden.
(Vgl. http://developer.android.com/r…android/os/AsyncTask.html Abschnitt "Order of Execution")
Allerdings habe ich auch keine Tasks, deren Berechnungen langwierig sind und unbedingt bevorzugt behandelt werden müssen.
Die Berechnungen werden ebenfalls in ihren jeweiligen Threads einfach sequentiell abgearbeitet.

Also zunächst einmal ist das Java, kein Assembler. Man darf, kann und soll seine Variablen sinnvoll ausschreiben.

Weiterhin finde ich es nicht wartbar, wenn irgendwelche Klassen auf irgendwelche Member irgendwelcher anderen Klassen zugreifen.

Die Main würde ich dann so gestalten:

//Blah blah blah... OMG! It's a nipple.
Socket clientSocket = new Socket("192.168.1.1", 2002);
BufferedReader inputBufferedReader = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
BufferedReader outputBufferedReader = new BufferedWriter(new OutputStreamWriter(clientSocket.getOutputStream()));
OwnAsyncTask theBackgroundTask = new OwnAsyncTask();
// Jetzt kannst du je nach Implementierung deines Tasks noch weitere Dinge angeben!
theBackgroundTask.setSocket(clientSocket);
theBackgroundTask.setInputReader(inputBufferedReader);
theBackgroundTask.setOutputReader(outputBufferedReader);
// Hier wird der Task erst gestartet.
theBackgroundTask.execute();


// Und hier können die Sockets und Reader und wat weiß ich noch weiter bearbeitet werden. Aber ob das eine gute Idee ist...
inputReader.flush();
outputReader.flush();
clientSocket.close();

Und den Task selbst einfach ein wenig erweitern.

class MyOwnTask extends AsyncTask
{
  private Socket connectionSocket;
  private BufferedReader inputReader;
  private BufferedReader outputReader;


  public void setSocket(Socket theSocket)<Void, Void, Void>
  {
    // Ich will den Socket nur ersetzen, allerdings nicht mit einem NULL Objekt.    
    if(theSocket != null && theSocket != connectionSocket)
    {
        connectionSocket = theSocket;
    }
  }


  public void setInputReader(BufferedReader reader)
  {
    if(reader != null && inputReader != reader)
    {
      inputReader = reader;
    }
  }


  public void setOutputReader(BufferedReader reader)
  {
    if(reader != null && outputReader != reader)
    {
      outputReader = reader;
    }
  }


  private Socket getConnectionSocket()
  {
    // Der Socket ist existenziell.
    if(connectionSocket = null) throw new IllegalArgumentException();
    return connectionSocket;
  }


  private BufferedReader getInputReader()
  {
    if(inputReader == null)
    {
      inputReader = new BufferedReader(new InputStreamReader(getConnectionSocket().getInputStream())); 
    }
    return inputReader;
  }


  private BufferedReader getOutputReader()
  {
    if(outputReader == null)
    {
      outputReader = new BufferedReader(new OutputStreamReader(getConnectionSocket().getOutputStream());
    }
    return outputReader;
  }


  /* Und zum Ende das Bekannte */


  public Void doInBackground(Void... param)
  {
    // Hier kann ganz entspannt auf getConnectionSocket(), getInputReader() und getOutputReader() zugegriffen werden.
  }  


  public Void onPostExecute()
  {
    // Hier ist es auf jeden Fall sicher, sämtlichen Netzwerkverkehr zu unterbinden und freizugeben.
    getInputReader().flush;
    getOutputReader().flush;
    getConnectionSocket().close();
  }
}

Zitat von snipor

Wird das vom Garbage Collector dann einfach aufgeräumt, oder kann ich das noch nutzen?

Diese Frage ist etwas schwierig zu beantworten.
Die Kurzfassung ist: du sollst dich selbst darum kümmern, deine Dinge (geöffnete Streams, Sockets, Connections, Files etc.pp.) selbst wieder frei zu geben.
Im Falle des Async Task hast du den Vorteil, dass nach dessen Beendigung sämtliche Instanzvariablen ihr Signal zur Freigabe erhalten. Der Garbage Collector räumt dann also alles auf. Leider kann es einige Dinge geben, die beim Aufräumen nicht durchgeführt werden. Das Schließen von Streams einer Socketverbindung zum Beispiel. Hängt also ganz von der Implementierung des Objektes ab.

Zurück zum Thema: solltest du die Verbindung oder Instanz ausschließlich in diesem AsyncTask deklariert und zugewiesen haben, dann kommst du nach Beendigung des Tasks nicht mehr ran. Dir fehlt einfach die Referenz zu dem Objekt. Hast du deinem AsyncTask hingegen das Objekt als Referenz mitgegeben, ist es nach Beendigung des Tasks für dich noch immer verfügbar.

Moin nach Berlin!

Zitat von Kogoro

Bis auf das es keine Pointer gibt

Eher, dass ausnahmslos alles ein Pointer ist.
Gewaltiger Unterschied.