上次的文章中描述了 DailyTick 的設計理念。經過兩周左右的設計和開發，現在 DailyTick 的主要 UI 已經完成了原型的設計和初步的實現。既然是原型，當然看起來就有點粗糙。 主 UI 主 UI 是使用一個 實現的。一個用來記錄，一個用來統計。當然，最終的完成版應該至少有 3 個 Tab ...
上次的文章中描述了 DailyTick 的設計理念。經過兩周左右的設計和開發，現在 DailyTick 的主要 UI 已經完成了原型的設計和初步的實現。既然是原型，當然看起來就有點粗糙。
主 UI
主 UI 是使用一個 TabbedView 實現的。一個用來記錄，一個用來統計。當然，最終的完成版應該至少有 3 個 Tab，因為還需要有一個“設置”的 Tab。現在因為我還沒想到有什麼需要設置的，暫時沒有寫。在“記錄”這個 tab 里，有兩個組件：一個 ListView 和一個 NControl 寫成的圓形按鈕。使用的時候，只需要點一下下麵那個圓形按鈕，就可以形成一條記錄。當然，為了防止誤點，我這裡設置了一個限制，就是兩次點擊之間需要大於 1 分鐘。這帶來一個麻煩就是：你不能記錄小於 1 分鐘的事件。比如你想看看自己每天做時間記錄的過程消耗了多長時間，這個暫時辦不到。
上面這個列表，其實我還是有點擔心的：如果這個軟體可以被使用 10 年（應該不太可能，因為那個時候，應該會有比手機更好用的設備），按照我現在記錄的情況來看，一天大概有 30 條左右的記錄，一年是 365 * 30 = 10950 條，10 年就是 10 萬條，如果每天記錄得細點，可能就有幾十萬條，那會不會崩呢？雖然可以使用 Cell 的重用機制，不過也還是有點擔心。當然，比起 ListView 的性能問題，我更擔心的是記憶體夠不夠用。因為左邊那個時間顯示，並不是一個 Label。因為我的 UI 設計水平太差，所以我使用了 ListView 內置的 ImageCell，左邊那個是一個圖片。這個圖片是在記憶體里繪製出來，再使用 ImageSource.FromStream 載入的。所以不知道會不會消耗太多的記憶體。這裡可能是一個可以優化的點。
對事件/活動的修改
在記錄完一個活動/事件之後，需要記錄做了什麼事情，也就是一個事件/活動的主題，還需要給一個事件添加標簽，以便之後做統計。本來我想的是，使用 ListView 的 Context Menu 來實現的，但這東西有個問題，就是和 TabbedView 的左右滑動有衝突，所以怎麼也不能顯示 Context Menu。我只好放棄這個方案，使用了 DisplayActionSheet。結果，在 Android 上，就成了這個樣子。不是很美觀。當然，做為原型，也就先這樣好了。
雖然這裡寫了5個操作，但我現在只實現了 1.5 個。這個 1 就是：
好吧，我知道這個也有點醜（這也叫有點……）。功能很簡單，就是一個文本的編輯，然後再更新回原來的列表裡。另外的 0.5 個，是編輯 tag 的 page，這個只是完成了一個樣子，但我感覺並不是很好用，可能在後面還會再改。
按照我現在的設想，DailyTick 不會有其它時間記錄軟體那種編輯一個事件的開始時間、結束時間的功能，我提供的是把一個時間段進行拆分，或者把兩個時間段合併。這樣保證了一天的時間線是完整的，不存在“無記錄時間”這個東西。因為按照我對這個軟體的設計哲學，人是無法控制時間的，不管你怎麼使用自己的時間，時間本身都會不受控制的流走。所以，我們能做的，只是記錄自己在某一段時間里做了什麼。這裡可能有一個問題，需要在未來解決一下，就是在什麼地方體現我一天的日程安排，也就是 TODO 要記錄在哪兒的問題。
這裡，時間段拆分是有一個 UI 的，我寫了一個草稿，但沒有放上來。對於合併操作，可能只有確認的提示，不會有單獨的 UI。
統計 UI
統計頁里，只有一個 WebView，當然是一個定製的 WebView，因為我需要在 C# 和 JS 之間傳數據。這個 HybridWebView 的基礎實現已經實現出來了，不過要怎麼傳遞數據，還沒有想法。按照現在的初步設想，應該會使用 highchart.js 和 jQuery 來完成統計頁的實現（並沒有什麼複雜交互，不想上 MVVM 的東西了）。主要就是報表和餅圖了。雖然我覺得餅圖其實意義有限，直接一個 table 可以搞定很多工作，但如果這個工具被擴散到非理科出身的人那裡（只是幻想一下），那麼統計圖就變成必不可少的東西了。
當然，這一切都還只是原型，如果你有什麼對 UI 或者 UE 上的看法，歡迎在下麵留言，一起討論。也歡迎 star & fork 我的項目：https://github.com/holmescn/DailyTick
