@@ -41,7 +41,7 @@ apps are discussed in this guide, alongside suggestions to help avoid them.
41
41
42
42
## Battery Ratings
43
43
44
- Any app published in the [ Developer Portal] ( https://dev-portal.getpebble.com )
44
+ Any app published in the [ Developer Portal] ({{ site.links.devportal }} )
45
45
will have a battery grade associated with it, once a minimum threshold of data
46
46
has been collected. This can be used to get a rough idea of how much battery
47
47
power the app consumes. For watchfaces and apps that will be launched for long
@@ -64,7 +64,7 @@ A common cause of such a drain are long-running animations that cause frequent
64
64
display updates. For example, a watchface that plays a half-second `` Animation ``
65
65
for every second that ticks by will drain the battery faster than one that does
66
66
so only once per minute. The latter approach will allow a lot more time for the
67
- watch to sleep.
67
+ watch to sleep.
68
68
69
69
``` c
70
70
static void tick_handler (struct tm * tick_time, TimeUnits changed) {
@@ -106,7 +106,7 @@ accel_tap_service_subscribe(tap_handler);
106
106
Many watchfaces unecessarily tick once a second by using the ``SECOND_UNIT``
107
107
constant value with the ``TickTimerService``, when they only update the display
108
108
once a minute. By using the ``MINUTE_UNIT`` instead, the amount of times the
109
- watch is woken up per minute is reduced.
109
+ watch is woken up per minute is reduced.
110
110
111
111
```c
112
112
// Only tick once a minute, much more time asleep
@@ -131,7 +131,7 @@ sensors will also prevent the watch from going to sleep and consume more battery
131
131
power. The `` AccelerometerService `` API features the ability to configure the
132
132
sampling rate and number of samples received per update, allowing batching of
133
133
data into less frequent updates. By receiving updates less frequently, the
134
- battery will last longer.
134
+ battery will last longer.
135
135
136
136
``` c
137
137
// Batch samples into sets of 10 per callback
@@ -160,11 +160,11 @@ instead present a list of previous inputs if appropriate to reduce usage of this
160
160
API.
161
161
162
162
``` c
163
- static void dictation_session_callback (DictationSession * session, DictationSessionStatus status,
163
+ static void dictation_session_callback (DictationSession * session, DictationSessionStatus status,
164
164
char * transcription, void * context) {
165
165
if(status == DictationSessionStatusSuccess) {
166
166
// Display the dictated text
167
- snprintf(s_last_text, sizeof(s_last_text), "Transcription:\n\n%s",
167
+ snprintf(s_last_text, sizeof(s_last_text), "Transcription:\n\n%s",
168
168
transcription);
169
169
text_layer_set_text(s_output_layer, s_last_text);
170
170
@@ -181,7 +181,7 @@ static void dictation_session_callback(DictationSession *session, DictationSessi
181
181
Hinted at above, frequent use of the ``AppMessage`` API to send and recieve data
182
182
will cause the Bluetooth connection to enter a more responsive state, which
183
183
consumes much more power. A small time after a message is sent, the connection
184
- will return back to a low-power state.
184
+ will return back to a low-power state.
185
185
186
186
The 'sniff interval' determines how often the API checks for new messages from
187
187
the phone, and should be let in the default ``SNIFF_INTERVAL_NORMAL`` state as
0 commit comments