移動社交之寫操作及展示的那些事

前言:本文寫的目的是介紹寫操作(例如:發微信,發朋友圈)遇到的問題,以及響應的解決方案,其中可能不是純技術方案,也會有一些產品的考慮.在移動網際網路時代,社交作為一個重要的領域被各家公司佔領.比如說IM+私密社交的微信,私信+公開社交的微博,還有其他一些垂直領域的的社交例如職場的脈脈,孕婦的寶寶樹,女生的大姨媽等等.

寫操作我把它分為2類:

1. 類似於微信,或者微博私信之類的有IM屬性的列表展示.

   一般是最新的資訊在最下邊展示,它會有狀態的顯示.傳送中,傳送成功,傳送失敗.

2. 類似於微信朋友圈,微博之類的社交屬性的列表展示.

   一般是最新的資訊在最上邊展示,它的展示就會根據產品的定義,有不同的展示形式了.不同的展示展示形式,會有對應的解決方案.

寫操作最終就是要展示.

那麼展示也分為2個方面

1. 展示給自己看
2. 展示給別人看
   展示給別人看,是最簡單的,只要你把內容發給伺服器.然後其他人通過請求把內容下載下來進行展示就OK了.
   展示給自己看,這個是最繁瑣的.因為他就會涉及到假資料的展示問題.

假資料的展示根據寫操作的分類也有不同:

1. IM屬性的列表.

   他需要把你輸入框中的資料,攢成一個假資料放到列表裡,然後在這條資料上有3種狀態.

   1.1 傳送中.需要用一些UI效果展示,比如說loding.

   1.2 傳送成功.不需要UI展示.

   1.3 傳送失敗.需要用UI效果標識,點選還能重發.

   如果你做的展示,不需要這3中狀態.那麼開發肯定的會非常高興.

2. 社交屬性的列表.

   用微博,以及微信舉例.

   以前的微博(現在的是會在自己的列表展示),自己發的文字,是不展示到自己的列表中的.他們會在後臺幫你傳送,這樣就不會設計到假資料的操作.

   微信,自己的發的文字,是會展示到自己的列表(當然是假資料),等傳送成功後,會顯示"刪除"2字.這樣你就可以對這條資料進行操作了.

   說了以上兩種列表的展示,除了不用假資料是最簡單的方式外,只要涉及到假資料,就會讓你的開發複雜度提高一個等級.下面我從技術方案上對假資料的展示,說一下自己的見解.

大概先介紹一下正常的流程.

編輯文字 ----> 假資料展示 ---->傳送到伺服器 ----->伺服器返回傳送狀態----->更新UI

其中2,3可以呼喚.或者並行.這個看你的設計方案.

一般這種流程問題會出現在假資料從傳送中到傳送結果的展示這一塊.

問題1.假資料怎麼展示?(傳送成功,傳送失敗)

問題2.怎麼讓伺服器返回的結果,準確的找到那一條假資料.

這兩個問題,我會用一種方式解決掉.就是localId,解釋一下就是每條資料都有有一個localId(假資料有,伺服器正常返回的資料無),這個localId是有一個命名規則的.
例如:"local_時間戳","failure_時間戳",時間戳就是當時的時間,就是簡單為了id唯一.傳送假資料到列表,你肯定會reloadData,那麼此時你需要判斷一下localid,

這樣就解決了你判斷狀態的難題.

那麼怎麼找到那條假資料呢?這是需要你在傳送時候把假資料的localid帶到request裡,然後等傳送成功或者失敗後,在通過這個localid找到這條假資料,更改響應的狀態.

這樣靠一個localid就完美的解決了傳送展示的問題.

下一篇文章,我會介紹在IM中如果傳送失敗,他的順序問題.