Skip to content
This repository has been archived by the owner on Sep 2, 2024. It is now read-only.

Logging

Jump to bottom
sundaram75 edited this page Dec 9, 2015 · 1 revision

Design

The following log files are used in this project. Developers should use them for understanding the code flow & debugging in environments where a debugger is not available. Also developers should stick to the convention while writing to the log files so as to ensure readability & understanding for other developers.

1.Performance.log 2.Programflow.log 3.Warnings.log 4.Trace.log 5.Usage.log

1. Performance.log This will be used to record the execution times of frequently called functions / functions with high time complexity.The logs will be used for performance tuning/ performance improvement. Memory usage can also be logged to gather information about possible memory leaks.

Programflow.log

This will be used to record the program flow . Will be very useful in the absence of a debugger.

Warnings.log This will used to record warnings about certain inputs being provided to functions that are not in line with the use cases which the current code covers.These are conditions which may not cause the program to fail/ crash but may give incorrect output leading to less than satisfactory user experience. Primarily to be used for defensive programming.Strongly suggested for core algorithms/functions that will be used by other developers to implement new features / extend functionality of the product.

Trace.log

This will be used to store image data about the last 3-4 frames being processed.It will be rolling log i.e old data will be erased when log file reaches a certain size. Exceptions which are likely to caused the application to stop working should also be logged here.

Usage.log

This will be used to log data about usage patterns of the user. Basically usage data that will help to predict implicit user expectations. This data will be used to come up with new features & improvements in the app. Data that can be logged are.

  1. Time of day .
  2. Lighting conditions which may affect image quality.
  3. Data about steadiness of hand (gathered from accelerometer ) to determine causes of blurring/ lack of image quality.
  4. User starting a certain process but abandoning it . Eg scanning but not saving the image.
  5. Starting the app but closing without scanning anything. This list will grow as more features for the app are implemented.

Implementation

Openscan uses Log4cpp to implement the above logger design. Logging can be turned ON/OFF by changing the log4cpp.properties file and the changes take effect without compile. Logging for each file can be set at the desired level by changing the threshold value in the properties file. For more details on how this can be achieved refer to the log4cpp or log4j website. To log to any of the above log files developers are suggested to follow any of the 3 below mentioned methods

Method 1 - Use the log4cpp::Category object. This method is to be used when within a call block many log statements are written to the same log file This will reduce the overhead of calling getInstance for each log statment. Example code is provided below

log4cpp::Category& prog_flow = log4cpp::Category::getInstance(std::string("prog_flow"));
prog_flow.debug("Writing debug to progflow log ");
prog_flow.info("Writing info to progflow log ");
prog_flow.warn("Writing warning to progflow log");

The possible string values while getting the object are "prog_flow" - To write to Program Flow Log. "trace" - To write to the trace.log file "warn" - To write to the warnings.log file "perf" - To write to the performance log file "usage" - To write to the usage log file.

Method 2- Directly reference the catetory object The overhead of assignment operator in method1 can be avoided by direcly referencing the log4cpp:Category object as shown in the below code

log4cpp::Category::getInstance(std::string("prog_flow")).debug("Direct Access Method");

Method 3 - Use the preprocessor directive defined in defines.chh file The method is suggested for better code readability. The preprocessor directives defined are LOG_PERF,LOG_PROG_FLOW,LOG_TRACE,LOG_WARNING,LOG_USAGE Sample code for the same is provided below.

    LOG_PROG_FLOW.debug("Preprocessor Directive");

Developer Guidelines (To be detailed )

While logging to this log the developers should follow the below guidelines .

Performance / Memory cost considerations This cost of logging to the log is . The memory usage for typical user groups of the app should be measured and filled at a later date.

Release Guidelines- Eg: It is suggested that this logging be (TBD - turned on / turned off ) before shipping to end user.

Clone this wiki locally