问:尼玛Android 4.1Jelly Bean都发布了,你还bb2.3,坑爹呢,这是?
答:这个真不好意思了,屌丝的特点就是后知后觉。
问:那有何用?
答:可以很不负责任的说,从2.2以后launcher 拖拽流程基本没变化。
问:基本?那还是有变化,到底还是坑爹。
答:“爹,您硬了”。
-------------------------------------------------------------------------我是风格线--------
回归正题,要是做launcher的话,那拖拽事件处理、响应是必须得撸清楚的:
下面分步骤详细说明:
一,事件产生
拖拽事件的产生基于用户长按操作,分两种情况:
- 长按桌面(workspace视图)上的子视图(应用图标,文件夹,widget)事件响应是launcher.java
F2跳转之:
- 长按应用主菜单(AllAppGridView视图)上的子视图(应用图标)事件响应是AllAppGridView.java
该步骤的事件产生最终都定位mDragger.startDrag方法,顺着它往下摸就行了。
二,mDragger为何物?
mDragger是DragController实例,我们F3可以看到DragController其实就是一个接口,里面有几个很眼熟的抽象方法
F4一下可以知道该接口的唯一子类是DragLayer.java,必须进去一探究竟,尼玛这玩意竟然继承了frameLayout,脑子里有东西闪过,soga,原来是这样:
...........上面的代码就是launcher的主布局文件。DragLayer作为整个launcher的RootView负责所有拖拽事件的统一分发处理。因为launcher上能看到的组件都布局在它之上
为啥它是frameLayout,我就不罗嗦了。
当用户长按某一launcher组件时,DragLayer.startDrag会扯开嗓子通知那些相关组件做好接受拖拽事件的准备,并顺便悄悄的隐藏被拖拽图标的原始view。
三,既然已经跟到frameLayout视图,那么接下来应该是顺着触屏时序处理来看比较直观。
onInterceptTouchEvent作为触屏事件的节奏“打断者”在这里并没啥作为,只是在up时调用endDrag,用来在合适的时候显示刚才隐藏的view。老大不管事,那自然小弟抗大梁了。看看onTouchEvent是如何有条不紊的处理这些拖拽事件的。
在Action_move事件里要特别注意一下findDropTarget方法的实现,该事件会不断调用dropTarget的那几个抽象方法,只要是实现了该接口的view(userFolder,DeleteZone,workspace)都会根据特定的条件调用相应的重载方法,从而作出像文件夹开合,deleteZone变色等响应。
Action_up事件中咱们很熟练的F3,进了drop方法(太重要了,它决定了该拖拽事件最终的结果,是目标view接受了它还是拒绝都在这里都到裁决)。但代码其实很简短:
其实去年已经看这块了,怎奈人搓且奇懒无比,今天总算做个了结。