Bedingtes Kompilieren

Bobert

Bobert

Fortgeschrittenes Mitglied
15
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 :love:, kein Workaround :thumbdn:.

Gruß Bobert
 
Bobert schrieb:
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:

Code:
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.
 
  • Danke
Reaktionen: 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,
Code:
<application android:release=["true" | "false"] ... >
bekommt dann Android "Schluckauf"?

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

Gruß Bobert
 
Zuletzt bearbeitet:
Ich halte es für sinnvoll solch eine Einstellung in der abgeleiteten Application zu halten.

Code:
public class MyApp extends Application {
  public static final String DEBUG = "MyApp";
  public static final boolean RELEASE = false;
}
 
  • Danke
Reaktionen: Bobert
Hallo,

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

MyActivity.java
Code:
public class MyActivity extends Activity {
...
    private void someMethode() {
        if (MyApp.RELEASE) Log.d(MyApp.TAG, "Foo");
    }
}
MyApp.java
Code:
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
 
Bobert schrieb:
Hallo,

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

MyActivity.java
Code:
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
Code:
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'.
 
maniac103 schrieb:
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!
 
Hallo,

Jep :thumbup:
Das sollte wohl ein if (!MyApp.RELEASE) sein
Log.wtf() ein Schelm wer böses dabei denkt. Heist aber wirklich "What a Terrible Failure" :biggrin:

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
 
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.
 
funcoder schrieb:
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.
 
Bobert schrieb:
Hallo,

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

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.
 
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
 
funcoder schrieb:
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...
 
Bobert schrieb:
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.
 
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 :thumbsup: viel geholfen.

Gruß Bobert
 
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.
 

Ähnliche Themen

D
Antworten
4
Aufrufe
765
DTSchneiderlein
D
F
Antworten
1
Aufrufe
1.933
xz1c
X
G
Antworten
1
Aufrufe
1.955
Gelöschtes Mitglied 410096
G
Zurück
Oben Unten