《101 Windows Phone 7 Apps》讀書筆記-BABY NAME ELIMINATOR

課程內容

Ø本機資料庫

Ø在應用程式中處理資料

 

    Baby Name Eliminator是一種通過輸入性格特徵而擷取嬰兒名字的應用程式（我和我的妻子用這種方法來為兩個兒子取名字）。與採用頭腦風暴的方式取名字、而後又擔心錯過了最好的名字不同，本應用程式使得我們利用淘汰法為嬰兒取名。

    Baby Name Eliminator建立在一個巨大的資料庫之上，它存放了美國範圍內使用的36,065個男孩名字和60,438個女孩名字。在我們選定性別以後，應用程式會使用多種過濾器來縮小名字列表。這些過濾器建立在以下幾個因素的基礎之上：每個名字的受歡迎程度、名字的開頭和結束字母以及該名字首次使用的時間。一旦對列表進行過濾之後，我們就可以一個個得對名字進行排除，直到做出最後的選擇。

    在為孩子取名字時，我們會進行多次考慮，排除那些明顯不好的，留下我們猶豫不決的。在我們靜下心來對待20個可選擇的名字時，我和妻子各自選擇認為最好的5個。對於第一個兒子，我們選取了共同的名字，所以就這樣下了最後的決定。如果你和妻子都有Windows Phone手機，那麼各自選擇名字、直到列出候選名單，這種方式將非常有趣。

    那麼，這個名字資料庫從何而來呢？答案是社會安全域，它可以提供1880年以來幾乎每個社會安全卡上的姓名。這張表有幾點需要說明：

➔ 出於隱私的原因，只包含給定年份中使用5次以上的名字。

➔ 單個字元的名字不包括在內。

➔ 1937年之前出生的許多人沒有社會安全卡，所以那些年的資料不全。

➔ 相同名字的不同拼字被視為不同的名字。

➔ 資料未經加工，也未經排錯。有時候申請表上的性別是錯誤的，導致女孩名字列表上出現男孩子的名字，同時相反的情況也存在。除此之外，一些名字被記錄為“未知”，“未命名”，或者是“嬰兒”。這些情況可以通過限制列表的前1000個名字來解決。

    為使能這種過濾，本應用程式利用了兩個本機資料庫-一個存放男孩名字，另一個存放女孩的名字。

 

Working with Local Databases

    Windows Phone 7缺少對本機資料庫的支援是其公認的缺點之一。鼓勵應用程式與伺服器端的資料庫配合工作，但是這對於開發人員來說會引入額外的負擔，對於使用者來說會帶來更多的麻煩（延時，資料連線，潛在的資料流量成本）。幸運的是，我們可以選擇第三方資料庫。我最喜歡的是開源的SQLite for Windows Phone 7，它由Dan Ciprian Ardelean所建立。我們可以在以下網頁中進行查看：http://sviluppomobile.blogspot.com/2010/03/sqlite-for-wp-7-series-proof-of-concept.html。並通過以下連結擷取最新的版本：http://www.neologics.eu/Dan/WP7_Sqlite_20.09.2010.zip。它包含了C#原始碼和一個Community.CsharpSqlite.WP.dll檔案，我們可以在工程中對它進行引用。它當然不可能沒有缺陷，但是在多數情況下它都工作得非常好（比如本應用程式）。

    SQLite for Windows Phone 7從隔離儲存空間中讀取或者寫入資料庫檔案。如果我們想要把填充好資料的資料庫和應用程式一起部署，我們可以將資料庫檔案包含到工程中，並且把Build Action設定為Content。在運行時，第一次使用SQLite之前，我們的應用程式擷取檔案，並把它儲存到隔離儲存空間中。在工程中要以內容的方式訪問檔案，我們可以調用Application. GetResourceStream。

如何建立一個隨應用程式部署的包含資料庫的.bd檔案？

   以下就是在Windows Phone應用程式中的方法：

1. 執行CREATE TABLE和INSERT命令，使用SQLite產生一個資料庫。

2. 利用隔離儲存空間的API，擷取SQLite儲存到隔離儲存空間中的.db檔案的未經處理資料。

3. 從Visual Studio debugger拷貝字元資料作為Base64編碼的字串，使用另外的（案頭）程式解碼，將它們儲存到需要的.db檔案中。

注意：

➔ 在執行大量的資料庫操作時，為了使得使用者介面可響應，與SQLite的互動是通過BackgroundWorker的後台線程來完成的，通過回呼函數來擷取成功/失敗資訊。

➔ 傳遞給ExecuteScalar和ExecuteQuery的命令字串可以是SQL命令，比如：SELECT COUNT(*) FROM table

➔ ExecuteQuery是一個通用的方法，其通用參數T必須是一個類，且具有一個與查詢中選擇的列相一致的屬性。

    Application.GetResourceStream與工程中包含的檔案配合工作，檔案的Build Action設定為Content，或者Build Action設定為Resource。對於後者，傳入的URI必須符合下面的文法：/dllName;component/pathAndFilename

    注意，dllName可以引用.xap檔案中的任何dll，只要它包含需要的資源。但是，不能包含dll尾碼。

    對於本應用，位於工程根目錄的男孩名字資料庫（Boys.db）的DatabaseName字串如下所示，

    /WindowsPhoneApp;component/Boys.db

    但是，如果這樣的話，列表24.1使用的SaveFile就必須更改，因為DatabaseName字串對於隔離儲存空間來說，不再是一個有效檔案名稱。

 

Application.GetResourceStream與Assembly.GetManifestResourceStream

    我們可能偶然發現Assembly.GetManifestResourceStream API是作為讀取包含在應用中的檔案的方法。這樣是可行的，但是僅僅限於那些Build Action設定為 Embedded Resource的檔案（而不是設定為Resource）。

    但是，傳遞給GetManifestResourceStream的字串具有它獨特的文法：dllName.filename中dllName是包含embedded resource的DLL的名字。那是因為在命名每個embedded resource 時，C#編譯器自動將DLL名字（減去.dll副檔名）前置到檔案名稱中（你可以通過諸如.NET Reflector工具來開啟DLL查看名字）。本應用中，兩個有效字串是“WindowsPhoneApp.Boys.db”和“WindowsPhoneApp.Girls.db”。

    相對於這種方法來說，Application.GetResourceStream更加靈活。與其他那些將檔案作為嵌入式資源的機制相比，使用作為內容方式檔案的GetResourceStream方法更加受人歡迎，因為資源會增加DLL檔案的大小，並且那樣會增加應用程式的載入時間。

 

The Filter Page

    我們可以通過瀏覽包含的原始碼來查看應用程式的首頁面，但我們首先要查看利用DatabaseHelper類的過濾頁面。過濾頁面24.1所示，顯示了列表中有多少個名字，然後，我們能夠利用一些選項來過濾它，這些選項可以映射為SQL查詢命令，並作用在資料庫上（男孩與女孩名字在之前的首頁面上進行選擇）。

圖24.1

    24.2所示，每個按鈕會揭示一個新的視窗或者頁面，那使得使用者可以控制每個相關的過濾條件。點擊名字的數量會揭示真實名字的列表，24.3所示。該列表不能進行互動排除，但是，那可以在首頁面中來完成。

圖24.2

圖24.3

注意：

➔ 點擊按鈕時彈出的對話方塊是由Dialog使用者控制項所建立的，這可以在應用程式的原始碼中看到。字幕的網格由LetterGrid使用者控制項所建立。這裡的網格與第18章“Cocktails”中的QuickJumpGrid控制項很類似。

➔ 5個過濾按鈕是toggle類型的，它們的IsChecked狀態由背後的代碼來管理。如果一條過濾條件被啟用，它相關的按鈕會被檢查（高亮），使得使用者可以在不用點擊每個按鈕的情況下看到它，也不用對其過濾條件進行雙重檢查。

➔ 在後台線程執行查詢時，進度條和它相關的使用者介面會顯示出來，24.4所示。因為它不會佔據整個螢幕，所以如果使用者不在意等待當前名字的話，它允許使用者繼續工作。

➔本工程包含了兩個資料庫（Boys.db 和Girls.db），它們具有相同的模式。它們只包含一張名為Names表，該表具有三個列：Name，BestRank（它單個年份中最好的排名）和FirstYear（在社會安全資料庫中首次出現的年份）。

➔ 重新整理名字數量的查詢命令為“SELECT COUNT(*) FROM Names”，它可以具有WHERE子句，它們建立在那些由過濾法則決定的設定之上。

➔ 顯示真實名字的查詢命令為“SELECT Name FROM Names”，它同樣可以具有WHERE子句。因此，與ExecuteQuery 一同使用的Record類具有單字串的Name屬性。ToString方法允許Record集合可以作為沒有任何資料範本的list box預覽的資料來源，因為text block中內建的ToString已經足夠。

➔正如前一章中的date picker一樣，本應用對每個字元選擇都使用雙向資料繫結。