Even if your application is fast and responsive, certain design decisions can still cause problems for users because of unplanned interactions with other applications or dialogs, inadvertent loss of data, unintended blocking, and so on. To avoid these problems, it helps to understand the context in which your applications run and the system interactions that can affect your application. In short, you should strive to develop an application that interacts seamlessly with the system and with other applications.
여러분의 애플리케이션이 빠르고 응답이 좋다 할지라도, 어떤 디자인 결정들은 여전히 사용자에게 문제를 야기시킬 수 있다 - 다른 애플리케이션 또는 다이얼로그와 계획되지 않은 상호작용, 데이터의 부주의한 손실, 의도되지 않은 멈춤 등 때문에 그럴 수 있다. 이러한 문제점을 피하기 위해, 여러분의 애플리케이션이 실행되는 컨텍스트와 여러분의 애플리케이션에 영향을 줄 수 있는 시스템 상호작용들을 이해하는 것은 도움이 된다. 간략하게 말하자면, 여러분은 시스템 그리고 다른 애플리케이션과 끊김없이 상호작용하는 애플리케이션을 개발하기 위해 노력해야 한다.
A common seamlessness problem is when an application's background process for example, a service or broadcast receiver pops up a dialog in response to some event. This may seem like harmless behavior, especially when you are building and testing your application in isolation, on the emulator. However, when your application is run on an actual device, your application may not have user focus at the time your background process displays the dialog. So it could end up that your application would display it's dialog behind the active application, or it could take focus from the current application and display the dialog in front of whatever the user was doing (such as dialing a phone call, for example). That behavior would not work for your application or for the user.
일반적인 무결절성 문제는 하나의 애플리케이션의 백그라운드 프로세스 - 예를 들어 서비스 또는 브로드캐스트 리시버 ? 가 어떤 이벤트에 응답하여 다이얼로그를 팝업할 때이다. 이러한 현상은 특히 여러분이 애플리케이션을 에뮬레이터 상에서 독립적으로 빌드하고 테스트할 때에는 해가 없는 것처럼 보일 수도 있다. 하지만 여러분의 애플리케이션이 실제 디바이스 상에서 실행될 때, 여러분의 애플리케이션이 백그라운드 프로세스로 다이얼로그를 보여줄 때 사용자 포커스를 가지지고 있지 않을 수도 있다. 그러므로 여러분의 애플리케이션은 결국에는 액티브(역주 : 현재 포커스를 가지고 있는) 애플리케이션 뒤에서 다이얼로그를 보여줄 것이다. 또한 그것은 현재의(역주 : 포커를 가지고 있는) 애플리케이션으로부터 포커스를 가져올 것이며 (예를 들어 전화를 거는 것과 같은) 사용자가 무엇을 하고 있던지 상관없이 그것 앞에 다이얼로그를 보여줄 수 있다. 이러한 동작방식은 여러분의 애플리케이션 또는 사용자를 위한 일이 아니다.
To avoid these problems, your application should use the proper system
facility for notifying the user the
Notification classes. Using
notifications, your application can signal the user that an event has
taken place, by displaying an icon in the status bar rather than taking
focus and interrupting the user.
이러한 문제점을 피하기 위해, 여러분의 애플리케이션은 사용자에게 노티피케이션을 주기 위한 적절한 시스템 설비 ? 노티피케이션Notification 클래스를 사용해야 한다. 노티피케이션을 사용할 때, 여러분의 애플리케이션은 포커스를 가져가서 사용자를 방해하기 보다는 상태바status bar에 아이콘을 보여줌으로써 사용자에게 이벤트가 발생했음을 알려줄 수 있다.
Another example of a seamlessness problem is when an activity inadvertently loses state or user data because it doesn't correctly implement the onPause() and other lifecycle methods. Or, if your application exposes data intended to be used by other applications, you should expose it via a ContentProvider, rather than (for example) doing so through a world-readable raw file or database.
무결절성 문제의 또 다른 예제는 하나의 액티비티가 onPause()와 다른 생명주기 메쏘드들을 정확하게 구현하지 않아서 상태나 사용자 데이터를 부주의하게 상실하게 될 때이다. 또는 만약 여러분의 애플리케이션이 다른 애플리케이션에 의해 사용되어지도록 데이터를 보여준다면, 여러분은 그 데이터를 world-readable 원시 파일이나 데이터 베이스를 통해서 하기 보다는 컨텐트 프로바이더를 통해 보여주어야 한다.
What those examples have in common is that they involve cooperating nicely with the system and other applications. The Android system is designed to treat applications as a sort of federation of loosely-coupled components, rather than chunks of black-box code. This allows you as the developer to view the entire system as just an even-larger federation of these components. This benefits you by allowing you to integrate cleanly and seamlessly with other applications, and so you should design your own code to return the favor.
이러한 예제들이 공통적으로 가지고 있는 것은, 그 예제들이 시스템과 다른 애플리케이션들과 아주 잘 협력하고 있다는 것이다. 안드로이드 시스템은 애플리케이션을 블랙박스 코드 덩어리가 아닌, 일종의 느슨하게 결합된 컴포넌트의 연합체로 취급하도록 디자인되어 있다. 이것은 여러분이 개발자로서 전체 시스템을 이러한 컴포넌트의 훨씬 더 큰 연합체로 볼 수 있게 한다. 이것은 여러분으로 하여금 다른 애플리케이션을 깨끗하고cleanly 끊김없이seamlessly 통합할 수 있게 함으로써 여러분에게 이점을 준다. 그러므로 여러분은 자신의 코드가 그 혜택을 돌려주도록 디자인해야 한다.
This document discusses common seamlessness problems and how to avoid them. It covers these topics:
이 문서는 일반적인 무결정성 문제들과 그것들을 회피하는 방법을 논의한다. 이것은 다음의 토픽들을 다룬다.
Always keep in mind that Android is a mobile platform. It may seem obvious to say it, but it's important to remember that another Activity (such as the "Incoming Phone Call" app) can pop up over your own Activity at any moment. This will fire the onSaveInstanceState() and onPause() methods, and will likely result in your application being killed.
안드로이드가 모바일 플랫폼이라는 사실을 항상 유의하라. 이것은 당연해 보일 수도 있지만, (“전화가 오는 것”과 같은) 다른 액티비티가 어떤 순간에 여러분 자신의 액티비티 위에 팝업될 수 있다는 점을 기억하는 것은 중요하다. 이것은 onSaveInstanceState()와 onPause() 메쏘드를 호출할 것이고, 여러분의 애플리케이션이 종료되도록 할 것이다.
If the user was editing data in your application when the other Activity appeared, your application will likely lose that data when your application is killed. Unless, of course, you save the work in progress first. The "Android Way" is to do just that: Android applications that accept or edit input should override the onSaveInstanceState() method and save their state in some appropriate fashion. When the user revisits the application, she should be able to retrieve her data.
만약 다른 액티비티가 나타날 때 사용자가 여러분의 애플리케이션 데이터를 편집하는 중이었다면, 여러분의 애플리케이션은 종료될 때 진행 중인 작업을 먼저 저장하지 않는다면 데이터를 상실하게 될 것이다. 안드로이드 방식Android Way은 진행중인 작업을 저장하는 것이다: 입력을 받거나 편집하는 안드로이드 애플리케이션은 onSaveInstanceState() 메쏘드를 오버라이드해야 하고 어떤 적절한 방식으로 그 애플리케이션의 상태를 저장해야 한다. 그 사용자가 그 애플리케이션을 다시 방문할 때, 그 데이터를 다시 가져오는 것이 가능해야 한다.
A classic example of a good use of this behavior is a mail application. If the user was composing an email when another Activity started up, the application should save the in-process email as a draft.
이런 행동을 잘 사용한 전통적인 예제가 메일 애플리케이션이다. 만약 사용자가 다른 액티비티가 시작되었을 때 이메일을 작성하고 있는 중이었다면, 애플리케이션은 작성 중인 이메일을 초고draft로 저장해야 한다.
If you wouldn't walk down the street in your underwear, neither should your data. While it's possible to expose certain kinds of application to the world to read, this is usually not the best idea. Exposing raw data requires other applications to understand your data format; if you change that format, you'll break any other applications that aren't similarly updated.
여러분이 속옷 차림으로 거리를 걷지 않는 것과 마찬가지로 여러분의 데이터도 그러지 않아야 한다. 특정 종류의 애플리케이션을 외부에 드러내어 그 애플리케이션의 데이터를 읽도록 하는 것은 가능하지만, 이것은 보통 최선의 안은 아니다. 원시 데이터를 드러내는 것은 다른 애플리케이션들이 여러분의 데이터 포맷을 이해하도록 요구한다. 만약 여러분이 그 포맷을 변경한다면, 비슷하게 업데이트되지 않은 다른 애플리케이션들을 망가뜨릴 것이다.
The "Android Way" is to create a ContentProvider to expose your data to other applications via a clean, well-thought-out, and maintainable API. Using a ContentProvider is much like inserting a Java language interface to split up and componentize two tightly-coupled pieces of code. This means you'll be able to modify the internal format of your data without changing the interface exposed by the ContentProvider, and this without affecting other applications.
“안드로이드 방식Android Way”은 여러분의 데이터를 다른 애플리케이션들에 깨끗하고, 잘 정리되어 있고, 그리고 유지보수 가능한 API를 드러내기 위해 컨텐트 프로바이더를 생성하는 것이다. 컨텐트 프로바이더를 사용하는 것은 두 개의 긴밀히 연결된 코드를 나누어 컴포넌트화기 위한 Java 언어 인터페이스를 삽입하는 것과 매우 비슷하다. 이것은 컨텐트 프로바이더에 의해 드러난 인터페이스를 변경하지 않고, 그리고 다른 애플리케이션에 영향을 주지 않으면서도 데이터의 내부 포맷을 수정할 수 있다는 것을 의미한다.
If the user is running an application (such as the Phone application during a call) it's a pretty safe bet he did it on purpose. That's why you should avoid spawning activities except in direct response to user input from the current Activity.
만약 사용자가 (통화하는 동안 폰 애플리케이션과 같은) 애플리케이션을 실행하고 있다면, 그가 목적을 가지고 그것을 했다는 것은 확실한 것이다. 이것은 여러분이 현재의 액티비티로부터 사용자의 입력에 직접 응답한 것을 제외하고 액티비티들을 만드는 것을 피해야 하는 이유이다.
That is, don't call startActivity() from BroadcastReceivers or Services running in the background. Doing so will interrupt whatever application is currently running, and result in an annoyed user. Perhaps even worse, your Activity may become a "keystroke bandit" and receive some of the input the user was in the middle of providing to the previous Activity. Depending on what your application does, this could be bad news.
즉, 백그라운드에서 실행되는 브로드캐스트 리시버나 서비스에서 startActivity()를 호출하지 말아라. 그렇게 하는 것은 애플리케이션이 현재 실행하고 있는 것이 무엇이든지 간에 방해를 할 것이며, 그래서 사용자에게 불편을 초래할 것이다. 더 나쁜 상황은, 여러분의 액티비티가 “키입력 도적keystoke bandit” 이 될 수도 있고, 사용자가 이전의 액티비티에 제공하고 있었던 입력을 수신할 수도 있다. 여러분의 애플리케이션이 무엇을 하는 지에 따라서, 이것은 좋지 않은 소식이 될 수도 있다.
Instead of spawning Activity UIs directly from the background, you should instead use the NotificationManager to set Notifications. These will appear in the status bar, and the user can then click on them at his leisure, to see what your application has to show him.
백그라운드로부터 직접적으로 액티비티 UI를 생성하는 것 대신, 여러분은 노티피케이션을 설정하기 위한 노티피케이션 매니저를 대신 사용해야 한다. 이것들은 상태 바에서 나타날 것이고, 그래서 사용자는 여러분의 애플리케이션이 그에게 보여주어야 하는 것을 보기 위해 틈이 날 때 그것을 클릭할 수 있다.
(Note that all this doesn't apply to cases where your own Activity is already in the foreground: in that case, the user expects to see your next Activity in response to input.)
(위에서 언급한 모든 것은 여러분의 액티비티가 이미 포어그라운드에 있는 모든 경우에는 적용되지는 않는다는 것에주의하라: 그 경우에, 사용자는 입력에 반응하여 여러분의 다음 액티비티를 보길 기대한다.)
If your application needs to perform some expensive or long-running computation, you should probably move it to a thread. This will prevent the dreaded "Application Not Responding" dialog from being displayed to the user, with the ultimate result being the fiery demise of your application.
만약 여러분의 애플리케이션이 다소 비싸거나 오랜시간 실행되는 연산을 수행하는 것이 필요하다면, 여러분은 아마도 그것을 하나의 쓰레드로 옮겨야 한다. 이것은 여러분의 애플리케이션이 종료되는 최종 결과를 가지는, “애플리케이션이 응답하지 않습니다(Application Not Responding)”라는 공포스러운 다이얼로그가 사용자에게 보여지는 것을 막을 것이다.
By default, all code in an Activity as well as all its Views run in the same thread. This is the same thread that also handles UI events. For example, when the user presses a key, a key-down event is added to the Activity's main thread's queue. The event handler system needs to dequeue and handle that event quickly; if it doesn't, the system concludes after a few seconds that the application is hung and offers to kill it for the user.
디폴트로, 액티비티에 있는 모든 뷰들과 모든 코드들은 동일한 쓰레드에서 실행된다. 이것은 또한 UI 이벤트를 처리하는 것과 동일한 쓰레드이다. 예를 들어 사용자가 키를 눌렀을 때, 키 다운 이벤트가 액티비티의 메인 쓰레드 큐에 추가된다. 그 이벤트 핸들러 시스템은 그 이벤트를 재빨리 큐에서 꺼내어 처리하는 것이 필요하다. 만약 그것이 안된다면, 시스템은 몇 초 후에 애플리케이션이 멈춰있다고 결론내리고, 사용자에게 그것을 강제 종료하라고 제안한다.
If you have long-running code, running it inline in your Activity will run it on the event handler thread, effectively blocking the event handler. This will delay input processing, and result in the ANR dialogs. To avoid this, move your computations to a thread. This Design for Responsiveness document discusses how to do that..
만약 여러분이 오랜시간 실행되는 코드를 가지고 있다면, 그것을 여러분의 액티비티에서 인라인으로 실행하는 것은 그 이벤트 핸들러 쓰레드 상에서 그것을 실행할 것이다. 그것은 그 이벤트 핸들러를 사실상 방해한다. 이것은 입력 처리를 지연시킬 것이고, 결국 ANR 다이얼로그를 초래할 것이다. 이것을 피하기 위해, 여러분의 연산을 쓰레드로 옮겨라. 20장. “응답성을 위한 설계” 문서가 그것을 하는 방법에 대해 설명한다.
Any application worth using will probably have several different screens. When designing the screens of your UI, be sure to make use of multiple Activity object instances.
사용할 가치가 있는 임의의 애플리케이션은 아마 여러 개의 다른 스크린을 가지고 있을 것이다. 여러분의 UI 스크린을 디자인할 때, 여러 개의 액티비티 오브젝트 인스턴스들을 사용하도록 하라.
Depending on your development background, you may interpret an Activity as similar to something like a Java Applet, in that it is the entry point for your application. However, that's not quite accurate: where an Applet subclass is the single entry point for a Java Applet, an Activity should be thought of as one of potentially several entry points to your application. The only difference between your "main" Activity and any others you might have is that the "main" one just happens to be the only one that expressed an interest in the "android.intent.action.MAIN" action in your AndroidManifest..xml file.
여러분의 개발 경험에 의존해서, 여러분은 하나의 액티비티가 여러분 애플리케이션에 대한 시작점이라는 점에서 하나의 Java 애플릿과 유사하다고 해석할 수 있다. 하지만 그것은 그렇게 정확하지는 않다: Applet 서브클래스는 Java 애플릿에 대한 단일한 시작점이지만, 액티비티는 여러분의 애플리케이션에 대한 잠재적인 여러 시작점 중에 하나로 간주되어야 한다. 여러분의 “메인main” 액티비티와 여러분이 가질 수도 있는 다른 액티비티들간의 유일한 차이는, 그 메인main 액티비티는 단지 여러분의 AndroidManifest.xml 파일에 있는 “android.intent.action.MAIN” 액션에 관심을 나타내고 있다는 것이다.
So, when designing your application, think of your application as a federation of Activity objects. This will make your code a lot more maintainable in the long run, and as a nice side effect also plays nicely with Android's application history and "backstack" model.
그러므로 여러분의 애플리케이션을 디자인할 때, 여러분의 애플리케이션을 액티비티 오브젝트의 연합체로 생각하라. 이것은 결국에는 여러분의 코드를 훨씬 더 유지보수 가능하게 할 것이며, 그리고 또한 좋은 부수 효과로써 안드로이드 애플리케이션 히스토리와 “뒤로 가기backstack” 모델과 잘 협력하게 한다.
When it comes to the look-and-feel of the user interface, it's important to blend in nicely. Users are jarred by applications which contrast with the user interface they've come to expect. When designing your UIs, you should try and avoid rolling your own as much as possible. Instead, use a Theme. You can override or extend those parts of the theme that you need to, but at least you're starting from the same UI base as all the other applications. For all the details, read Applying Styles and Themes.
사용자 인터페이스의 룩앤필look-and-feel에 대해, 잘 조화를 이루는 것은 중요하다. 사용자들은 그들이 기대했던 사용자 인터페이스와 현저하게 다른 애플리케이션에 의해 거슬리게 된다. 여러분의 UI를 디자인할 때, 여러분은 가능한 많이 여러분 자신을 튀게 하는 것을 해서는 안된다. 대신, 테마를 사용하라. 여러분은 필요로 하는 그 테마의 일부를 오버라이드하거나 또는 확장할 수 있다. 그러나 최소한 여러분은 다른 모든 애플리케이션과 같은 UI 기반에서 시작해야 한다. 자세한 사항에 대해서는 “스타일과 테마 적용하기”를 읽어라.
Different Android-powered devices will support different screen resolutions. Some will even be able to change resolutions on the fly, such as by switching to landscape mode. It's important to make sure your layouts and drawables are flexible enough to display properly on a variety of device screens.
다른 안드로이드 디바이스들은 다른 스크린 해상도를 지원할 것이다. 어떤 것은 가로 모드landscape mode로 변경하는 것과 같이, 심지어는 동작 중에 해상도를 변경할 수도 있을 것이다. 여러분의 레이아웃과 드로어블drawables을 다양한 디바이스 스크린 상에서 적절하게 표시될 수 있을 만큼 유연하게 만드는 것은 중요하다.
Fortunately, this is very easy to do. In brief, what you must do is provide different versions of your artwork (if you use any) for the key resolutions, and then design your layout to accommodate various dimensions. (For example, avoid using hard-coded positions and instead use relative layouts.) If you do that much, the system handles the rest, and your application looks great on any device.
다행히 이것은 매운 쉬운 일이다. 간략하게 말해서, 여러분이 해야만 하는 것은 주요 해상도에 대해 다른 버전의 아트워크artwork를 제공하는 것이다. 그래서 여러분의 레이아웃이 다양한 크기를 수용하도록 디자인하라(예를 들어 힘들게 직접 계산한 위치를 사용하는 것을 피하고 대신 RelativeLayout을 사용하라). 만약 여러분이 이렇게 많이 한다면, 시스템은 그 나머지를 처리할 것이고 여러분의 애플리케이션은 어떤 디바이스에서도 멋지게 보일 것이다.
Android devices will come with a variety of network-connectivity options. All will have some data-access provision, though some will be faster than others. The lowest common denominator, however, is GPRS, the non-3G data service for GSM networks. Even 3G-capable devices will spend lots of time on non-3G networks, so slow networks will remain a reality for quite a long time to come.
안드로이드 디바이스들은 다양한 네트워크 커넥션 옵션과 함께 동작한다. 어떤 것이 다른 어떤 것들보다 더 빠르다 할 지라도, 모든 옵션들은 약간의 데이터 접근 규정data-access provision을 가질 것이다. 하지만 그 최소 공통 분모는 GSM 네트워크에 대해서는 3G 데이터 서비스가 아닌 GPRS이다. 심지어 3G가 가능한 디바이스 조차도 많은 시간을 3G가 지원되지 않는 네트워크 상에서 보내게 될 것이다. 그러므로 느린 네트워크는 꽤나 오랜 시간 동안 접하게 되는 현실로 남을 것이다.
That's why you should always code your applications to minimize network accesses and bandwidth. You can't assume the network is fast, so you should always plan for it to be slow. If your users happen to be on faster networks, then that's great their experience will only improve. You want to avoid the inverse case though: applications that are usable some of the time, but frustratingly slow the rest based on where the user is at any given moment are likely to be unpopular.
이것이 여러분이 애플리케이션을 네트워크 접속과 대여폭을 최소화하도록 작성해야 하는 이유이다. 여러분은 네트워크가 빠르다고 가정할 수 없다. 그러므로 여러분은 느린 네트워크에 대한 계획을 항상 가지고 있어야 한다. 만약 여러분의 사용자가 더 빠른 네트워크에 있을 수 있다면, 그것은 좋은 일이다 - 단지 사용자 경험이 개선될 뿐이다. 여러분은 그 반대의 경우를 피하고 싶을 뿐이다: 어떤 시간에는 사용될 수 있지만, 어느 특정 시점에 주어진 사용자가 있는 곳에 기반하여 나머지 시간에는 실망스럽게도 느린 애플리케이션은 인기가 없을 것이다.
One potential gotcha here is that it's very easy to fall into this trap if you're using the emulator, since the emulator uses your desktop computer's network connection. That's almost guaranteed to be much faster than a cell network, so you'll want to change the settings on the emulator that simulate slower network speeds. You can do this in Eclipse, in the "Emulator Settings" tab of your launch configuration or via a command-line option when starting the emulator.
만약 여러분이 에뮬레이터를 사용하고 있다면 이런 함정에 빠지는 것이 매우 쉽다. 왜냐하면 그 에뮬레이터가 여러분의 데스크탑 컴퓨터의 네트워크 커넥션을 사용하고 있기 때문이다. 그것은 대개 무선 네트워크보다 훨씬 더 빠르다는 것이 보장된다. 그러므로 여러분은 더 느린 네트워크 속도를 시뮬레이션하는 에뮬레이터의 설정을 변경하고 싶을 것이다. 여러분은 이클립스eclipse에서 런치 설정의 “Emulator Settings” 탭이나 또는 에뮬레이터를 시작할 때 커맨드 라인의 옵션을 통해 이것을 할 수 있다.
Android will support a variety of handset form-factors. That's a fancy way of saying that some Android devices will have full "QWERTY" keyboards, while others will have 40-key, 12-key, or even other key configurations. Similarly, some devices will have touch-screens, but many won't.
안드로이드는 다양한 핸드폰 형태를 지원할 것이다. 어떤 안드로이드 디바이스는 전체 QWERTY 키보드를 가지고 있을 것이고, 그에 반해 다른 것들은 40-key, 12-key, 또는 다른 키 설정을 가질 것이라고 말하는 것은 엉뚱한 생각이다. 비슷하게, 어떤 디바이스들은 터치 스크린을 가질 것이고, 많은 것들은 그렇지 않을 것이다.
When building your applications, keep that in mind. Don't make assumptions about specific keyboard layouts -- unless, of course, you're really interested in restricting your application so that it can only be used on those devices.
여러분의 애플리케이션을 만들 때, 이를 염두에 두어라: 특정 키보드 레이아웃에 대해 가정하지마라 ? 당연하겠지만, 만약 여러분의 애플리케이션이 특정 디바이스에서만 사용될 수 있도록 그것을 제한하는 것에 관심을 가지지 않는다면 이를 염두에 두어야 한다.
A mobile device isn't very mobile if it's constantly plugged into the wall. Mobile devices are battery-powered, and the longer we can make that battery last on a charge, the happier everyone is especially the user. Two of the biggest consumers of battery power are the processor, and the radio; that's why it's important to write your applications to do as little work as possible, and use the network as infrequently as possible.
모바일 디바이스가 항상 벽 플러그에 꽂혀져 있다면 전혀 모바일이 아니다. 모바일 디바이스는 배터리로 동작한다. 그리고 배터리가 더 오래가도록 만들 수 있다면, 사용자는 더 행복하게 될 것이다 - 배터리 전원에 대한 가장 큰 두 소비자는 프로세서와 라디오radio이다; 이것이 여러분의 애플리케이션을 가능한 한 적게 작업하고, 그리고 가능한 한 드물게 네트워크를 사용하게 작성하는 것이 중요한 이유이다.
Minimizing the amount of processor time your application uses really comes down to writing efficient code. To minimize the power drain from using the radio, be sure to handle error conditions gracefully, and only fetch what you need. For example, don't constantly retry a network operation if one failed. If it failed once, it's likely because the user has no reception, so it's probably going to fail again if you try right away; all you'll do is waste battery power.
여러분의 애플리케이션이 사용하고 있는 프로세서 시간의 양을 최소화하는 것은 실제로는 효율적인 코드를 작성하는 것이 된다. 라디오 사용으로부터 배터리 소모를 최소화하도록 하기 위해 우아하게 에러 조건을 처리하고 여러분이 필요한 것만을 가져오도록 하라. 예를 들어 한 번 실패하면 네트워크 오퍼레이션을 계속 재시도하지 마라. 만약 그것이 한 번 실패하면, 그것은 아마도 사용자가 어떤 수신도 하지 못하기 때문이다. 그러므로 만약 여러분이 바로 다시 시도한다면 그것은 아마도 다시 실패하게 될 것이다; 여러분이 하는 모든 것은 배터리 전원을 낭비한다.
Users are pretty smart: if your program is power-hungry, you can count on them noticing. The only thing you can be sure of at that point is that your program won't stay installed very long.
사용자들은 꽤 영리하다: 만약 여러분의 프로그램이 배터리를 많이 소모한다면, 사용자들은 그것을 알아챌 것이다. 그 시점에서 여러분이 확실하게 할 수 있는 유일한 것은 여러분의 프로그램이 오랫동안 설치되어 있지 않을 것이라는 것이다.