個人知識管理系統Version1.0開發記錄（08）

標籤：android   style   blog   http   java   使用   

切入點

前面，我們已經搭建好了web端的一種基本結構，需要進一步定位的主要問題有三點：

1、介面的選擇和確定，用extjs做的初步樣式，進一步改動為jqueryUI/html，再進一步改變為HTML5等。我們思考一種使用者思維，只要有一個地方讓使用者不喜歡，使用者就會全盤否定該款軟體；所以，軟體介面一定要簡單、精緻、能引起使用者的興趣、符合使用者習慣和使用者思維。

2、架構的選擇和確定，struts2,hibernate/mybatis,spring等，在編寫知識體核心功能模組前，需要完成選擇和改寫。

3、方向的選擇和確定，每個人的時間、精力都是一定的，選擇一件事情，就需要先放棄其他很多事情；識時務者為俊傑，方向的選擇上，可以參考社會背景和商業需求、工作相關內容、個人成長情況等。方向的選擇至關重要，若是什麼都想學什麼都想做，只會迷失在知識的汪海大海之中，以致迷失自我、蹉跎歲月。學會專註，學會合作，學會溝通，自己不會的事務，不在自己知識體系主幹上的事務，找專業人士合作才是上策。建議常用紙筆：

（1）列舉出需要在做的功能模板，然後根據她們需要的知識來分析她們，哪些我們能做，我們需要學習去做，哪些需要我們做精做細；

（2）列舉模組優先順序，模組關聯，哪些需要先做，哪些可以建立關聯；

（3）哪些可以做個架子，然後找更專業的夥伴來做。

 

接下來，我們需要花費一段時間來做一個“串連功能模組”，以便切入到移動端，搭建移動端的一種基本結構。我們可以從以下幾方面來考慮：

（1）切入點，簡單、實用，是web端上的一個功能模組到app端上的一個功能模組的串連。

（2）資料可以互連，不論是介面不同還是資料庫不同，可以建立關聯，進行CRM管理。

（3）符合使用者習慣，具有商業價值。

 

只有想不到，沒有做不到。多看看廣告，電梯、地鐵、媒體新聞、車載電視、廣場廣告等，看看別人在做什麼，使用者群體在看什麼。先不考慮能否實現，我們來類比一個情境：

（1）我們在web介面加入一個功能模組，“聯絡我們”，有一些連絡方式和一個二維碼；

（2）使用者關注我們的號，我們通過公眾號擷取使用者基本資料、地理位置等；

（3）進行CRM管理，把使用者基本資料和本系統使用者基本資料形成關聯，用這個應用切入到移動端，開發各自獨立的（資料庫和軟體介面）、三者互相關聯的移動端軟體。至於收集這些資訊幹嘛用的，請諮詢商業夥伴。

 

不論對錯，日後再說。時間如梭，趕緊動手。思路如下：

 

1、在公眾平台查看API和一些協助資訊，大致看看怎麼玩的，需要什麼條件，需要注意什麼，可能用到什麼知識。是基於伺服器的資料轉送和處理。

 

2、編寫控制層。（1）使用者介面是，（2）使用者發送資訊到伺服器，（3）伺服器把資訊發送到我們編寫的控制層，（4）控制層接收資訊、處理資訊、發送處理資訊到伺服器，（5）伺服器把資訊發送給使用者。

 

3、使用者發送到伺服器的資訊，有文本、圖片、連結、地理位置、聲音、視頻；服務號發送到伺服器的資訊，有文本、圖片、連結、聲音、視頻。按照API上的資訊參數說明

，把她們封裝成對象。

 

4、資料交換格式是xml。控制層接收訊息，是把伺服器發送過來的xml轉換成java對象；控制層發送訊息，是把java轉換成xml發送到伺服器。使用dom和xstream。

 

5、開啟服務號“擷取使用者地理位置”，編寫一些業務處理邏輯，比如接收訊息、處理訊息、發送訊息。我們擷取使用者地理位置，並把這些資料原樣發送給使用者。

 

 

6、服務號自訂菜單，根據API編寫菜單對象，根據開發人員憑據產生自訂菜單。按鈕有兩種，click和view。

 

7、資料存放區。若只是即時處理資訊，可以把資料暫時儲存在記憶體；若是需要做CRM管理，並實現一些追溯功能，則要考慮使用資料庫。

 

8、不想用手機，不想讓服務號知道我們真實的地理位置，怎麼玩？那麼就要考慮，移動端地理位置資料來自哪裡？移動端系統。OK，下載android模擬器、GPS功能軟體、，設定地理位置為北京天安門。用模擬器登入，服務號向我們發送的是北京天安門的地理位置，因為她接收到的是這個地理位置。

 

      我們後面需要完成，（1）產生帶參二維碼，或者類似功能，（2）完善自訂菜單，（3）編寫能和使用者做一些基本互動的智能機器人，（4）追溯功能的實現，（5）資料互連的實現，為移動端的編寫開路搭橋。

      最近觀天下時事，冥冥中似乎察覺到了一絲命運的軌跡，其實，她一直都在我們的眼前，當我們開始懂她的時候，我們才看見她的存在，才發現她早已經等待了我們很久很久。OK，我們下次見。