나는 동반 정의와 함께 안드로이드 문서 에서이 용어를 보았습니다.
이는 완료된 후 시스템에서 데이터를 보유하는 브로드 캐스트이므로 클라이언트는 다음 브로드 캐스트를 기다릴 필요없이 해당 데이터를 빠르게 검색 할 수 있습니다.
무슨 뜻이에요? 누군가 특정 예를 들어 사용법을 자세히 설명 할 수 있습니까? 이 인 텐트를 사용하려면 허가를 요청해야한다고 생각합니까? 왜 그렇습니까?
<uses-permission android:name="android.permission.BROADCAST_STICKY"/> - Allows an application to broadcast sticky intents.
답변:
활동 onPause이 일반 방송으로 호출 하면 방송 수신을 놓칠 수 있습니다. 에서 시작된 후 고정 브로드 캐스트를 확인할 수 있습니다 onResume.
고정 브로드 캐스트는 더 이상 사용되지 않습니다.
sendStickyBroadcast설명서를 참조하십시오 .
이 메서드는 API 레벨 21에서 더 이상 사용되지 않습니다.
고정 방송은 사용해서는 안됩니다. 보안 (누구나 액세스 가능), 보호 (누구나 수정할 수 있음) 및 기타 많은 문제를 제공하지 않습니다. 권장되는 패턴은 고정되지 않은 브로드 캐스트를 사용하여 무언가 변경되었음을보고하고 앱이 원할 때마다 현재 값을 검색하는 또 다른 메커니즘을 사용하는 것입니다.
Intent intent = new Intent("some.custom.action");
intent.putExtra("some_boolean", true);
sendStickyBroadcast(intent);
관련 게시물 : Android에서 sendStickyBroadcast와 sendBroadcast의 차이점은 무엇입니까?
수신기의 .NET Framework에서 사용하려면 removeStickyBroadcast(Intent)및 API 레벨 5 이상을 참조하십시오 .isInitialStickyBroadcast()onReceive
sendStickyBroadcast()sendBroadcast(Intent)고정이라고 하는 기능을 수행합니다. 즉, 전송하는 인 텐트는 브로드 캐스트가 완료된 후에도 유지되므로 다른 사용자가의 반환 값을 통해 해당 데이터를 빠르게 검색 할 수 있습니다 registerReceiver(BroadcastReceiver, IntentFilter). 다른 모든 방법에서 이것은 sendBroadcast(Intent). 운영 체제를 통해 전송되는 고정 브로드 캐스트의 한 가지 예는 ACTION_BATTERY_CHANGED. registerReceiver()해당 작업 을 호출 하면 (null이 있더라도) BroadcastReceiver해당 작업에 대해 마지막으로 브로드 캐스트 된 인 텐트를 얻습니다. 따라서 배터리의 모든 향후 상태 변경에 대해 반드시 등록하지 않고도이를 사용하여 배터리 상태를 찾을 수 있습니다.
고정 브로드 캐스트의 값은 마지막 브로드 캐스트였으며 현재 고정 캐시에 보관 된 값입니다. 지금 당장받은 방송의 가치가 아닙니다. 언제든지 액세스 할 수있는 브라우저 쿠키와 같다고 말할 수 있다고 생각합니다. 스티키 브로드 캐스트는 이제 스티키 브로드 캐스트 방법에 대한 문서 ( 예 :)에 따라 더 이상 사용되지 않습니다 .
이 메서드는 API 레벨 21에서 더 이상 사용되지 않습니다. 고정 브로드 캐스트를 사용해서는 안됩니다. 보안 (누구나 액세스 가능), 보호 (누구나 수정할 수 있음) 및 기타 많은 문제를 제공하지 않습니다. 권장되는 패턴은 고정되지 않은 브로드 캐스트를 사용하여 무언가 변경되었음을보고하고 앱이 원할 때마다 현재 값을 검색하는 또 다른 메커니즘을 사용하는 것입니다.
정상적인 브로드 캐스트 인 텐트는 시스템에서 전송 및 처리 된 후에는 더 이상 사용할 수 없습니다. sendStickyBroadcast (Intent) 메서드를 사용하는 경우 Intent가 고정되어 브로드 캐스트가 완료된 후에도 전송중인 Intent가 유지됩니다.
내 블로그 참조 : 여기에 링크 설명 입력
Sticky broadcasts should not be used. They provide no security (anyone can access them), no protection (anyone can modify them), and many other problems. The recommended pattern is to use a non-sticky broadcast to report that something has changed, with another mechanism for apps to retrieve the current value whenever desired.