上次的文章中描述了 dailytick 的設計理念。經過兩周左右的設計和開發，現在 dailytick 的主要 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，這個只是完成了乙個樣子，但我感覺並不是很好用，可能在後面還會再改。
這裡，時間段拆分是有乙個 ui 的，我寫了乙個草稿，但沒有放上來。對於合併操作，可能只有確認的提示，不會有單獨的 ui。
統計頁裡，只有乙個webview，當然是乙個定製的webview，因為我需要在 c# 和 js 之間傳資料。這個hybridwebview的基礎實現已經實現出來了，不過要怎麼傳遞資料，還沒有想法。按照現在的初步設想，應該會使用 highchart.js 和 jquery 來完成統計頁的實現（並沒有什麼複雜互動，不想上 mvvm 的東西了）。主要就是報表和餅圖了。雖然我覺得餅圖其實意義有限，直接乙個 table 可以搞定很多任務作，但如果這個工具被擴散到非理科出身的人那裡（只是幻想一下），那麼統計圖就變成必不可少的東西了。
敏捷開發實錄 一
記錄一下敏捷開發的一些過程，因為沒有實實在在的走這個流程，新公司會按這個模式開發，自己也很有興趣，因為之前也帶了一年多專案，也曾深陷泥淖，所以很期待這個模式下的開發實踐帶來的效果。在迭代計畫會上，產品負責人講解迭代要開發的條目，團隊進行估算並放入下乙個迭代。在這產品負責人建立條目化的產品待開發項，並...
Android應用開發全程實錄
android應用開發全程實錄 內容上覆蓋了用android開發需要的大部分知識儲備。開發者通過本書的學習輕鬆開發出企業級的android應用。android應用開發全程實錄 以android各個元件應用為軸，系統地介紹了android開發的各個技術要點，如activity service broa...
pygame飛機大戰開發實錄3
通過之前的講解，了解了一些相關原理和基本的控制方法。接下來就可以開始編寫 飛機大戰 了。開始之前，先說一說，為什麼要以物件化程式設計，之前的例子裡的指令碼，都是以過程化編寫，而實際開發則以物件化為主。這裡把飛機移動的指令碼，按物件化重新編寫，右邊是原來的指令碼。乍一看，物件化好像要複雜一些。進一步觀...