本文轉(zhuǎn)載于郭霖大神的博客,點(diǎn)擊進(jìn)入原文。另文章末尾加上了一點(diǎn)自己的見解。
1. Dialog
首先來介紹一下Dialog的用法吧,其實(shí)很簡(jiǎn)單,相信大多數(shù)人都是經(jīng)常使用的:
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setTitle("Title")
.setMessage("Dialog content.")
.setPositiveButton("OK", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog,
int which) {
}
})
.setNegativeButton("Cancel", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog,
int which) {
}
})
.show();
這段代碼就可以彈出一個(gè)非常精美的Dialog了,如下圖所示:

現(xiàn)在這個(gè)Dialog是Material Design風(fēng)格的,因?yàn)槲沂窃?.0系統(tǒng)上運(yùn)行的,因此會(huì)自動(dòng)賦予這樣的風(fēng)格。但是如果在老版本系統(tǒng)上運(yùn)行,比如說2.3系統(tǒng),會(huì)是什么樣的效果呢?運(yùn)行一下就知道了,如下圖所示:

額。。這個(gè)效果就比較丑了,不過沒辦法,這就是2.3系統(tǒng)當(dāng)時(shí)的風(fēng)格呀。
人的審美總是在進(jìn)步的,我們有沒有什么辦法在老版本的系統(tǒng)中也使用Material Design風(fēng)格的Dialog呢?當(dāng)然有,Google已經(jīng)充分考慮到了這一點(diǎn),在appcompat-v7庫中也提供了一個(gè)AlertDialog類,完整路徑是:
android.support.v7.app.AlertDialog
我們使用這個(gè)包中的AlertDialog,就能讓對(duì)話框在所有的系統(tǒng)版本中都保持一致的風(fēng)格了。現(xiàn)在在2.3系統(tǒng)中重新運(yùn)行一下,效果如下所示:

可以看到,現(xiàn)在的效果就比較不錯(cuò)了,這也算是一個(gè)小技巧吧。
Dialog的作用是給用戶一個(gè)提示信息,并讓用戶根據(jù)提示做出判斷。而Dialog的特征就是,它會(huì)阻止你原本正在進(jìn)行的操作,必須停止下來對(duì)Dialog進(jìn)行處理。但是,大多數(shù)的人可能并不喜歡這樣被打斷,也許用戶正在處理一項(xiàng)重要的操作,突然彈出一個(gè)Dialog遮擋住了他原本的操作,這個(gè)時(shí)候用戶會(huì)變得很惱火。
因此,使用Dialog的時(shí)候還是謹(jǐn)慎一點(diǎn)比較好,盡量不要給用戶帶來糟糕的體驗(yàn)感。
2. Toast
說到不會(huì)阻擋用戶原本正在進(jìn)行的操作,這就延伸到我們今天的第二個(gè)主題,Toast。Toast只會(huì)彈出一段信息,告訴用戶某某事情已經(jīng)發(fā)生了,過一段時(shí)間后就會(huì)自動(dòng)消失。它完全不會(huì)阻擋用戶的任何操作,甚至用戶也可以完全不用理會(huì)Toast。
那么我們還是先來看一下Toast的基本用法吧,如下所示:
Toast.makeText(context, "things happened",
Toast.LENGTH_SHORT).show();
最后一個(gè)參數(shù)用于指定Toast顯示的時(shí)長(zhǎng),Toast.LENGTH_SHORT表示顯示時(shí)間較短,Toast.LENGTH_LONG表示顯示時(shí)間較長(zhǎng)。
不過也不是說Toast的用法就一點(diǎn)深度都沒有了,比如說上述的寫法就會(huì)存在如下圖所示的問題:

可以看到,這里我快速連續(xù)點(diǎn)擊了五次按鈕,Toast就觸發(fā)了五次。這樣的體驗(yàn)其實(shí)是不好的,因?yàn)橐苍S用戶是手抖了一下多點(diǎn)了幾次,導(dǎo)致Toast就長(zhǎng)時(shí)間關(guān)閉不掉了。又或者我們其實(shí)已在進(jìn)行其他操作了,應(yīng)該彈出新的Toast提示,而上一個(gè)Toast卻還沒顯示結(jié)束。
因此,最佳的做法是將Toast的調(diào)用封裝成一個(gè)接口,寫在一個(gè)公共的類當(dāng)中,如下所示:
public class Util {
private static Toast toast;
public static void showToast(Context context,
String content) {
if (toast == null) {
toast = Toast.makeText(context,
content,
Toast.LENGTH_SHORT);
} else {
toast.setText(content);
}
toast.show();
}
}
可以看到,這里和我們平時(shí)使用Toast的方式并不一樣,這里會(huì)先判斷Toast對(duì)象是否為空,如果是空的情況下才會(huì)調(diào)用makeText()方法來去生成一個(gè)Toast對(duì)象,否則就直接調(diào)用setText()方法來設(shè)置顯示的內(nèi)容,最后再調(diào)用show()方法將Toast顯示出來。由于不會(huì)每次調(diào)用的時(shí)候都生成新的Toast對(duì)象,因此剛才我們遇到的問題在這里就不會(huì)出現(xiàn)了。
調(diào)用的時(shí)候也很簡(jiǎn)單,只需要把Context對(duì)象和Toast要顯示的內(nèi)容傳進(jìn)來就可以了:
Util.showToast(context, "things happened");
現(xiàn)在我們?cè)僦匦逻\(yùn)行一遍程序,效果如下圖所示:

可以看到,現(xiàn)在不管我們觸發(fā)多少次Toast調(diào)用,都只會(huì)持續(xù)一次Toast顯示的時(shí)長(zhǎng),這也算是一個(gè)小技巧吧。
Toast的作用是告訴用戶現(xiàn)在發(fā)生了什么事情,不會(huì)阻擋用戶的操作,但同時(shí)用戶只能被動(dòng)接收這個(gè)事情,因?yàn)闆]有什么辦法來讓用戶是選擇同意還是拒絕。
雖說Toast在用戶體驗(yàn)方面要比Dialog好一些,但是也要慎用,尤其是涉及到一些敏感操作的時(shí)候。比如說刪除數(shù)據(jù),只給用戶一個(gè)提示:“你的數(shù)據(jù)已被刪除”,而不給用戶選擇是否要?jiǎng)h除的機(jī)會(huì),這個(gè)時(shí)候用戶可能就要暴走了。
3. Snackbar
如果說Dialog和Toast是兩個(gè)極端的話,那么Snackbar就是處于中間的位置了。Snackbar和Toast比較相似,但是用途更加廣泛,并且它是可以和用戶進(jìn)行交互的。Snackbar使用一個(gè)動(dòng)畫效果從屏幕的底部彈出來,過一段時(shí)間后也會(huì)自動(dòng)消失。
在使用Snackbar之前,首先需要在app/build.gradle中添加相應(yīng)的依賴:
dependencies { compile 'com.android.support:design:23.4.0' }
然后就可以使用Snackbar了,它的用法和Toast是比較相似的:
Snackbar.make(view, "data deleted",Snackbar.LENGTH_LONG)
.setAction("Undo", new View.OnClickListener(){
@Override
public void onClick(View v) {
}
})
.show();
這里調(diào)用Snackbar的make()方法來創(chuàng)建一個(gè)Snackbar對(duì)象,make()方法的第一個(gè)參數(shù)需要傳入一個(gè)view,只要是當(dāng)前界面布局的任意一個(gè)view都可以,Snackbar會(huì)使用這個(gè)view來自動(dòng)查找最外層的布局,用于展示Snackbar。第二個(gè)參數(shù)就是Snackbar中顯示的內(nèi)容,第三個(gè)參數(shù)是Snackbar顯示的時(shí)長(zhǎng)。這些和Toast都是類似的。
接著這里又調(diào)用了一個(gè)setAction()方法來設(shè)置一個(gè)動(dòng)作,從而讓Snackbar不僅僅是一個(gè)提示,而是可以和用戶進(jìn)行交互的。最后調(diào)用show()方法讓Snackbar顯示出來。
現(xiàn)在重新運(yùn)行一下程序,效果如下圖所示:

可以看到,Snackbar的效果有點(diǎn)類似于Toast,不過它是從屏幕底部彈出來的。另外Snackbar上面可以加入和用戶交互的按鈕,比如刪除數(shù)據(jù)的時(shí)候給用戶一個(gè)Undo的選項(xiàng),從這些小的細(xì)節(jié)方面都可以提升很多的用戶體驗(yàn)。
4. 總結(jié)
現(xiàn)在你有三種方式可以給用戶提示信息,Dialog、Toast和Snackbar,下面我們對(duì)這三種方式的使用時(shí)機(jī)做個(gè)總結(jié)吧。
Dialog:當(dāng)提示信息是至關(guān)重要的,并且必須要由用戶做出決定才能繼續(xù)的時(shí)候,使用Dialog。
Toast:當(dāng)提示信息只是告知用戶某個(gè)事情發(fā)生了,用戶不需要對(duì)這個(gè)事情做出響應(yīng)的時(shí)候,使用Toast。
Snackbar:以上兩者之外的任何其他場(chǎng)景,Snackbar可能會(huì)是你最好的選擇。
終于看到這里啦~ 使用原文中的彈出Toast的Util的時(shí)候,若是用戶只是重復(fù)點(diǎn)擊一個(gè)彈出Toast的Button(或其他的)是不會(huì)有什么異常,但當(dāng)用戶多次點(diǎn)擊不同的彈出Toast的Button(或其他的),最后那個(gè)Toast的內(nèi)容顯示的時(shí)間會(huì)變得很少。即當(dāng)前一定數(shù)量的點(diǎn)擊次數(shù)分享一個(gè)Toast的顯示時(shí)間。這樣“一閃而過”的提示帶來的體驗(yàn)也不好,可以將Util做修改,如下:
public class ToastUtil {
private static Toast toast;
public static void showToast(Context context, String content) {
if (content == null)
return;
// 判斷toast是否為空,空就新建否則取消當(dāng)前Toast
if (toast != null) {
toast.cancel();
}
toast = Toast.makeText(context, content, Toast.LENGTH_SHORT);
toast.show();
}
}
這個(gè)做法會(huì)每次新建一個(gè)Toast,但是保證了最后一個(gè)Toast的顯示時(shí)間。各有取舍吧有這樣需求的時(shí)候,這個(gè)也還是不錯(cuò)的
希望可以幫到你~