Update some API description

Change-Id: Icdfda275de7ec1c63a62c73f177ec21ee0a0c276
Signed-off-by: Boram Bae <boram21.bae@samsung.com>

diff --git a/include/sensor.h b/include/sensor.h
index 5b152af..9152827 100644 (file)
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -988,7 +988,7 @@ int sensor_listener_unset_accuracy_cb(sensor_listener_h listener);
  *          To be able to read the current values or the last known values, the sensor needs to be
  *          enabled in advance. As an application cannot be sure that the sensor is already enabled
  *          by other applications, it is recommended to start the sensor explicitly by using sensor_listener_start().@n
- *          But note that, even if the sensor is started, on-demand reading can fail always,
+ *          But note that even if the sensor is started, on-demand reading can fail anyway,
  *          thus it would be better to use the asynchronous callback approach.
  *
  * @param[in]   listener    A listener handle
@@ -1009,12 +1009,12 @@ int sensor_listener_read_data(sensor_listener_h listener, sensor_event_s *event)
  * @since_tizen 5.5
  *
  * @remarks  As a sensor usually works in an event-driven manner, it may not be able to read its data on demand.
- *          Then this function tries to return the last known values.@n
+ *          In such cases this function tries to return the last known values.@n
  *          When there are last known values that are caused by multi-event publishing, the @a count is greater than or equal to 1.@n
  *          To be able to read the current values or the last known values, the sensor needs to be enabled in advance.
  *          As an application cannot be sure that the sensor is already enabled by other applications,
  *          it is recommended to start the sensor explicitly by using sensor_listener_start().@n
- *          But note that, even if the sensor is started, on-demand reading can fail always,
+ *          But note that even if the sensor is started, on-demand reading can fail anyway,
  *          thus it would be better to use the asynchronous callback approach.
  *          The @a events must be released using free(), if not being used anymore.@n
  *
@@ -1065,7 +1065,7 @@ int sensor_listener_set_interval(sensor_listener_h listener, unsigned int interv
  * @details Sensors that support batching may allow applications to change their maximum batch latencies.
  *          For example, if you set the latency as 10,000 ms, the sensor may store its data
  *          up to 10,000 ms, before delivering the data through the HAL.@n
- *          In cases of non-batching sensors, this function returns #SENSOR_ERROR_NONE,
+ *          In case of non-batching sensors, this function returns #SENSOR_ERROR_NONE,
  *          but nothing is affected by the input latency value.
  * @since_tizen @if MOBILE 2.3 @elseif WEARABLE 2.3.1 @endif
  *
@@ -1122,8 +1122,8 @@ int sensor_listener_set_option(sensor_listener_h listener, sensor_option_e optio
 /**
  * @brief   Flushes stored data of a sensor.
  * @details  Flushes all data of a sensor as if the max batch latency has expired.
- *          Data are delivered in the usual way through the event callback function. @n
- *          In cases of non-batching sensors, this function returns #SENSOR_ERROR_NONE
+ *          Data is delivered in the usual way through the event callback function. @n
+ *          In case of non-batching sensors, this function does nothing and returns #SENSOR_ERROR_NONE.
  * @since_tizen 5.5
  *
  * @param[in]   listener        A listener handle