|
2011年8月3日
Activity啟動方式有四種,分別是:
standard singleTop singleTask singleInstance
可以根據實際的需求為Activity設置對應的啟動模式,從而可以避免創建大量重復的Activity等問題。
設置Activity的啟動模式,只需要在AndroidManifest.xml里對應的<activity>標簽設置android:launchMode屬性,例如:
- <activity
- android:name=".A1"
- android:launchMode="standard" />
下面是這四種模式的作用:standard 默認模式,可以不用寫配置。在這個模式下,都會默認創建一個新的實例。因此,在這種模式下,可以有多個相同的實例,也允許多個相同Activity疊加。例如:若我有一個Activity名為A1, 上面有一個按鈕可跳轉到A1。那么如果我點擊按鈕,便會新啟一個Activity A1疊在剛才的A1之上,再點擊,又會再新啟一個在它之上……點back鍵會依照棧順序依次退出。singleTop可以有多個實例,但是不允許多個相同Activity疊加。即,如果Activity在棧頂的時候,啟動相同的Activity,不會創建新的實例,而會調用其onNewIntent方法。例如:若我有兩個Activity名為B1,B2,兩個Activity內容功能完全相同,都有兩個按鈕可以跳到B1或者B2,唯一不同的是B1為standard,B2為singleTop。若我意圖打開的順序為B1->B2->B2,則實際打開的順序為B1->B2(后一次意圖打開B2,實際只調用了前一個的onNewIntent方法)若我意圖打開的順序為B1->B2->B1->B2,則實際打開的順序與意圖的一致,為B1->B2->B1->B2。singleTask只有一個實例。在同一個應用程序中啟動他的時候,若Activity不存在,則會在當前task創建一個新的實例,若存在,則會把task中在其之上的其它Activity destory掉并調用它的onNewIntent方法。如果是在別的應用程序中啟動它,則會新建一個task,并在該task中啟動這個Activity,singleTask允許別的Activity與其在一個task中共存,也就是說,如果我在這個singleTask的實例中再打開新的Activity,這個新的Activity還是會在singleTask的實例的task中。例如:若我的應用程序中有三個Activity,C1,C2,C3,三個Activity可互相啟動,其中C2為singleTask模式,那么,無論我在這個程序中如何點擊啟動,如:C1->C2->C3->C2->C3->C1-C2,C1,C3可能存在多個實例,但是C2只會存在一個,并且這三個Activity都在同一個task里面。但是C1->C2->C3->C2->C3->C1-C2,這樣的操作過程實際應該是如下這樣的,因為singleTask會把task中在其之上的其它Activity destory掉。操作:C1->C2 C1->C2->C3 C1->C2->C3->C2 C1->C2->C3->C2->C3->C1 C1->C2->C3->C2->C3->C1-C2實際:C1->C2 C1->C2->C3 C1->C2 C1->C2->C3->C1 C1->C2若是別的應用程序打開C2,則會新啟一個task。如別的應用Other中有一個activity,taskId為200,從它打開C2,則C2的taskIdI不會為200,例如C2的taskId為201,那么再從C2打開C1、C3,則C2、C3的taskId仍為201。注意:如果此時你點擊home,然后再打開Other,發現這時顯示的肯定會是Other應用中的內容,而不會是我們應用中的C1 C2 C3中的其中一個。singleInstance只有一個實例,并且這個實例獨立運行在一個task中,這個task只有這個實例,不允許有別的Activity存在。例如:程序有三個ActivityD1,D2,D3,三個Activity可互相啟動,其中D2為singleInstance模式。那么程序從D1開始運行,假設D1的taskId為200,那么從D1啟動D2時,D2會新啟動一個task,即D2與D1不在一個task中運行。假設D2的taskId為201,再從D2啟動D3時,D3的taskId為200,也就是說它被壓到了D1啟動的任務棧中。若是在別的應用程序打開D2,假設Other的taskId為200,打開D2,D2會新建一個task運行,假設它的taskId為201,那么如果這時再從D2啟動D1或者D3,則又會再創建一個task,因此,若操作步驟為other->D2->D1,這過程就涉及到了3個task了。
系統4.0.3以后的 File file=new File(""); Uri uri1 = Uri.fromFile(file); Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND); //intent.setType("audio/*"); intent.setType("application/octet-stream"); ComponentName comp=new ComponentName("com.mediatek.bluetooth","com.mediatek.bluetooth.BluetoothShareGatewayActivity"); intent.setComponent(comp); intent.putExtra(Intent.EXTRA_STREAM, uri1); startActivity(intent); 系統4.0.3以前的 Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND); //這個類型函數是自己工具類的方法,你可以自己設置文件類型,例如圖片文件:image/* //不想寫類型直接*/*也是可以的 intent.setType("audio/*"); //這里setClassName就是指定藍牙,不寫這句就彈出選擇用什么發送 //有藍牙啊,gmail啊,彩信之類的 intent.setClassName("com.android.bluetooth" , "com.android.bluetooth.opp.BluetoothOppLauncherActivity"); intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File(""))); startActivity(intent); ArrayList<Uri> uris = new ArrayList<Uri>(); uris.add(Uri.fromFile(new File("/sdcard/111.txt"))); uris.add(Uri.fromFile(new File("/sdcard/222.txt"))); Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND_MULTIPLE); intent.setType("video/*"); intent.setClassName("com.android.bluetooth" , "com.android.bluetooth.opp.BluetoothOppLauncherActivity"); //intent.setClassName("com.mediatek.bluetooth","com.mediatek.bluetooth.BluetoothShareGatewayActivity"); //intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("/sdcard/111.txt")) ); //intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("/sdcard/222.txt"))); intent.putExtra(Intent.EXTRA_STREAM, uris); startActivity(intent);
我們在頁面布局的時候,經常會設置容器的長度,但是到底該使用哪個作為長度的單位而懊惱。在Android中支持的描述大小區域的類型有以下幾種: px(pixels)——像素:不同的設備顯示效果相同,一般我們HVGA代表320x480像素,這個用的比較多。 dip(device independent pixels)——設備獨立像素:這個和設備硬件有關,一般我們為了支持WCGA、HVGA和QVGA推薦使用這個,不依賴于像素。等同于dp。 sp(scaled pixels—best for text size)——帶比例的像素。 pt(points)——磅:1pt = 1/72英寸 in(inches)——英寸 mm(millimeters)——毫米 到底px和dip有什么區別呢? dip != px 主要是針對不同設備而言的。在Density是160的設備上,比如用AVDManager創建的默認模擬器,dip和px是一樣的但是如果同樣的代碼,換到不同Density的設備上,比如換到一個Density是240的設備上,dip和px體現出來的大小就不一樣了。px不管在什么樣的設備上都是那樣長,但是dip會根據設備變化;WQVGA屏density=120;QVGA屏density=120;HVGA屏density=160;WVGA屏density=240;density值表示每英寸有多少個顯示點,與分辨率是兩個概念。
當屏幕density=240時使用hdpi標簽的資源 當屏幕density=160時,使用mdpi標簽的資源 當屏幕density=120時,使用ldpi標簽的資源。
不加任何標簽的資源是各種分辨率情況下共用的。布局時盡量使用單位dip,少使用px。
換算公式為: pixs =dips * (densityDpi/160). dips=(pixs*160)/densityDpi 如何獲得設備的屏幕分辨率和屏幕密度?
例如分辨率為480*800,密度為240的設備,方法如下DisplayMetrics dm =getResources().getDisplayMetrics(); dm.densityDpi=240 dm.widthPixels=480 dm.heightPixels=800
首先啟動android模擬器。 打開cmd命令行窗口。輸入adb -s emulator-5554 shell 此時可以管理系統文件夾了,再輸入ls 可以看到列出了文件夾和文件,輸入cd system/app再輸入ls 可以看到系統自帶的應用程序apk文件,刪除你想要刪除的,例如Phone.apk,輸入rm Phone.apk 此時會看到提示說rm failed for Phone.apk, Read-only file system那是因為這些是只讀文件,我們沒有權限刪除它。所以接下來要做的是獲取權限,首先查看權限,輸入mount 可以看到/dev/block/mtdblock0 /system yaffs2 ro 0 0說明在system這個地方我們沒有權限那么接下來我們就來獲取權限,輸入mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system 沒有提示錯誤,再次查看權限,輸入mount 可以看到/dev/block/mtdblock0 /system yaffs2 rw 0 0 說明我們已經獲取到權限了此時再輸入rm Phone.apk就可以成功刪除了
最后一點,就算你成功刪除了,android模擬器每次啟動時也會恢復回來。 那么如何永久刪除呢,很簡單,刪除SdkSetup.apk,輸入rm SdkSetup.apk 還沒完,找到avd目錄(一般在我的文檔),進入xxxx.avd目錄,刪除cache.img和userdata-qemu.img 還有還有,找到%SDK_HOME%/platforms/android-X/images/system.img,復制到上面的目錄中。 最后最后,再重啟模擬器,大功告成!
如果你的游戲不吃CPU,用View就比較好,符合標準Android操作方式,由系統決定刷新surface的時機。 但如果很不幸的,你做不到不讓你的程序吃CPU,你就只好使用SurfaceView來強制刷新surface了,不然系統的UI進程很可能搶不過你那些吃CPU的線程。 當然其實不止這兩種方法來刷新Surface的,這兩種只是純Java應用比較常見的方法。 SurfaceView和View最本質的區別在于,surfaceView是在一個新起的單獨線程中可以重新繪制畫面而View必須在UI的主線程中更新畫面。 那么在UI的主線程中更新畫面 可能會引發問題,比如你更新畫面的時間過長,那么你的主UI線程會被你正在畫的函數阻塞。那么將無法響應按鍵,觸屏等消息。 當使用surfaceView 由于是在新的線程中更新畫面所以不會阻塞你的UI主線程。但這也帶來了另外一個問題,就是事件同步。比如你觸屏了一下,你需要surfaceView中 thread處理,一般就需要有一個event queue的設計來保存touch event,這會稍稍復雜一點,因為涉及到線程同步。 所以基于以上,根據游戲特點,一般分成兩類。 1 被動更新畫面的。比如棋類,這種用view就好了。因為畫面的更新是依賴于 onTouch 來更新,可以直接使用 invalidate。 因為這種情況下,這一次Touch和下一次的Touch需要的時間比較長些,不會產生影響。 2 主動更新。比如一個人在一直跑動。這就需要一個單獨的thread不停的重繪人的狀態,避免阻塞main UI thread。所以顯然view不合適,需要surfaceView來控制。
android多國語言文件夾文件匯總如下: 中文(中國):values-zh-rCN 中文(臺灣):values-zh-rTW 中文(香港):values-zh-rHK 英語(美國):values-en-rUS 英語(英國):values-en-rGB 英文(澳大利亞):values-en-rAU 英文(加拿大):values-en-rCA 英文(愛爾蘭):values-en-rIE 英文(印度):values-en-rIN 英文(新西蘭):values-en-rNZ 英文(新加坡):values-en-rSG 英文(南非):values-en-rZA 阿拉伯文(埃及):values-ar-rEG 阿拉伯文(以色列):values-ar-rIL 保加利亞文: values-bg-rBG 加泰羅尼亞文:values-ca-rES 捷克文:values-cs-rCZ 丹麥文:values-da-rDK 德文(奧地利):values-de-rAT 德文(瑞士):values-de-rCH 德文(德國):values-de-rDE 德文(列支敦士登):values-de-rLI 希臘文:values-el-rGR 西班牙文(西班牙):values-es-rES 西班牙文(美國):values-es-rUS 芬蘭文(芬蘭):values-fi-rFI 法文(比利時):values-fr-rBE 法文(加拿大):values-fr-rCA 法文(瑞士):values-fr-rCH 法文(法國):values-fr-rFR 希伯來文:values-iw-rIL 印地文:values-hi-rIN 克羅里亞文:values-hr-rHR 匈牙利文:values-hu-rHU 印度尼西亞文:values-in-rID 意大利文(瑞士):values-it-rCH 意大利文(意大利):values-it-rIT 日文:values-ja-rJP 韓文:values-ko-rKR 立陶宛文:valueslt-rLT 拉脫維亞文:values-lv-rLV 挪威博克馬爾文:values-nb-rNO 荷蘭文(比利時):values-nl-BE 荷蘭文(荷蘭):values-nl-rNL 波蘭文:values-pl-rPL 葡萄牙文(巴西):values-pt-rBR 葡萄牙文(葡萄牙):values-pt-rPT 羅馬尼亞文:values-ro-rRO 俄文:values-ru-rRU 斯洛伐克文:values-sk-rSK 斯洛文尼亞文:values-sl-rSI 塞爾維亞文:values-sr-rRS 瑞典文:values-sv-rSE 泰文:values-th-rTH 塔加洛語:values-tl-rPH 土耳其文:values--r-rTR 烏克蘭文:values-uk-rUA 越南文:values-vi-rVN
Intent.FLAG_ACTIVITY_REORDER_TO_FRONT的意思是,如果task中已經有這個activity A,那么就把A拿到task的最頂層,而不是創建一個新的activity。
所以不加flag也不會影響界面的切過去,只是會影響task的順序而已。
Android:stackFromBottom="true" 設置該屬性之后你做好的列表就會顯示在列表的最下面,值為true和false android:transcriptMode="alwaysScroll" 要用ListView或者其它顯示大量Items的控件實時跟蹤或者查看信息,并且希望最新的條目可以自動滾動到可視范圍內。通過設置的控件 transcriptMode屬性可以將Android平臺的控件(支持ScrollBar)自動滑動到最底部。 c acheColorHint屬性,很多人希望能夠改變一下它的背景,使他能夠符合整體的UI設計,改變背景背很簡單只需要準備一張圖片然后指定屬性 android:background="@drawable/bg",不過當你這么做以后,發現背景是變了,但是當你拖動,或者點擊list空白位置的 時候發現ListItem都變成黑色的了,破壞了整體效果。 如果只是換背景的顏色的話,可以直接指定 android:cacheColorHint為你所要的顏色,如果你是用圖片做背景的話,那也只要將 android:cacheColorHint指定為透明(#00000000)就可以了 android:divider="@drawable/list_driver" 其中 @drawable/list_driver 是一個圖片資源,如果不想顯示分割線則只要設置為android:divider="@drawable/@null" 就可以了 android:scrollbars="none"與setVerticalScrollBarEnabled(true);的效果是一樣的,不活動的 時候隱藏,活動的時候也隱藏 android:fadeScrollbars="true" 配置ListView布局的時候,設置這個屬性為true就可以實現滾動條的自動隱藏和顯示。 fadingEdge屬性,上邊和下邊有黑色的陰影 android:fadingEdge="none" 設置后沒有陰影了 
<activity android:name=".usual.activity.Declaration" android:theme="@android:style/Theme.Translucent.NoTitleBar" />
1.背景自適應且不失真問題的存在 制作自適應背景圖片是UI開發的一個廣泛問題,也是界面設計師渴望解決的問題,我相信我們彼此都深有體會。 比如,列表的背景圖一定,但是列表的高度隨著列表數據項會發生變化;標題欄的背景,無論橫屏還是豎屏,高分辨率還是低分辨率,都能自動填充滿,而且不失真等等背景問題。 根據以往的經驗,我們一般采用先切圖后拼湊的做法,這種做法本來我想在這里和大家介紹一下,其實有的時候還是很有用的,但是說起來會比較麻煩,就不說這個非重點了,略去,如果大家真的要介紹,在回復中說明,我再考慮一下。 Android針對這種情況,專門制作了一種.9.PNG格式來解決這個問題。 2.9.PNG格式。 我不想在這里過多的討論PNG格式的定義問題。但是.9.PNG確實是標準的PNG格式,只是在最外面一圈額外增加1px的邊框,這個1px的邊框就是 用來定義圖片中可擴展的和靜態不變的區域。特別說明,left和top邊框中交叉部分是可拉伸部分,未選中部分是靜態區域部分。right和bottom 邊框中交叉部分則是內容部分(變相的相當于定義看一個內邊距,神似padding功能,后面我會單獨介紹一下),這個參數是可選的, 如下圖。
在Android中以9.PNG格式的圖片未背景,則能夠自定義拉伸而不失真,比如系統的Button就是一個典型的例子。 其實呢,無論是left和top,還是right和bottom都是把圖片分成9塊 (邊角四塊是不能縮放的,其他的四塊則是允許縮放的),所以叫做9.PNG。 3. 使用Draw9Patch.jar制作9.PNG圖片之定義拉伸區域。 前面已經了解到9.PNG格式的工作方式,下面我們使用谷歌提供的Draw9Patch(運行android-sdk-windows\tools目錄下的Draw9Patch.bat)來制作.9.PNG圖片。 第一步:準備要拉伸的圖片。  非常小的一張圖片,我希望以此為背景,中間部分填充文章內容。 第二步:制作.9.PNG圖片。 打開Draw9Patch,把圖片拖進去,如下:
 默認的拉伸是整體拉伸,其實邊框部分我們并不想拉伸,好,我們自己來定義拉伸區域,如下圖:
  然后點擊File,導出為content.9.png。 第三步:在layout文件中使用制作的 .9.PNG圖片. 新建工程Draw9Patch,默認主Activity為Draw9PatchActivity.java: 2 | public void onCreate(Bundle savedInstanceState) |
4 | super .onCreate(savedInstanceState); |
5 | setContentView(R.layout.main); |
我們把content.9.png文件拷貝到/res/drawable文件夾下,打開/res/layout目錄下的main.xml,申明如下: 01 | <? xml version = "1.0" encoding = "utf-8" ?> |
02 | < LinearLayout xmlns:android = " |
03 | android:orientation = "vertical" |
04 | android:layout_width = "fill_parent" |
05 | android:layout_height = "fill_parent" |
06 | android:background = "#777" |
07 | android:padding = "8dip" |
10 | android:layout_width = "fill_parent" |
11 | android:layout_height = "wrap_content" |
12 | android:text = "正文:A NinePatchDrawable graphic is a stretchable bitmap image." |
13 | android:background = "@drawable/content" |
14 | android:textColor = "#000" |
如圖,
 我們修改text, 01 | <? xml version = "1.0" encoding = "utf-8" ?> |
02 | < LinearLayout xmlns:android = " |
03 | android:orientation = "vertical" |
04 | android:layout_width = "fill_parent" |
05 | android:layout_height = "fill_parent" |
06 | android:background = "#777" |
07 | android:padding = "8dip" |
10 | android:layout_width = "fill_parent" |
11 | android:layout_height = "wrap_content" |
12 | android:text = " 正文:A NinePatchDrawable graphic is a stretchable bitmap image, which Android will automatically resize to accommodate the contents of the View in which you have placed it as the background. A NinePatch drawable is a standard PNG image that includes an extra 1-pixel-wide border." |
13 | android:background = "@drawable/content" |
14 | android:textColor = "#000" |
如圖,
 可以看出,邊框非常的清晰。下圖是未使用.9.PNG的對比圖,而且也不是我們要的效果: 到這里為止,我們已經基本會制作.9.PNG圖片了。為了知識體系的全面性和深入性,我們繼續。 4.使用Draw9Patch.jar制作9.PNG圖片之定義內容區域。 是不是覺得文字和邊距挨的太近,好,我們使用right和bottom邊的線來定義內容區域,來達到增大內邊距的目的。
 我們定義了一個很小的內容區域,其他的地方則自動充當邊框,從而使內邊距顯的很大,如下圖,
 在這里,我要特別說明,一開始為了增大內邊距,很容易慣性思維,在<TextView>中申明 android:padding="10dip" 之類的,我在這里勸告朋友們不要這么做,一是你將無法預知你的顯示,二是這比較混淆,因為設置內容區域就是確定padding,所以我在前面部分說他們是 神似。我個人認為通過內容區域設定padding比在布局xml中定義padding更優雅,更簡潔! 關于Draw9Patch工具的其他使用說明,我在次不再累述,因為要說的話太多,為了節省篇幅,請參考官方文檔。 5.制作.9.PNG的高級技巧。 對于初學Draw9Patch的人來說,這可以算是高級技巧,那就是:拉伸區域,可以不是連續的,可以不止一塊,而且是和自定義的邊框線的長度成正比。 直接上圖說明:
6.SDK中如何處理9.PNG圖片。 SDK專門針對9.PNG做了定義和處理,這里我們只是做個簡單的流程分析,Bitmap在讀取圖像流數據的時候,會把判斷圖片的 NinePatchChunk(9Patch數據塊),如果NinePatchChunk不為空,則是 NinePatchDrawable,NinePatchDrawable則又會交給NinePatch處理: 1 | setNinePatchState( new NinePatchState( |
2 | new NinePatch(bitmap, bitmap.getNinePatchChunk(), "XML 9-patch" ), |
NinePatch檢驗成功則調用本地方法,繪制出最終的圖片: 1 | nativeDraw(canvas.mNativeCanvas, location, |
2 | mBitmap.ni(), mChunk, paint != null ? paint.mNativePaint : 0 , |
3 | canvas.mDensity, mBitmap.mDensity); |
7.android系統中大量應用了9.PNG圖片。 通過解壓隨便一個rom,找到里面的framework_res.apk,里面有大量的9.PNG格式文件,被廣泛的應用起來,比如常見的有: 按鈕:  解鎖:  下拉框:  標題欄: Toast: 還有搜索,鍵盤,放大縮小控件,時間加減等等,我就不一一列舉。 8.最后送上一些圖例,以饗讀者,以做后鑒: 賞圖1 本人之作  賞圖2 下拉按鈕 賞圖3 文章頭部背景 賞圖4 系統頭部背景  轉載于 http://www.cnblogs.com/qianxudetianxia/archive/2011/04/17/2017591.html
方法一: Java代碼  - public void saveIcon(Bitmap icon) {
- if (icon == null) {
- return;
- }
-
- // 最終圖標要保存到瀏覽器的內部數據庫中,系統程序均保存為SQLite格式,Browser也不例外,因為圖片是二進制的所以使用字節數組存儲數據庫的
- // BLOB類型
- final ByteArrayOutputStream os = new ByteArrayOutputStream();
- // 將Bitmap壓縮成PNG編碼,質量為100%存儲
- icon.compress(Bitmap.CompressFormat.PNG, 100, os);
- // 構造SQLite的Content對象,這里也可以使用raw
- ContentValues values = new ContentValues();
- // 寫入數據庫的Browser.BookmarkColumns.TOUCH_ICON字段
- values.put(Browser.BookmarkColumns.TOUCH_ICON, os.toByteArray());
-
- DBUtil.update(....);//調用更新或者插入到數據庫的方法
- }
方法二:如果數據表入口時一個content:URI Java代碼  - import android.provider.MediaStore.Images.Media;
- import android.content.ContentValues;
- import java.io.OutputStream;
-
- // Save the name and description of an image in a ContentValues map.
- ContentValues values = new ContentValues(3);
- values.put(Media.DISPLAY_NAME, "road_trip_1");
- values.put(Media.DESCRIPTION, "Day 1, trip to Los Angeles");
- values.put(Media.MIME_TYPE, "image/jpeg");
-
- // Add a new record without the bitmap, but with the values just set.
- // insert() returns the URI of the new record.
- Uri uri = getContentResolver().insert(Media.EXTERNAL_CONTENT_URI, values);
-
- // Now get a handle to the file for that record, and save the data into it.
- // Here, sourceBitmap is a Bitmap object representing the file to save to the database.
- try {
- OutputStream outStream = getContentResolver().openOutputStream(uri);
- sourceBitmap.compress(Bitmap.CompressFormat.JPEG, 50, outStream);
- outStream.close();
- } catch (Exception e) {
- Log.e(TAG, "exception while writing image", e);
- }
1、成員變量(全局變量)命名首字母以m開頭第二個字母大寫;(e.g int mIndex = 0) 2、常量全部大寫 3、靜態的變量命名首字母以s開頭第二個字母大寫;(e.g static int sIndex = 0)
原文出自:http://blog.csdn.net/aa4790139/article/details/6754230 第一種情況: Proguard returned with error code 1. See console Error: C:/Documents (系統找不到指定文件) 后來發現是因為將整個工程放到了桌面上,而桌面的目錄是C:/Documents and Settings/Administrator/桌面,在這里面有空格,而proguard進行發編譯的時候是不允許有空格的 如果換了正確路徑還不好用的話,直接刪除proguard就好了 注意:SDK和程序路徑最好不要有空格符 第二種情況: Proguard returned with error code 1. See console 異常: java.lang.ArrayIndexOutOfBoundsException 解決辦法:將proguard.cfg中的"-dontpreverify"改成“-dontoptimize” 參考文章:http://groups.google.com/group/android-developers/browse_thread/thread/eca3b0f5ce6ad00f
建一個自己的博客,既可以練習php,mysql,還能了解一些網站基礎知識。好了現在我就吧自己建立玩站的過程寫下來,供大家參考!過程是漫長的,只有自己摸索,才能不斷增加經驗,才能自己解決問題! 首先我們得要個空間,這個空間是用來放網頁文件滴,其實網站就是一個文件夾,里面放了許多網頁,在靜態網頁中,當你用瀏覽器訪問這個文件時它會首先訪問index.html,自己動手做過的同學肯定知道,當你把別人網站拷下來的時候體會就明顯了,我就這么干的(好像很廢話)。 1.我前前后后申請了N多空間,不是空間太小,就是無法登陸,或者DNS解析不上,所以我推薦用www.simplefreeweb.com,完全免費滴,等一晚上就把賬號密碼發過來了,后臺有很多工具mysql,phpmyadmin等等(額- -!我忘了說一點,懂一點數據庫和php的同學上手快一些,因為你連數據庫,表都不知道,那出現問題你都不知道在哪里)。 2.注冊好能登陸的前提下,再到cn.wordpress.org下載他們的wordpress(這是別人做好的玩站模板,直接可用,里面是php文件如果你自己有自信比他做的好,或者練習php,那就自己做吧)解壓上傳到空間,上傳工具很多,我用的是filezilla,用www.simplefreeweb.com提供的ftp站好密碼,上傳到ftp里面的www目錄下,記住上傳wordpress文件下的文件,不要把wordpress文件夾一起傳上去,要不然你要訪問yourname.simplefreeweb.com/wordpress才能訪問。 3.上傳完成,用simplefreeweb給你的后臺登陸網址登陸,在里面建立數據庫,再向數據庫添加用戶的時候一定要勾選全部權限,要不然在后面wordpress安裝的時候會連接出現問題! 4.建立好數據庫后,登陸你的網站yourname.simplefreeweb.com,會出現wordpress安裝導向,按照步驟就可以啦! 5.yourname.simplefreeweb.com這個是人家的二級域名,既不個性,有很難記,所以我們得要個自己的。網上的頂級域名很多但價格不菲,而且申請麻煩,所以我建議到http://www.dot.tk申請,很方便! 綁定域名,就是將這個域名指向你的網站,方法主要是域名解析,免費的解析商也很多,很久都沒消息(我的就是,ywww.simplefreeweb.com自帶的解析不給力啊)。但是,tk里面有個域名跳轉,當你申請完后把你的yourname.simplefreeweb.com填進去,這樣當訪問你的域名,如我的www.liubos.k時候,直接跳到liubo.simplefreeweb.com。好處是方便,缺點是當別人訪問非主頁時,還是顯示原來的網址!又等一晚上!第二天再訪問自己的網站www.xxx.tk吧!說到xxx,我又邪惡了,呵呵!
摘要: android 使用contentobserver監聽數據庫內容變化在android中經常會用到改變數據庫內容后再去使用數據庫更新的內容,很多人會重新去query一遍,但是這樣的問題就是程序會特別占內存,而且有可能會摟關cursor而導致程序內存未釋放等等。其實android內部提供了一種ContentObserver的東西來監聽數據庫內容的變化。ContentObserver的構造函數需要一個參... 閱讀全文
最近有個需求,不去調用系統界面發送彩信功能。做過發送短信功能的同學可能第一反應是這樣: 不使用 StartActivity,像發短信那樣,調用一個類似于發短信的方法 SmsManager smsManager = SmsManager.getDefault(); smsManager.sendTextMessage(phoneCode, null, text, null, null); 可以實現嗎? 答案是否定的,因為android上根本就沒有提供發送彩信的接口,如果你想發送彩信,對不起,請調用系統彩信app界面,如下
Intent sendIntent = new Intent(Intent.ACTION_SEND, Uri.parse("mms://"));
sendIntent.setType("image/jpeg");
String url = "file://sdcard//tmpPhoto.jpg";
sendIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(url));
startActivity(Intent.createChooser(sendIntent, "MMS:"));
但是這種方法往往不能滿足我們的需求,能不能不調用系統界面,自己實現發送彩信呢?經過幾天的努力,終于找到了解決辦法。 第一步:先構造出你要發送的彩信內容,即構建一個pdu,需要用到以下幾個類,這些類都是從android源碼的MMS應用中mms.pdu包中copy出來的。你需要將pdu包中的所有類 都拷貝到你的工程中,然后自己酌情調通。 final SendReq sendRequest = new SendReq(); final PduBody pduBody = new PduBody(); final PduPart part = new PduPart();//存放附件,每個附件是一個part,如果添加多個附件,就想body中add多個part。 pduBody.addPart(partPdu); sendRequest.setBody(pduBody); final PduComposer composer = new PduComposer(ctx, sendRequest); final byte[] bytesToSend = composer.make(); //將彩信的內容以及主題等信息轉化成byte數組,準備通過http協議發送到 ”http://mmsc.monternet.com”; 第二步:發送彩信到彩信中心。 構建pdu的代碼:
String subject = "測試彩信";
String recipient = "接收彩信的號碼";//138xxxxxxx
final SendReq sendRequest = new SendReq();
final EncodedStringValue[] sub = EncodedStringValue.extract(subject);
if (sub != null && sub.length > 0) {
sendRequest.setSubject(sub[0]);
}
final EncodedStringValue[] phoneNumbers = EncodedStringValue.extract(recipient);
if (phoneNumbers != null && phoneNumbers.length > 0) {
sendRequest.addTo(phoneNumbers[0]);
}
final PduBody pduBody = new PduBody();
final PduPart part = new PduPart();
part.setName("sample".getBytes());
part.setContentType("image/png".getBytes());
String furl = "file://mnt/sdcard//1.jpg";
final PduPart partPdu = new PduPart();
partPdu.setCharset(CharacterSets.UTF_8);//UTF_16
partPdu.setName(part.getName());
partPdu.setContentType(part.getContentType());
partPdu.setDataUri(Uri.parse(furl));
pduBody.addPart(partPdu);
sendRequest.setBody(pduBody);
final PduComposer composer = new PduComposer(ctx, sendRequest);
final byte[] bytesToSend = composer.make();
Thread t = new Thread(new Runnable() {
@Override
public void run() {
try {
HttpConnectInterface.sendMMS(ctx, bytesToSend);
//
} catch (IOException e) {
e.printStackTrace();
}
}
});
t.start(); 發送pdu到彩信中心的代碼: public static String mmscUrl = "http://mmsc.monternet.com";
// public static String mmscUrl = "http://www.baidu.com/";
public static String mmsProxy = "10.0.0.172";
public static String mmsProt = "80";
private static String HDR_VALUE_ACCEPT_LANGUAGE = "";
// Definition for necessary HTTP headers.
private static final String HDR_KEY_ACCEPT = "Accept";
private static final String HDR_KEY_ACCEPT_LANGUAGE = "Accept-Language";
private static final String HDR_VALUE_ACCEPT =
"*/*, application/vnd.wap.mms-message, application/vnd.wap.sic";
public static byte[] sendMMS(Context context, byte[] pdu)throws IOException{
HDR_VALUE_ACCEPT_LANGUAGE = getHttpAcceptLanguage();
if (mmscUrl == null) {
throw new IllegalArgumentException("URL must not be null.");
}
HttpClient client = null;
try {
// Make sure to use a proxy which supports CONNECT.
client = HttpConnector.buileClient(context);
HttpPost post = new HttpPost(mmscUrl);
//mms PUD START
ByteArrayEntity entity = new ByteArrayEntity(pdu);
entity.setContentType("application/vnd.wap.mms-message");
post.setEntity(entity);
post.addHeader(HDR_KEY_ACCEPT, HDR_VALUE_ACCEPT);
post.addHeader(HDR_KEY_ACCEPT_LANGUAGE, HDR_VALUE_ACCEPT_LANGUAGE);
//mms PUD END
HttpParams params = client.getParams();
HttpProtocolParams.setContentCharset(params, "UTF-8");
HttpResponse response = client.execute(post);
LogUtility.showLog(tag, "111");
StatusLine status = response.getStatusLine();
LogUtility.showLog(tag, "status "+status.getStatusCode());
if (status.getStatusCode() != 200) { // HTTP 200 is not success.
LogUtility.showLog(tag, "!200");
throw new IOException("HTTP error: " + status.getReasonPhrase());
}
HttpEntity resentity = response.getEntity();
byte[] body = null;
if (resentity != null) {
try {
if (resentity.getContentLength() > 0) {
body = new byte[(int) resentity.getContentLength()];
DataInputStream dis = new DataInputStream(resentity.getContent());
try {
dis.readFully(body);
} finally {
try {
dis.close();
} catch (IOException e) {
Log.e(tag, "Error closing input stream: " + e.getMessage());
}
}
}
} finally {
if (entity != null) {
entity.consumeContent();
}
}
}
LogUtility.showLog(tag, "result:"+new String(body));
return body;
} catch (IllegalStateException e) {
LogUtility.showLog(tag, "",e);
// handleHttpConnectionException(e, mmscUrl);
} catch (IllegalArgumentException e) {
LogUtility.showLog(tag, "",e);
// handleHttpConnectionException(e, mmscUrl);
} catch (SocketException e) {
LogUtility.showLog(tag, "",e);
// handleHttpConnectionException(e, mmscUrl);
} catch (Exception e) {
LogUtility.showLog(tag, "",e);
//handleHttpConnectionException(e, mmscUrl);
} finally {
if (client != null) {
// client.;
}
}
return new byte[0];
} 至此,彩信的發送算是完成了。 總結:android的彩信相關操作都是沒有api的,包括彩信的讀取、發送、存儲。這些過程都是需要手動去完成的。想要弄懂這些過程,需要仔細閱讀android源碼中的mms這個app。還有就是去研究mmssms.db數據庫,因為彩信的讀取和存儲其實都是對mmssms.db這個數據庫的操作過程。而且因為這個是共享的數據庫,所以只能用ContentProvider這個組件去操作db。 總之,想要研究彩信這塊(包括普通短信),你就必須的研究mmssms.db的操作方法,多多了解每個表對應的哪個uri,每個uri能提供什么樣的操作,那些字段代表短信的那些屬性等。 最后推薦個好用的sqlite查看工具:SQLite Database Browser。
注意到在Activity的API中有大量的onXXXX形式的函數定義,除了我們前面用到的onCreate以外,還有onStart,onStop以及onPause等等。從字面上看,它們是一些事件回調,那么次序又是如何的呢?其實這種事情,自己做個實驗最明白不過了。在做這個實驗之前,我們先得找到在Android中的Log是如何輸出的。
顯然,我們要用的是android.util.log類,這個類相當的簡單易用,因為它提供的全是一些靜態方法:
Log.v(String tag, String msg); //VERBOSE
Log.d(String tag, String msg); //DEBUG
Log.i(String tag, String msg); //INFO
Log.w(String tag, String msg); //WARN
Log.e(String tag, String msg); //ERROR
前面的tag是由我們定義的一個標識,一般可以用“類名_方法名“來定義。 輸出的LOG信息,如果用Eclipse+ADT開發,在LogCat中就可以看到,否則用adb logcat也行,不過我是從來都依賴于IDE環境的。
好了,現在我們修改前面的HelloThree代碼:
public void onStart()
{
super.onStart();
Log.v(TAG,"onStart");
}
public void onStop()
{
super.onStop();
Log.v(TAG,"onStop");
}
public void onResume()
{
super.onResume();
Log.v(TAG,"onResume");
}
public void onRestart()
{
super.onRestart();
Log.v(TAG,"onReStart");
}
public void onPause()
{
super.onPause();
Log.v(TAG,"onPause");
}
public void onDestroy()
{
super.onDestroy();
Log.v(TAG,"onDestroy");
}
public void onFreeze(Bundle outState)
{
super.onFreeze(outState);
Log.v(TAG,"onFreeze");
} 在HelloThreeB中也同樣增加這樣的代碼,編譯,運行一下,從logcat中分析輸出的日志。 在啟動第一個界面Activity One時,它的次序是: onCreate (ONE) - onStart (ONE) - onResume(ONE) 雖然是第一次啟動,也要走一遍這個resume事件。然后,我們點goto跳到第二個Activity Two中(前一個沒有關閉),這時走的次序是: onFreeze(ONE) - onPause(ONE) - onCreate(TWO) - onStart(TWO) - onResume(TWO) - onStop(ONE) 說明,第二個Activity Two在啟動前,One會經歷一個:凍結、暫停的過程,在啟動Two后,One才會被停止? 然后,我們再點back回到第一個界面,這時走的次序是: onPause(TWO) - onActivityResult(ONE) - onStart(ONE) - onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO) 說明,返回時,Two沒有經歷凍結就直接暫停了,在One接收參數,重啟后,Two就停止并被銷毀了。 最后,我們點一下Exit退出應用,它的次序是: onPause(ONE) - onStop(ONE) - onDestroy(ONE) 說明如果我們用了finish的話,不會有freeze,但是仍會經歷pause - stop才被銷毀。
這里有點疑問的是:為什么回來時先是Start才是Restart?可是文檔中的圖上畫的卻是先restart再start的啊?不過,后面的表格中的描述好象是正確的,start后面總是跟著resume(如果是第一次)或者restart(如果原來被stop掉了,這種情況會在start與resume中插一個restart)。
下面不跑例子了,看看文檔吧。
1.Android用Activity Stack來管理多個Activity,所以呢,同一時刻只會有最頂上的那個Activity是處于active或者running狀態。其它的Activity都被壓在下面了。
2.如果非活動的Activity仍是可見的(即如果上面壓著的是一個非全屏的Activity或透明的Activity),它是處于paused狀態的。在系統內存不足的情況下,paused狀態的Activity是有可被系統殺掉的。只是不明白,如果它被干掉了,界面上的顯示又會變成什么模樣?看來下回有必要研究一下這種情況了。
3.幾個事件的配對可以比較清楚地理解它們的關系。Create與Destroy配成一對,叫entrie lifetime,在創建時分配資源,則在銷毀時釋放資源;往上一點還有Start與Stop一對,叫visible lifetime,表達的是可見與非可見這么一個過程;最頂上的就是Resume和Pause這一對了,叫foreground lifetime,表達的了是否處于激活狀態的過程。
4.因此,我們實現的Activity派生類,要重載兩個重要的方法:onCreate()進行初始化操作,onPause()保存當前操作的結果。
除了Activity Lifecycle以外,Android還有一個Process Lifecycle的說明:
在內存不足的時候,Android是會主動清理門戶的,那它又是如何判斷哪個process是可以清掉的呢?文檔中也提到了它的重要性排序:
1.最容易被清掉的是empty process,空進程是指那些沒有Activity與之綁定,也沒有任何應用程序組件(如Services或者IntentReceiver)與之綁定的進程,也就是說在這個process中沒有任何activity或者service之類的東西,它們僅僅是作為一個cache,在啟動新的Activity時可以提高速度。它們是會被優先清掉的。因此建議,我們的后臺操作,最好是作成Service的形式,也就是說應該在Activity中啟動一個Service去執行這些操作。
2.接下來就是background activity了,也就是被stop掉了那些activity所處的process,那些不可見的Activity被清掉的確是安全的,系統維持著一個LRU列表,多個處于background的activity都在這里面,系統可以根據LRU列表判斷哪些activity是可以被清掉的,以及其中哪一個應該是最先被清掉。不過,文檔中提到在這個已被清掉的Activity又被重新創建的時候,它的onCreate會被調用,參數就是onFreeze時的那個Bundle。不過這里有一點不明白的是,難道這個Activity被killed時,Android會幫它保留著這個Bundle嗎?
3.然后就輪到service process了,這是一個與Service綁定的進程,由startService方法啟動。雖然它們不為用戶所見,但一般是在處理一些長時間的操作(例如MP3的播放),系統會保護它,除非真的沒有內存可用了。
4.接著又輪到那些visible activity了,或者說visible process。前面也談到這個情況,被Paused的Activity也是有可能會被系統清掉,不過相對來說,它已經是處于一個比較安全的位置了。
5.最安全應該就是那個foreground activity了,不到迫不得已它是不會被清掉的。這種process不僅包括resume之后的activity,也包括那些onReceiveIntent之后的IntentReceiver實例。
在Android Application的生命周期的討論中,文檔也提到了一些需要注意的事項:因為Android應用程序的生存期并不是由應用本身直接控制的,而是由Android系統平臺進行管理的,所以,對于我們開發者而言,需要了解不同的組件Activity、Service和IntentReceiver的生命,切記的是:如果組件的選擇不當,很有可能系統會殺掉一個正在進行重要工作的進程。
|