Add post menu on ListActivity, and ignoring post support

[WUGqnwvMQPzl]

在ListActivity的串中加上個菜單，可以不用點開串直接進行舉報操作，另外還可以永久屏蔽某個串，就像蘆葦島一樣

...不過我有個疑問，似乎用ContextMenu來做菜單會比彈出一個Dialog要更好些，但是我在嘗試給它加上菜單時，雖然菜單可以正常彈出，但是點擊事件的註冊似乎只會對縮略圖生效，點擊整個串並不會進入到詳情介面。不知道有什麼比較好的方法可以解決這個問題？

[seven332]

应该控制被屏蔽的串的数量，以避免可能出现的性能问题。譬如限制只能最多同时屏蔽100个串，用 LRU 的方式管理，匹配中一次就算使用一次。

而且如果某一页所有的串都被屏蔽了，加载会出现问题。

我不明白为何 ContextMenu 比 Dialog 要好些。在提交的代码中，我没看到 ContextMenu 相关的内容，所以无法判断点击事件失效是什么原因。

[WUGqnwvMQPzl]

這確實是個問題，畢竟島上沒有後端接口去處理這件事，只能在客戶端實現，多多少少還是會有些麻煩。不過我剛剛翻了下LRU的相關資料，似乎在圖像緩存上用得比較多（但這不是什麼問題），在下還不是特別明白比較進階方面的知識，這個用LRU管理具體是如何實現的？是通過LRUCache暫時把已屏蔽的串進行記錄嗎？

關於ContextMenu，我當時是參照網絡上的實例（例如這個）寫的，雖然菜單可以彈出，但是點擊事件似乎出了些毛病。

[seven332]

LRU 是个缓存淘汰策略，在很多地方都有使用。Android 中的也有实现，即 LruCache，但是在这个地方不能直接拿来用，场景不太一样，但是可以参考其实原理。就是将 LinkedHashMap 构造函数中 accessOrder 传入 true，使得 get(key) 调用后，被访问的节点放到了最后一个，而通过 Iterator 访问并不会影响排序。具体细节请查阅 LinkedHashMap 的源码。

针对目前的场景，由于将最大屏蔽数量设置为一个很小的值（假设为 100），不用考虑检查是否被屏蔽的效率。将所有被屏蔽的 id 存入一个 LinkedHashMap 中，key 为 id，value 为 null。检查时，通过 LinkedHashMap 的 Iterator 检查。若被屏蔽，调用 LinkedHashMap.get(id)，表示这个 id 被使用了。存储的话就有些麻烦了，我不确定 putStringSet() 是否能保证顺序，如果不行的话，就要用别的方式实现了。

ContextMenu 导致 点击无效是因为和 mRecyclerView.setOnItemClickListener 有冲突，改成在 ViewHolder 里添加 itemView.setOnClickListener 就行了。

[WUGqnwvMQPzl]

剛剛寫了個比較簡單的LRU緩存實現，測試了一下可以正常屏蔽串，不知道具體細節方面還有什麼需要修改。

最大屏蔽限制改成了閣下所指的100條串。

關於ContextMenu，或許我還得慢慢看，畢竟串列表中的RecylerView有兩個點擊事件要處理，一個是縮略圖，一個是整個View。如果能搞定這個問題，或許可以把所有涉及到彈Dialog的菜單改成ContextMenu，就是不知道用戶滿不滿意這一點。

[seven332]

我还是不理解为何 ContextMenu 优于 Dialog。Dialog 相比 ContextMenu 更能使用户关注选择。

[WUGqnwvMQPzl]

我还是不理解为何 ContextMenu 优于 Dialog。Dialog 相比 ContextMenu 更能使用户关注选择。

我也想了下還是維持現狀比較好，可能是我過於習慣蘆葦島的介面了，蘆葦島的長按菜單就是類似ContextMenu的實現。