免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP，暢享免費電子書等14項超值服

開通VIP

首頁

好書

留言交流

下載APP

聯(lián)系客服
一個帖子學會Android開發(fā)四大組件

注：本文來自“友盟杯”，僅在此閱讀，學習


這個文章主要是講Android開發(fā)的四大組件，本文主要分為

一、Activity詳解
二、Service詳解
三、Broadcast Receiver詳解
四、Content Provider詳解
外加一個重要組件 intent的詳解。



一、Activity詳解
Activty的生命周期的也就是它所在進程的生命周期。


 

一個Activity的啟動順序：

onCreate()——>onStart()——>onResume()

當另一個Activity啟動時:
第一個Activity onPause()——>第二個Activity    onCreate()——>onStart()——>onResume() 
——>第一個Activity   onStop()

當返回到第一個Activity時：
第二個Activity onPause() ——> 第一個Activity　onRestart()——>onStart()——>onResume() 
——>第二個Activity   onStop()——>onDestroy()

一個Activity的銷毀順序:
（情況一）onPause()——><Process Killed> 
（情況二）onPause()——>onStop()——><Process Killed> 
（情況三）onPause()——>onStop()——>onDestroy()

　　每一個活動（ Activity ）都處于某一個狀態(tài)，對于開發(fā)者來說，是無法控制其應用程序處于某一個狀態(tài)的，這些均由系統(tǒng)來完成。

　　但是當一個活動的狀態(tài)發(fā)生改變的時候，開發(fā)者可以通過調用 onXX() 的方法獲取到相關的通知信息。

　　在實現(xiàn) Activity 類的時候，通過覆蓋（ override ）這些方法即可在你需要處理的時候來調用。


         一、 onCreate ：當活動第一次啟動的時候，觸發(fā)該方法，可以在此時完成活動的初始化工作。 
onCreate 方法有一個參數(shù)，該參數(shù)可以為空（ null ），也可以是之前調用 onSaveInstanceState （）方法保存的狀態(tài)信息。
        二、  onStart ：該方法的觸發(fā)表示所屬活動將被展現(xiàn)給用戶。
        三、  onResume ：當一個活動和用戶發(fā)生交互的時候，觸發(fā)該方法。
       四、  onPause ：當一個正在前臺運行的活動因為其他的活動需要前臺運行而轉入后臺運行的時候，觸發(fā)該方法。這時候需要將活動的狀態(tài)持久化，比如正在編輯的數(shù)據庫記錄等。
        五、  onStop ：當一個活動不再需要展示給用戶的時候，觸發(fā)該方法。如果內存緊張，系統(tǒng)會直接結束這個活動，而不會觸發(fā) onStop 方法。 所以保存狀態(tài)信息是應該在onPause時做，而不是onStop時做?；顒尤绻麤]有在前臺運行，都將被停止或者Linux管理進程為了給新的活動預留足夠的存儲空間而隨時結束這些活動。因此對于開發(fā)者來說，在設計應用程序的時候，必須時刻牢記這一原則。在一些情況下，onPause方法或許是活動觸發(fā)的最后的方法，因此開發(fā)者需要在這個時候保存需要保存的信息。
        六、onRestart ：當處于停止狀態(tài)的活動需要再次展現(xiàn)給用戶的時候，觸發(fā)該方法。
        七、 onDestroy ：當活動銷毀的時候，觸發(fā)該方法。和 onStop 方法一樣，如果內存緊張，系統(tǒng)會直接結束這個活動而不會觸發(fā)該方法。
·        onSaveInstanceState ：系統(tǒng)調用該方法，允許活動保存之前的狀態(tài)，比如說在一串字符串中的光標所處的位置等。 
通常情況下，開發(fā)者不需要重寫覆蓋該方法，在默認的實現(xiàn)中，已經提供了自動保存活動所涉及到的用戶界面組件的所有狀態(tài)信息。

　　Activity棧

　　上面提到開發(fā)者是無法控制Activity的狀態(tài)的，那Activity的狀態(tài)又是按照何種邏輯來運作的呢？這就要知道 Activity 棧。
　　每個Activity的狀態(tài)是由它在Activity棧（是一個后進先出LIFO，包含所有正在運行Activity的隊列）中的位置決定的。
　　當一個新的Activity啟動時，當前的活動的Activity將會移到Activity棧的頂部。
　　如果用戶使用后退按鈕返回的話，或者前臺的Activity結束，活動的Activity就會被移出棧消亡，而在棧上的上一個活動的Activity將會移上來并變?yōu)榛顒訝顟B(tài)。如下圖所示：
 　　一個應用程序的優(yōu)先級是受最高優(yōu)先級的Activity影響的。當決定某個應用程序是否要終結去釋放資源，Android內存管理使用棧來決定基于Activity的應用程序的優(yōu)先級。
　　Activity狀態(tài)
　　一般認為Activity有以下四種狀態(tài)：
　　活動的：當一個Activity在棧頂，它是可視的、有焦點、可接受用戶輸入的。Android試圖盡最大可能保持它活動狀態(tài)，殺死其它Activity來確保當前活動Activity有足夠的資源可使用。當另外一個Activity被激活，這個將會被暫停。
　　暫停：在很多情況下，你的Activity可視但是它沒有焦點，換句話說它被暫停了。有可能原因是一個透明或者非全屏的Activity被激活。
　　當被暫停，一個Activity仍會當成活動狀態(tài)，只不過是不可以接受用戶輸入。在極特殊的情況下，Android將會殺死一個暫停的Activity來為活動的Activity提供充足的資源。當一個Activity變?yōu)橥耆[藏，它將會變成停止。
　　停止：當一個Activity不是可視的，它“停止”了。這個Activity將仍然在內存中保存它所有的狀態(tài)和會員信息。盡管如此，當其它地方需要內存時，它將是最有可能被釋放資源的。當一個Activity停止后，一個很重要的步驟是要保存數(shù)據和當前UI狀態(tài)。一旦一個Activity退出或關閉了，它將變?yōu)榇脿顟B(tài)。
　　待用： 在一個Activity被殺死后和被裝在前，它是待用狀態(tài)的。待用Acitivity被移除Activity棧，并且需要在顯示和可用之前重新啟動它。
　　activity的四種加載模式
　　在android的多activity開發(fā)中，activity之間的跳轉可能需要有多種方式，有時是普通的生成一個新實例，有時希望跳轉到原來某個activity實例，而不是生成大量的重復的activity。加載模式便是決定以哪種方式啟動一個跳轉到原來某個Activity實例。
　　在android里，有4種activity的啟動模式，分別為：
　　·standard: 標準模式，一調用startActivity()方法就會產生一個新的實例。
　　·singleTop: 如果已經有一個實例位于Activity棧的頂部時，就不產生新的實例，而只是調用Activity中的newInstance()方法。如果不位于棧頂，會產生一個新的實例。
　　·singleTask: 會在一個新的task中產生這個實例，以后每次調用都會使用這個，不會去產生新的實例了。
　　·singleInstance: 這個跟singleTask基本上是一樣，只有一個區(qū)別：在這個模式下的Activity實例所處的task中，只能有這個activity實例，不能有其他的實例。
　　這些啟動模式可以在功能清單文件AndroidManifest.xml中進行設置，中的launchMode屬性。
　　相關的代碼中也有一些標志可以使用,比如我們想只啟用一個實例,則可以使用 Intent.FLAG_ACTIVITY_REORDER_TO_FRONT 標志，這個標志表示：如果這個activity已經啟動了，就不產生新的activity，而只是把這個activity實例加到棧頂來就可以了。
  1. 　　Intent intent = new Intent(ReorderFour.this, ReorderTwo.class);
  2. 　　intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
  3. 　　startActivity(intent);
復制代碼


　　Activity的加載模式受啟動Activity的Intent對象中設置的Flag和manifest文件中Activity的元素的特性值交互控制。
　　下面是影響加載模式的一些特性
　　核心的Intent Flag有：
　　FLAG_ACTIVITY_NEW_TASK
　　FLAG_ACTIVITY_CLEAR_TOP
　　FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
　　FLAG_ACTIVITY_SINGLE_TOP

核心的特性有：
　　taskAffinity
　　launchMode
　　allowTaskReparenting
　　clearTaskOnLaunch
　　alwaysRetainTaskState
　　finishOnTaskLaunch

　四種加載模式的區(qū)別
　　所屬task的區(qū)別
　　一般情況下，“standard”和”singleTop”的activity的目標task，和收到的Intent的發(fā)送者在同一個task內，就相當于誰調用它，它就跟誰在同一個Task中。
　　除非Intent包括參數(shù)FLAG_ACTIVITY_NEW_TASK。如果提供了FLAG_ACTIVITY_NEW_TASK參數(shù)，會啟動到別的task里。
　　“singleTask”和”singleInstance” 總是把要啟動的activity作為一個task的根元素，他們不會被啟動到一個其他task里。
　　是否允許多個實例
　　“standard”和”singleTop”可以被實例化多次，并且是可以存在于不同的task中；這種實例化時一個task可以包括一個activity的多個實例；
　　“singleTask”和”singleInstance”則限制只生成一個實例，并且是task的根元素。
　　singleTop 要求如果創(chuàng)建intent的時候棧頂已經有要創(chuàng)建的Activity的實例，則將intent發(fā)送給該實例，而不創(chuàng)建新的實例。
　　是否允許其它activity存在于本task內
　　“singleInstance”獨占一個task，其它activity不能存在那個task里；
　　如果它啟動了一個新的activity，不管新的activity的launch mode 如何，新的activity都將會到別的task里運行（如同加了FLAG_ACTIVITY_NEW_TASK參數(shù)）。
　　而另外三種模式，則可以和其它activity共存。
　　是否每次都生成新實例
　　“standard”對于每一個啟動Intent都會生成一個activity的新實例；
　　“singleTop”的activity如果在task的棧頂?shù)脑?，則不生成新的該activity的實例，直接使用棧頂?shù)膶嵗?，否則，生成該activity的實例。
　　比如：
　　現(xiàn)在task棧元素為A-B-C-D（D在棧頂），這時候給D發(fā)一個啟動intent，如果D是 “standard”的，則生成D的一個新實例，棧變?yōu)锳－B－C－D－D。
　　如果D是singleTop的話，則不會生產D的新實例，棧狀態(tài)仍為A-B-C-D
　　如果這時候給B發(fā)Intent的話，不管B的launchmode是”standard” 還是 “singleTop” ，都會生成B的新實例，棧狀態(tài)變?yōu)锳-B-C-D-B。
　　“singleInstance”是其所在棧的唯一activity，它會每次都被重用。
　　“singleTask” 如果在棧頂，則接受intent，否則，該intent會被丟棄，但是該task仍會回到前臺。 當已經存在的activity實例處理新的intent時候，會調用onNewIntent()方法，如果收到intent生成一個activity實例，那么用戶可以通過back鍵回到上一個狀態(tài)；如果是已經存在的一個activity來處理這個intent的話，用戶不能通過按back鍵返回到這之前的狀態(tài)。
-----------------------------------
二、Service詳解

　　service可以在和多場合的應用中使用，比如播放多媒體的時候用戶啟動了其他Activity這個時候程序要在后臺繼續(xù)播放，比如檢測SD卡上文件的變化，再或者在后臺記錄你地理信息位置的改變等等，總之服務嘛，總是藏在后頭的。

　　Service是在一段不定的時間運行在后臺，不和用戶交互應用組件。每個Service必須在manifest中 通過<service>來聲明?？梢酝ㄟ^contect.startservice和contect.bindserverice來啟動。

　　Service和其他的應用組件一樣，運行在進程的主線程中。這就是說如果service需要很多耗時或者阻塞的操作，需要在其子線程中實現(xiàn)。

　　service的兩種模式（startService()/bindService()不是完全分離的）：

　　本地服務 Local Service 用于應用程序內部。

　　它可以啟動并運行，直至有人停止了它或它自己停止。在這種方式下，它以調用Context.startService()啟動，而以調用Context.stopService()結束。它可以調用Service.stopSelf() 或 Service.stopSelfResult()來自己停止。不論調用了多少次startService()方法，你只需要調用一次stopService()來停止服務。

　　用于實現(xiàn)應用程序自己的一些耗時任務，比如查詢升級信息，并不占用應用程序比如Activity所屬線程，而是單開線程后臺執(zhí)行，這樣用戶體驗比較好。
　　遠程服務 Remote Service 用于android系統(tǒng)內部的應用程序之間。

　　它可以通過自己定義并暴露出來的接口進行程序操作。客戶端建立一個到服務對象的連接，并通過那個連接來調用服務。連接以調用Context.bindService()方法建立，以調用 Context.unbindService()關閉。多個客戶端可以綁定至同一個服務。如果服務此時還沒有加載，bindService()會先加載它。

　　可被其他應用程序復用，比如天氣預報服務，其他應用程序不需要再寫這樣的服務，調用已有的即可。

　生命周期

使用context.startService() 啟動Service是會會經歷:

　　context.startService() ->onCreate()- >onStart()->Service running

　　context.stopService() | ->onDestroy() ->Service stop

　　如果Service還沒有運行，則android先調用onCreate()然后調用onStart()；如果Service已經運行，則只調用onStart()，所以一個Service的onStart方法可能會重復調用多次。

　　stopService的時候直接onDestroy，如果是調用者自己直接退出而沒有調用stopService的話，Service會一直在后臺運行。該Service的調用者再啟動起來后可以通過stopService關閉Service。

　　所以調用startService的生命周期為：onCreate --> onStart(可多次調用) --> onDestroy
　　使用使用context.bindService()啟動Service會經歷：

　　context.bindService()->onCreate()->onBind()->Service running

　　onUnbind() -> onDestroy() ->Service stop

　　onBind將返回給客戶端一個IBind接口實例，IBind允許客戶端回調服務的方法，比如得到Service運行的狀態(tài)或其他操作。這個時候把調用者（Context，例如Activity）會和Service綁定在一起，Context退出了，Srevice就會調用onUnbind->onDestroy相應退出。

　　所以調用bindService的生命周期為：onCreate --> onBind(只一次，不可多次綁定) --> onUnbind --> onDestory。

　　在Service每一次的開啟關閉過程中，只有onStart可被多次調用(通過多次startService調用)，其他onCreate，onBind，onUnbind，onDestory在一個生命周期中只能被調用一次。

而啟動service，根據onStartCommand的返回值不同，有兩個附加的模式：

　　1. START_STICKY 用于顯示啟動和停止service。

　　2. START_NOT_STICKY或START_REDELIVER_INTENT用于有命令需要處理時才運行的模式。

　　服務不能自己運行，需要通過調用Context.startService()或Context.bindService()方法啟動服務。這兩個方法都可以啟動Service，但是它們的使用場合有所不同。

　　1. 使用startService()方法啟用服務，調用者與服務之間沒有關連，即使調用者退出了，服務仍然運行。

　　如果打算采用Context.startService()方法啟動服務，在服務未被創(chuàng)建時，系統(tǒng)會先調用服務的onCreate()方法，接著調用onStart()方法。

　　如果調用startService()方法前服務已經被創(chuàng)建，多次調用startService()方法并不會導致多次創(chuàng)建服務，但會導致多次調用onStart()方法。

　　采用startService()方法啟動的服務，只能調用Context.stopService()方法結束服務，服務結束時會調用onDestroy()方法。

　　2. 使用bindService()方法啟用服務，調用者與服務綁定在了一起，調用者一旦退出，服務也就終止，大有“不求同時生，必須同時死”的特點。

　　onBind()只有采用Context.bindService()方法啟動服務時才會回調該方法。該方法在調用者與服務綁定時被調用，當調用者與服務已經綁定，多次調用Context.bindService()方法并不會導致該方法被多次調用。

　　采用Context.bindService()方法啟動服務時只能調用onUnbind()方法解除調用者與服務解除，服務結束時會調用onDestroy()方法。

　　看看官方給出的比較流程示意圖：

　　官方文檔告訴我們，一個service可以同時start并且bind，在這樣的情況，系統(tǒng)會一直保持service的運行狀態(tài)如果service已經start了或者BIND_AUTO_CREATE標志被設置。如果沒有一個條件滿足，那么系統(tǒng)將會調用onDestory方法來終止service.所有的清理工作（終止線程，反注冊接收器）都在onDestory中完成。

　　擁有service的進程具有較高的優(yōu)先級

　　官方文檔告訴我們，Android系統(tǒng)會盡量保持擁有service的進程運行，只要在該service已經被啟動(start)或者客戶端連接(bindService)到它。當內存不足時，需要保持，擁有service的進程具有較高的優(yōu)先級。

　　1． 如果service正在調用onCreate,onStartCommand或者onDestory方法，那么用于當前service的進程則變?yōu)榍芭_進程以避免被killed。

　　2． 如果當前service已經被啟動(start)，擁有它的進程則比那些用戶可見的進程優(yōu)先級低一些，但是比那些不可見的進程更重要，這就意味著service一般不會被killed.

　　3． 如果客戶端已經連接到service (bindService),那么擁有Service的進程則擁有最高的優(yōu)先級，可以認為service是可見的。

　　4． 如果service可以使用startForeground(int, Notification)方法來將service設置為前臺狀態(tài)，那么系統(tǒng)就認為是對用戶可見的，并不會在內存不足時killed。

　　如果有其他的應用組件作為Service,Activity等運行在相同的進程中，那么將會增加該進程的重要性。

　　本地service

　　1.不需和Activity交互的本地服務

  1. public class LocalService extends Service {

  3. private static final String TAG = "LocalService";

  5. @Override
  6. public IBinder onBind(Intent intent) {
  7. Log.i(TAG, "onBind");
  8. return null;
  9. }

  11. @Override
  12. public void onCreate() {
  13. Log.i(TAG, "onCreate");
  14. super.onCreate();
  15. }

  17. @Override
  18. public void onDestroy() {
  19. Log.i(TAG, "onDestroy");
  20. super.onDestroy();
  21. }

  23. @Override
  24. public void onStart(Intent intent, int startId) {
  25. Log.i(TAG, "onStart");
  26. super.onStart(intent, startId);
  27. }
  28. }
復制代碼
　　Activity:
  1. public class ServiceActivity extends Activity {

  3. @Override
  4. protected void onCreate(Bundle savedInstanceState) {
  5. super.onCreate(savedInstanceState);
  6. setContentView(R.layout.servicedemo);

  8. ((Button) findViewById(R.id.startLocalService)).setOnClickListener(
  9. new View.OnClickListener(){

  11. @Override
  12. public void onClick(View view) {
  13. // TODO Auto-generated method stub
  14. startService(new Intent("com.demo.SERVICE_DEMO"));
  15. } 
  16. });

  18. ((Button) findViewById(R.id.stopLocalService)).setOnClickListener(
  19. new View.OnClickListener(){

  21. @Override
  22. public void onClick(View view) {
  23. // TODO Auto-generated method stub
  24. stopService(new Intent("com.demo.SERVICE_DEMO"));
  25. }
  26. });
  27. }

  29. }
復制代碼
　　在AndroidManifest.xml添加：
  1. <service android:name=".LocalService">
  2. <intent-filter>
  3. <action android:name="com.demo.SERVICE_DEMO" />
  4. <category android:name="android.intent.category.default" />
  5. </intent-filter>
  6. </service>
復制代碼
　　否則啟動服務時會提示new Intent找不到"com.demo.SERVICE_DEMO"。

　　對于這類不需和Activity交互的本地服務，是使用startService/stopService的最好例子。

　　運行時可以發(fā)現(xiàn)第一次startService時，會調用onCreate和onStart，在沒有stopService前，無論點擊多少次startService，都只會調用onStart。而stopService時調用onDestroy。再次點擊stopService，會發(fā)現(xiàn)不會進入service的生命周期的，即不會再調用onCreate，onStart和onDestroy。

　　而onBind在startService/stopService中沒有調用。

　　2.本地服務和Activity交互

　　對于這種case，官方的sample(APIDemo\app.LocalService)是最好的例子:

  1. /**
  2. * This is an example of implementing an application service that runs locally
  3. * in the same process as the application. The {@link LocalServiceController}
  4. * and {@link LocalServiceBinding} classes show how to interact with the
  5. * service.
  6. *
  7. * <p>Notice the use of the {@link NotificationManager} when interesting things
  8. * happen in the service. This is generally how background services should
  9. * interact with the user, rather than doing something more disruptive such as
  10. * calling startActivity().
  11. */
  12. public class LocalService extends Service {
  13. private NotificationManager mNM;

  15. /**
  16. * Class for clients to access. Because we know this service always
  17. * runs in the same process as its clients, we don't need to deal with
  18. * IPC.
  19. */
  20. public class LocalBinder extends Binder {
  21. LocalService getService() {
  22. return LocalService.this;
  23. }
  24. }

  26. @Override
  27. public void onCreate() {
  28. mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);

  30. // Display a notification about us starting. We put an icon in the status bar.
  31. showNotification();
  32. }

  34. @Override
  35. public int onStartCommand(Intent intent, int flags, int startId) {
  36. Log.i("LocalService", "Received start id " + startId + ": " + intent);
  37. // We want this service to continue running until it is explicitly
  38. // stopped, so return sticky.
  39. return START_STICKY;
  40. }

  42. @Override
  43. public void onDestroy() {
  44. // Cancel the persistent notification.
  45. mNM.cancel(R.string.local_service_started);

  47. // Tell the user we stopped.
  48. Toast.makeText(this, R.string.local_service_stopped, Toast.LENGTH_SHORT).show();
  49. }

  51. @Override
  52. public IBinder onBind(Intent intent) {
  53. return mBinder;
  54. }

  56. // This is the object that receives interactions from clients. See
  57. // RemoteService for a more complete example.
  58. private final IBinder mBinder = new LocalBinder();

  60. /**
  61. * Show a notification while this service is running.
  62. */
  63. private void showNotification() {
  64. // In this sample, we'll use the same text for the ticker and the expanded notification
  65. CharSequence text = getText(R.string.local_service_started);

  67. // Set the icon, scrolling text and timestamp
  68. Notification notification = new Notification(R.drawable.stat_sample, text,
  69. System.currentTimeMillis());

  71. // The PendingIntent to launch our activity if the user selects this notification
  72. PendingIntent contentIntent = PendingIntent.getActivity(this, 0,
  73. new Intent(this, LocalServiceController.class), 0);

  75. // Set the info for the views that show in the notification panel.
  76. notification.setLatestEventInfo(this, getText(R.string.local_service_label),
  77. text, contentIntent);

  79. // Send the notification.
  80. // We use a layout id because it is a unique number. We use it later to cancel.
  81. mNM.notify(R.string.local_service_started, notification);
  82. }
  83. }
復制代碼
　　這里可以發(fā)現(xiàn)onBind需要返回一個IBinder對象。也就是說和上一例子LocalService不同的是，

　　1. 添加了一個public內部類繼承Binder，并添加getService方法來返回當前的Service對象；

　　2. 新建一個IBinder對象--new那個Binder內部類；

　　3. onBind方法返還那個IBinder對象。

　　Activity:

  1. /**
  2. * <p>Example of binding and unbinding to the {@link LocalService}.
  3. * This demonstrates the implementation of a service which the client will
  4. * bind to, receiving an object through which it can communicate with the service.</p>
  5. */
  6. public class LocalServiceBinding extends Activity {
  7. private boolean mIsBound;
  8. private LocalService mBoundService;

  10. @Override
  11. protected void onCreate(Bundle savedInstanceState) {
  12. super.onCreate(savedInstanceState);

  14. setContentView(R.layout.local_service_binding);

  16. // Watch for button clicks.
  17. Button button = (Button)findViewById(R.id.bind);
  18. button.setOnClickListener(mBindListener);
  19. button = (Button)findViewById(R.id.unbind);
  20. button.setOnClickListener(mUnbindListener);
  21. }

  23. private ServiceConnection mConnection = new ServiceConnection() {
  24. public void onServiceConnected(ComponentName className, IBinder service) {
  25. // This is called when the connection with the service has been
  26. // established, giving us the service object we can use to
  27. // interact with the service. Because we have bound to a explicit
  28. // service that we know is running in our own process, we can
  29. // cast its IBinder to a concrete class and directly access it.
  30. mBoundService = ((LocalService.LocalBinder)service).getService(); 

  32. // Tell the user about this for our demo.
  33. Toast.makeText(LocalServiceBinding.this, R.string.local_service_connected,
  34. Toast.LENGTH_SHORT).show();
  35. }

  37. public void onServiceDisconnected(ComponentName className) { 
  38. // This is called when the connection with the service has been
  39. // unexpectedly disconnected -- that is, its process crashed.
  40. // Because it is running in our same process, we should never
  41. // see this happen.
  42. mBoundService = null;
  43. Toast.makeText(LocalServiceBinding.this, R.string.local_service_disconnected,
  44. Toast.LENGTH_SHORT).show();
  45. }
  46. };

  48. private OnClickListener mBindListener = new OnClickListener() {
  49. public void onClick(View v) {
  50. // Establish a connection with the service. We use an explicit
  51. // class name because we want a specific service implementation that
  52. // we know will be running in our own process (and thus won't be
  53. // supporting component replacement by other applications).
  54. bindService(new Intent(LocalServiceBinding.this, 
  55. LocalService.class), mConnection, Context.BIND_AUTO_CREATE);
  56. mIsBound = true;
  57. }
  58. };

  60. private OnClickListener mUnbindListener = new OnClickListener() {
  61. public void onClick(View v) {
  62. if (mIsBound) {
  63. // Detach our existing connection.
  64. unbindService(mConnection);
  65. mIsBound = false;
  66. }
  67. }
  68. };
  69. }
復制代碼


　　明顯看出這里面添加了一個名為ServiceConnection類，并實現(xiàn)了onServiceConnected(從IBinder獲取Service對象)和onServiceDisconnected(set Service to null)。

　　而bindService和unbindService方法都是操作這個ServiceConnection對象的。

　　AndroidManifest.xml里添加:

  1. 　　<service android:name=".app.LocalService" />
復制代碼
　　這里沒什么特別的，因為service沒有需要什么特別的action，所以只是聲明service而已，而activity和普通的沒差別。

　　運行時，發(fā)現(xiàn)調用次序是這樣的：

　　bindService:

　　1.LocalService : onCreate

　　2.LocalService : onBind

　　3.Activity: onServiceConnected

　　unbindService: 只是調用onDestroy

　　可見，onStart是不會被調用的，而onServiceDisconnected沒有調用的原因在上面代碼的注釋有說明。


------------------------
三、Broadcast Receiver詳解


　　BroadcastReceiver 用于異步接收廣播Intent。主要有兩大類，用于接收廣播的：

　　·正常廣播 Normal broadcasts（用 Context.sendBroadcast()發(fā)送）是完全異步的。它們都運行在一個未定義的順序，通常是在同一時間。這樣會更有效，但意味著receiver不能包含所要使用的結果或中止的API。

　　·有序廣播 Ordered broadcasts（用 Context.sendOrderedBroadcast()發(fā)送）每次被發(fā)送到一個receiver。所謂有序，就是每個receiver執(zhí)行后可以傳播到下一個receiver，也可以完全中止傳播--不傳播給其他receiver。 而receiver運行的順序可以通過matched intent-filter 里面的android:priority來控制，當priority優(yōu)先級相同的時候，Receiver以任意的順序運行。

　　要注意的是，即使是Normal broadcasts，系統(tǒng)在某些情況下可能會恢復到一次傳播給一個receiver。 特別是receiver可能需要創(chuàng)建一個進程，為了避免系統(tǒng)超載，只能一次運行一個receiver。

　　Broadcast Receiver 并沒有提供可視化的界面來顯示廣播信息。可以使用Notification和Notification Manager來實現(xiàn)可視化的信息的界面，顯示廣播信息的內容，圖標及震動信息。

　　生命周期

　　一個BroadcastReceiver 對象只有在被調用onReceive(Context, Intent)的才有效的，當從該函數(shù)返回后，該對象就無效的了，結束生命周期。

　　因此從這個特征可以看出，在所調用的onReceive(Context, Intent)函數(shù)里，不能有過于耗時的操作，不能使用線程來執(zhí)行。對于耗時的操作，請start service來完成。因為當?shù)玫狡渌惒讲僮魉祷氐慕Y果時，BroadcastReceiver 可能已經無效了。

　　發(fā)送廣播

　　事件的廣播比較簡單，構建Intent對象，可調用sendBroadcast(Intent)方法將廣播發(fā)出。另外還有sendOrderedBroadcast()，sendStickyBroadcast()等方法，請查閱API Doc。

　　1.new Intent with action name

　　Intent intent = new Intent(String action);

　　或者 只是new Intent, 然后

　　intent.setAction(String action);

　　2.set data等準備好了后，in activity,

　　sendBroadcast(Intent); // 發(fā)送廣播

　　接收廣播

　　通過定義一個繼承BroadcastReceiver類來實現(xiàn)，繼承該類后覆蓋其onReceiver方法，并在該方法中響應事件。
  1. public class SMSReceiver extends BroadcastReceiver { 

  3.         @Override 
  4.         public void onReceive(Context context, Intent intent) { 
  5.                 // get data from SMS intent 
  6.                 Bundle bundle = intent.getExtras(); 
  7.                 if (bundle != null){ 
  8.                         // get message by "pdus" 
  9.                         Object[] objArray = (Object[]) bundle.get("pdus"); 

  11.                         // rebuild SMS 
  12.                         SmsMessage[] messages = new SmsMessage[objArray.length]; 
  13.                         for (int i=0; i < objArray.length; i++){ 
  14.                                 messages[i] = SmsMessage.createFromPdu((byte[])objArray[i]); 

  16.                                 StringBuilder str = new StringBuilder("from: "); 
  17.                                 str.append(messages[i].getDisplayOriginatingAddress()); 
  18.                                 str.append("\nmessage:\n"); 
  19.                                 str.append(messages[i].getDisplayMessageBody()); 

  21.                                 Toast.makeText(context, str.toString(), Toast.LENGTH_LONG) 
  22.                                                 .show(); 
  23.                         } 
  24.                 } 
  25.         } 
  26. }
復制代碼
　　注冊Receiver

　　注冊有兩種方式：

　　1. 靜態(tài)方式，在AndroidManifest.xml的application里面定義receiver并設置要接收的action。

  1. 　　<receiver android:name=".SMSReceiver">

  3. 　　<intent-filter>

  5. 　　<action android:name="android.provider.Telephony.SMS_RECEIVED" />

  7. 　　</intent-filter>

  9. 　　</receiver>
復制代碼
2. 動態(tài)方式, 在activity里面調用函數(shù)來注冊，和靜態(tài)的內容差不多。一個形參是receiver，另一個是IntentFilter，其中里面是要接收的action。
  1. public class HelloDemo extends Activity {    
  2.         private BroadcastReceiver receiver;    

  4.         @Override 
  5.         protected void onStart() { 
  6.                 super.onStart(); 

  8.                 receiver = new CallReceiver(); 
  9.                 registerReceiver(receiver, new IntentFilter("android.intent.action.PHONE_STATE")); 
  10.         } 

  12.         @Override 
  13.         protected void onStop() { 
  14.                 unregisterReceiver(receiver); 
  15.                 super.onStop(); 
  16.         } 
  17. }
復制代碼
　　一個receiver可以接收多個action的，即可以有多個intent-filter，需要在onReceive里面對intent.getAction(action name)進行判斷。

　　個人推薦使用靜態(tài)注冊方式，由系統(tǒng)來管理receiver，而且程序里的所有receiver，可以在xml里面一目了然。而動態(tài)注冊方式，隱藏在代碼中，比較難發(fā)現(xiàn)。

　　而且動態(tài)注冊，需要特別注意的是，在退出程序前要記得調用Context.unregisterReceiver()方法。一般在activity的onStart()里面進行注冊, onStop()里面進行注銷。官方提醒，如果在Activity.onResume()里面注冊了，就必須在Activity.onPause()注銷。

　　Permission權限

　　要接收某些action，需要在AndroidManifest.xml里面添加相應的permission。例如接收SMS:

  1. <uses-permission android:name="android.permission.RECEIVE_SMS" />
復制代碼
　　下面給出動態(tài)注冊的接收來電的廣播處理的CallReceiver的代碼：

　　一種方式是直接讀取intent.getStringExtra("incoming_number")來獲取來電號碼：

  1. public class CallReceiver extends BroadcastReceiver { 

  3.         @Override 
  4.         public void onReceive(Context context, Intent intent) { 
  5.                 TelephonyManager teleManager = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE); 
  6.                  
  7.                 switch(teleManager.getCallState()){ 
  8.                 case TelephonyManager.CALL_STATE_RINGING: //響鈴 
  9.                         Toast.makeText(context, "Ringing: " + intent.getStringExtra("incoming_number"), Toast.LENGTH_LONG).show(); 
  10.                         break; 
  11.                 case TelephonyManager.CALL_STATE_OFFHOOK: //接聽 
  12.                         Toast.makeText(context, "OffHook: " + intent.getStringExtra("incoming_number"), Toast.LENGTH_LONG).show(); 
  13.                         break; 
  14.                 case TelephonyManager.CALL_STATE_IDLE: //掛斷 
  15.                         Toast.makeText(m_context, "Idle: " + incomingNumber, Toast.LENGTH_LONG).show(); 
  16.                         break; 
  17.                 } 
  18.         } 
  19. }
復制代碼
　　在運行時，發(fā)現(xiàn)除了響鈴時可以獲取來電號碼，接聽和掛斷都不能成功獲取的，顯示為null。

　　另一種方式是通過PhoneStateListener的onCallStateChanged來監(jiān)聽狀態(tài)的變化：

  1. public class CallReceiver extends BroadcastReceiver { 

  3.         private Context m_context; 
  4.         @Override 
  5.         public void onReceive(Context context, Intent intent) { 
  6.                 m_context = context; 
  7.                 TelephonyManager teleManager = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE); 
  8.                 teleManager.listen(new PhoneStateListener(){ 

  10.                         @Override 
  11.                         public void onCallStateChanged(int state, String incomingNumber) { 
  12.                                 switch(state){ 
  13.                                 case TelephonyManager.CALL_STATE_RINGING: //響鈴 
  14.                                         Toast.makeText(m_context, "Ringing: " + incomingNumber, Toast.LENGTH_LONG) 
  15.                                                                 .show(); 
  16.                                         break; 
  17.                                 case TelephonyManager.CALL_STATE_OFFHOOK: //接聽 
  18.                                         Toast.makeText(m_context, "OffHook: " + incomingNumber, Toast.LENGTH_LONG) 
  19.                                         .show(); 
  20.                                         break; 
  21.                                 case TelephonyManager.CALL_STATE_IDLE: //掛斷 
  22.                                         Toast.makeText(m_context, "Idle: " + incomingNumber, Toast.LENGTH_LONG) 
  23.                                         .show(); 
  24.                                         break; 
  25.                                 } 
  26.                         }}, PhoneStateListener.LISTEN_CALL_STATE);  
  27.         } 
  28. }
復制代碼
　　運行時也發(fā)現(xiàn)incomingNumber在接聽和掛斷時獲取為blank。

　　因為這里監(jiān)聽的是通話的狀態(tài)變化，所以這個receiver會被調用3次。

　　監(jiān)聽通話狀態(tài)需要加上權限：

  1. <uses-permission android:name="android.permission.READ_PHONE_STATE"/>
復制代碼
　　===========

　　小結：

　　1. 對于sendBroadCast的intent對象，需要設置其action name；

　　2. 推薦使用顯式指明receiver，在配置文件AndroidManifest.xml指明；

　　3. 一個receiver可以接收多個action;

　　4. 每次接收廣播都會重新生成一個接收廣播的對象，再次調用onReceive；

　　5. 在BroadCast 中盡量不要處理太多邏輯問題，建議復雜的邏輯交給Activity 或者 Service 去處理。



--------------------------------------------
四、Content Provider詳解

　　ContentProvider（內容提供者）是Android中的四大組件之一。主要用于對外共享數(shù)據，也就是通過ContentProvider把應用中的數(shù)據共享給其他應用訪問，其他應用可以通過ContentProvider對指定應用中的數(shù)據進行操作。ContentProvider分為系統(tǒng)的和自定義的，系統(tǒng)的也就是例如聯(lián)系人，圖片等數(shù)據。

　　android中對數(shù)據操作包含有：

　　file, sqlite3, Preferences, ContectResolver與ContentProvider前三種數(shù)據操作方式都只是針對本應用內數(shù)據，程序不能通過這三種方法去操作別的應用內的數(shù)據。

　　android中提供ContectResolver與ContentProvider來操作別的應用程序的數(shù)據。

　　使用方式:

　　一個應用實現(xiàn)ContentProvider來提供內容給別的應用來操作，

　　一個應用通過ContentResolver來操作別的應用數(shù)據，當然在自己的應用中也可以。

　　以下這段是Google Doc中對ContentProvider的大致概述:

　　內容提供者將一些特定的應用程序數(shù)據供給其它應用程序使用。內容提供者繼承于ContentProvider 基類，為其它應用程序取用和存儲它管理的數(shù)據實現(xiàn)了一套標準方法。然而，應用程序并不直接調用這些方法，而是使用一個 ContentResolver 對象，調用它的方法作為替代。ContentResolver可以與任意內容提供者進行會話，與其合作來對所有相關交互通訊進行管理。

　　1.ContentProvider

　　Android提供了一些主要數(shù)據類型的ContentProvider，比如音頻、視頻、圖片和私人通訊錄等?？稍赼ndroid.provider包下面找到一些Android提供的ContentProvider。通過獲得這些ContentProvider可以查詢它們包含的數(shù)據，當然前提是已獲得適當?shù)淖x取權限。

　　主要方法：

　　public boolean onCreate() 在創(chuàng)建ContentProvider時調用
　　public Cursor query(Uri, String[], String, String[], String) 用于查詢指定Uri的ContentProvider，返回一個Cursor

　　public Uri insert(Uri, ContentValues) 用于添加數(shù)據到指定Uri的ContentProvider中

　　public int update(Uri, ContentValues, String, String[]) 用于更新指定Uri的ContentProvider中的數(shù)據

　　public int delete(Uri, String, String[]) 用于從指定Uri的ContentProvider中刪除數(shù)據

　　public String getType(Uri) 用于返回指定的Uri中的數(shù)據的MIME類型

　　*如果操作的數(shù)據屬于集合類型，那么MIME類型字符串應該以vnd.android.cursor.dir/開頭。

　　例如：要得到所有person記錄的Uri為content://contacts/person，那么返回的MIME類型字符串為"vnd.android.cursor.dir/person"。

　　*如果要操作的數(shù)據屬于非集合類型數(shù)據，那么MIME類型字符串應該以vnd.android.cursor.item/開頭。

　　例如：要得到id為10的person記錄的Uri為content://contacts/person/10，那么返回的MIME類型字符串應為"vnd.android.cursor.item/person"。

　　2.ContentResolver

　　當外部應用需要對ContentProvider中的數(shù)據進行添加、刪除、修改和查詢操作時，可以使用ContentResolver類來完成，要獲取ContentResolver對象，可以使用Context提供的getContentResolver()方法。

　　ContentResolver cr = getContentResolver();

　　ContentResolver提供的方法和ContentProvider提供的方法對應的有以下幾個方法。

　　public Uri insert(Uri uri, ContentValues values) 用于添加數(shù)據到指定Uri的ContentProvider中。

　　public int delete(Uri uri, String selection, String[] selectionArgs) 用于從指定Uri的ContentProvider中刪除數(shù)據。

　　public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) 用于更新指定Uri的ContentProvider中的數(shù)據。

　　public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) 用于查詢指定Uri的ContentProvider。



　　3.Uri

　　Uri指定了將要操作的ContentProvider，其實可以把一個Uri看作是一個網址，我們把Uri分為三部分。

　　第一部分是"content://"?？梢钥醋魇蔷W址中的"http://"。

　　第二部分是主機名或authority，用于唯一標識這個ContentProvider，外部應用需要根據這個標識來找到它?？梢钥醋魇蔷W址中的主機名，比如"blog.csdn.net"。

　　第三部分是路徑名，用來表示將要操作的數(shù)據?？梢钥醋骶W址中細分的內容路徑。

 
---------------------------------
本站僅提供存儲服務，所有內容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內容，請點擊舉報。
打開APP，閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
Android 學習筆記 之四大組件總結0
Android(經典實例)
android應用的基本組件
解析activity之間數(shù)據傳遞的方法
android中跨進程通訊的4種方式
深入理解Android組件間通信機制對面向對象特性的影響詳解
更多類似文章 >>
生活服務
分享 收藏 導長圖 關注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權！
如果VIP功能使用有故障，
可點擊這里聯(lián)系客服！

聯(lián)系客服