Bedingtes Kompilieren

[Bobert]

Hallo,

in der Release Version sollten alle Log.[irgenwas] gelöscht werden Punkt 5.4

Ich kenne es so (von C, C++ und C#) das man "#ifdef release " benutzt. Dieses "Bedingtes Kompilieren" gibt es in Java nicht! Oder?

Wie macht Ihr das in euren Projekten wenn Ihr eine Release Version fertig macht, löscht Ihr per Hand alle LOG. oder etwa so wie hier beschrieben. Oder kennt Ihr eine weite Möglichkeit, wie man das machen SOLLTE.

Best Practices , kein Workaround .

Gruß Bobert

 

[maniac103]

Hallo,

in der Release Version sollten alle Log.[irgenwas] gelöscht werden Punkt 5.4

Ich kenne es so (von C, C++ und C#) das man "#ifdef release " benutzt. Dieses "Bedingtes Kompilieren" gibt es in Java nicht! Oder?

Richtig, da kein Präprozessor vorhanden ist.

Wie macht Ihr das in euren Projekten wenn Ihr eine Release Version fertig macht, löscht Ihr per Hand alle LOG. oder etwa so wie hier beschrieben. Oder kennt Ihr eine weite Möglichkeit, wie man das machen SOLLTE.

Ich mache das immer so:

public class MyActivity extends Activity {
    private static final boolean D = true; // bei Release auf false setzen
    private static final String TAG = "MyApp";

    private void someMethod() {
        if (D) Log.d(TAG, "Foo");
    }
}

In den AOSP-Sourcen wird's ähnlich gemacht.
Ich würde übrigens nicht alle Log-Aufrufe rausmachen / abschalten, sondern nur Log.d und Log.v.

 

[Bobert]

Hallo,

private static final boolean D = true; // bei Release auf false setzen

kann man das nicht an Zentraler stelle ablegen, sonst müsste ich ja jede Klasse / Activity diesen Eintrag ändern wen ich die Release Version erstelle!?

Ich dachte mir das dieser Eintrag ja in die AndroidManifest.xml gehört, dort sind alle Meta Daten der App. Hier habe ich aber nichts auf die schnelle gefunden ob man das "darf". Spontan würde ich follgendes schreiben,

<application android:release=["true" | "false"] ... >

bekommt dann Android "Schluckauf"?

Oder Oder Google brachte mir auch kein brauchbares Ergebnis. Jemand eine Gute Idee?

Gruß Bobert

 

[BenOtto]

Ich halte es für sinnvoll solch eine Einstellung in der abgeleiteten Application zu halten.

public class MyApp extends Application {
  public static final String DEBUG = "MyApp";
  public static final boolean RELEASE = false;
}

 

[Bobert]

Hallo,

danke euch damit kann ich gut leben. Zusammengefasst müsste es also so aussehen.

MyActivity.java

public class MyActivity extends Activity {
...
    private void someMethode() {
        if (MyApp.RELEASE) Log.d(MyApp.TAG, "Foo");
    }
}

MyApp.java

import android.app.Application;

public class MyApp extends Application{
    public static final String TAG = "MyApp";
    public static final boolean RELEASE = false;    
}

Wo ich nochmals nachfragen muss, in Punkt 5.4 wird gesagt

Deactivate any calls to Log methods in the source code.

Das meint alle, warum würdest Du @maniac103

... rausmachen / abschalten, sondern nur Log.d und Log.v.

Gruß Bobert

 

[maniac103]

Hallo,

danke euch damit kann ich gut leben. Zusammengefasst müsste es also so aussehen.

MyActivity.java

public class MyActivity extends Activity {
...
    private void someMethode() {
        if (MyApp.RELEASE) Log.d(MyApp.TAG, "Foo");
    }
}

Das sollte wohl ein if (!MyApp.RELEASE) sein

MyApp.java

import android.app.Application;

public class MyApp extends Application{
    public static final String TAG = "MyApp";
    public static final boolean RELEASE = false;    
}

Wo ich nochmals nachfragen muss, in Punkt 5.4 wird gesagt
Das meint alle, warum würdest Du @maniac103

... rausmachen / abschalten, sondern nur Log.d und Log.v.

Naja, Log.i, Log.w, Log.e und Log.wtf (LOL) nimmt man doch nur für wichtige Informationen (Exception-Logging etc.), die hilfreich sein können, wenn mal jemand ein Problem mit deiner App hat. Deswegen würde ich die drin lassen.

Ich würde auch nur Log.v rauscompilieren und Log.d von einer Preference-gesteuerten Variable abhängig machen. Wenn es ein Problem gibt, schaltet der Benutzer deiner App das Flag an und du hast ausführliche Debug-Informationen. Das wird z.B. in K9-Mail so gemacht. Default dabei ist natürlich 'Debug-Logging aus'.

 

[BenOtto]

Ich würde auch nur Log.v rauscompilieren und Log.d von einer Preference-gesteuerten Variable abhängig machen. Wenn es ein Problem gibt, schaltet der Benutzer deiner App das Flag an und du hast ausführliche Debug-Informationen. Das wird z.B. in K9-Mail so gemacht. Default dabei ist natürlich 'Debug-Logging aus'.

Auch eine gute Alternative!

 

[Bobert]

Hallo,

Jep

Das sollte wohl ein if (!MyApp.RELEASE) sein

Log.wtf() ein Schelm wer böses dabei denkt. Heist aber wirklich "What a Terrible Failure"

Hier wird gesagt "Verbose should never be compiled into an application except during development." hört sich für mich, implizit an das die anderen Meldungen drin bleiben sollen. Wenn ich die Log...() Meldungen in der Entwicklung beim benutzen des Emulator habe, bekomme ich diese Log...() in LogCat angezeigt, wo aber gehen die hin wenn ich die App ausliefere habe, wo kann ich die Meldungen auf dem Gerät finden?

Gruß Bobert

 

[funcoder]

Also ich habe einfach eine extra Methode erstellt:

private void Log(String text){
if(showLog)
Log.d("123","456");
}

Und dann natürlich immer diese Log Methode aufrufen. Lässt sich sicherlich mit den verschiedenen Log Typen tunen.

Vorteil ist, dass der Code nicht unschön wird mit tausenden Abfragen ob die Debug Ausgaben angezeigt werden sollen oder nicht.

 

[BenOtto]

Also ich habe einfach eine extra Methode erstellt:

private void Log(String text){
if(showLog)
Log.d("123","456");
}

Und dann natürlich immer diese Log Methode aufrufen. Lässt sich sicherlich mit den verschiedenen Log Typen tunen.

Vorteil ist, dass der Code nicht unschön wird mit tausenden Abfragen ob die Debug Ausgaben angezeigt werden sollen oder nicht.

Ja, sowas ist auch denkbar. Am besten auch als statische Methode innerhalb der Application-Klasse.

 

[BenOtto]

Hallo,

Jep Log.wtf() ein Schelm wer böses dabei denkt. Heist aber wirklich "What a Terrible Failure"

Hier wird gesagt "Verbose should never be compiled into an application except during development." hört sich für mich, implizit an das die anderen Meldungen drin bleiben sollen. Wenn ich die Log...() Meldungen in der Entwicklung beim benutzen des Emulator habe, bekomme ich diese Log...() in LogCat angezeigt, wo aber gehen die hin wenn ich die App ausliefere habe, wo kann ich die Meldungen auf dem Gerät finden?

Gruß Bobert

Die landen in einem Log-File. Dieses lässt sich dann auch von jedem auslesen. Wenn du also einen Fehler loggst, dann bringt dich das weiter, weil du über den Crash-Report eines Benutzers herausfinden kannst was genau los war.

 

[Bobert]

Die landen in einem Log-File. Dieses lässt sich dann auch von jedem auslesen. Wenn du also einen Fehler loggst, dann bringt dich das weiter, weil du über den Crash-Report eines Benutzers herausfinden kannst was genau los war.

Ok, ist ja Linux aber ich finde kein /var/log Verzeichnis, auch finde ich die Log.Files nicht, im App Verzeichnis?

Gruß Bobert

 

[maniac103]

Also ich habe einfach eine extra Methode erstellt:

private void Log(String text){
if(showLog)
Log.d("123","456");
}

Und dann natürlich immer diese Log Methode aufrufen. Lässt sich sicherlich mit den verschiedenen Log Typen tunen.

Vorteil ist, dass der Code nicht unschön wird mit tausenden Abfragen ob die Debug Ausgaben angezeigt werden sollen oder nicht.

Dafür hast du dann aber auch Overhead durch einen zusätzlichen Funktionsaufruf pro Logzeile...den wirft (AFAIK) der Android-Compiler leider nicht raus...

 

[maniac103]

Ok, ist ja Linux aber ich finde kein /var/log Verzeichnis, auch finde ich die Log.Files nicht, im App Verzeichnis?

Gruß Bobert

USB-Kabel anschließen und 'adb logcat' aufrufen
Oder halt aLogcat aus dem Market installieren.

 

[Bobert]

USB-Kabel anschließen und 'adb logcat' aufrufen
Oder halt aLogcat aus dem Market installieren.

Ja danke Dir, hatte die Hoffnung das es einfacher geht. Sicherlich keine Möglichkeit für eine Ausgelieferte App, aber Gut zu wissen. Auf jeden Fall hat mir dieser Thread und Ihr viel geholfen.

Gruß Bobert

 

[DieGoldeneMitte]

Ich bin gegen die Logfunktion.

Das mit der Funktion Log mag zwar etwas einfacher lesbar sein, hat aber den Nachteil, dass das Argument IMMER ausgewertet wird.