Kuix的事件处理机制(沙地版) 2

至此终于调用了doLayout强制重新“布局”，根据revalidateAsSoonAsPossible的备注，这个函数就是为了方便开发者“强制”刷新界面所提供的，Kuix本身不调用这个函数，而使用场合恰好就是我碰到的这个场景。解决方案如下： 

 

	    	Kuix.getCanvas().revalidateAsSoonAsPossible();
	    	//恢复滚动条
			ScrollPane main=(ScrollPane)screen.getWidget("main");
			main.bestScrollToChild(screen.getWidget("selUserName"), false);	

 

案例二：下拉框的bug

    如果你使用了下拉框（choice），并且使用了Kuix的刷屏机制（如：transition: slide(left);），那么很容易发现下拉框的一个bug会导致系统当机，快速按确定键弹出下拉框并选择，那么用不了几下就会发现界面完全失去响应，死机了，而且下拉列表的项目“丢失”了若干项。造成上述bug的原因是缺少同步机制，输入按键的时候Kuix会把按键存入keyEvents，等待消息处理线程的处理，快速多次输入确认键导致上一次弹出/关闭列表窗口还没处理完毕，消息处理线程又再次操作列表，导致死机现象产生，最好的解决方法当然是在弹出列表时增加同步机制，但是我们不希望按键输入完毕后界面还在缓慢的多次弹出、关闭，简单说就是不需要缓存输入键，所以下面的解决方案可以快速解决上述bug：

 

	protected void processKeyEvent(byte type, int keyCode) {
		if (initialized) {
			
			int kuixKeyCode = adoptKeyCode(keyCode);
			
			// Intercept debugInfos key
			if (type == KuixConstants.KEY_RELEASED_EVENT_TYPE) {
				if ((debugInfosKuixKeyCode & kuixKeyCode) == kuixKeyCode) {
					debugInfosKeyCounter++;
					if (debugInfosKeyCounter >= 3) {
						initializer.processDebugInfosKeyEvent();
						debugInfosKeyCounter = 0;
					}
				} else {
					debugInfosKeyCounter = 0;
				}
			}
			
			// Add event to queue
			synchronized (this) {
				if(keyEvents.isEmpty()) //add by shappy
					keyEvents.addElement(new int[] { type, kuixKeyCode });
			}
			
		}
	}

 if(keyEvents.isEmpty())可以保证在有键盘事件未处理时，新的键盘输入被系统忽略。理论上这样的代码可能丢失输入

键，但是好在多数手机上没有键盘，而且Kuix也不支持直接输入文字，所以，就这样吧。

附，choice的按键处理函数，这里显然没有同步机制

 

	/* (non-Javadoc)
	 * @see org.kalmeo.kuix.widget.AbstractActionWidget#processActionEvent()
	 */
	public boolean processActionEvent() {
		Desktop desktop = Kuix.getCanvas().getDesktop();
		if (desktop != null) {
			
			if (lastSelectedRadioButton != null) {
				lastSelectedRadioButton.catchChildrenFrom(choiceContainer);
			}
			
			// Retrieve the owner screen instance
			ownerScreen = desktop.getCurrentScreen();
			
			// Keep the cleanUpWhenRemoved property value
			ownerScreenCleanUpWhenRemoved = ownerScreen.cleanUpWhenRemoved;
			ownerScreen.cleanUpWhenRemoved = false;
			
			desktop.setCurrentScreen(screen);
			
		}
		return super.processActionEvent();
	}

    有人说choice在tabgroup中才会出现上述问题,其实不是的,起码我在没有tabgroup的ui中确实出现过上述问题,而且
也不难测试,主要应该是transition的刷屏机制导致popup的窗口延迟才会出现问题,另外就是弹出窗口后返回原来的窗口是会出现choice的选择项丢失的情况,虽然代码里面强制给choice赋值可以保证下次提交是可以获取到choice的值(否则会是null),但是弹出时选择项还是空.

    Kuix的代码框架总体不错,但是小问题相当多,毕竟他是开源的框剪,作者的更新也相当慢,对中文的支持还不是很好,做了这几个月时间,给初学者的建议是,如果你没有决心去修改或者了解其源代码的话,建议还是不用它吧.另外列出它的几个问题,不是全部,只是随手写出来的,是没有解决或者完善解决的问题.

1 choice的长度超过一页时会显示滚动条,但是弹出列表时不会自动定位到当前选择项

2 在有滚动条,而且界面长度超过一页时,读取或者操作界面的某个widget时(很多时候是读取/修改某个列表),界面会自动滚动到最后.

3 实机测试似乎界面上所有的字体都是一样的,而不是可以用j2me的三种大中小的字体,但是wtk的模拟器上则可以,怀疑是kuix对中文字体支持不是很好

4 界面停滞现象,用线程连接服务器读取数据时,返回处理结果后弹出或者修改界面时,会出现界面停滞的情况,按任一按键或者鼠标可以马上恢复,否则需要等几秒时间,这一情况在模拟器上很少出现,实机比较多,没碰到的人估计很难理解我说的额情况,测试判断应该是线程同步问题导致,查询过程越慢越明显(因为我用上https通道加密后,这个现象会更明显),暂时没有完善的解决方案.

5 Kuix不支持直接输入,必须弹出标准输入窗口,这个其实不影响软件的功能,但是有时候挺煞风景的,而且不是kuix才有,其实有些开源的组件部分解决这个问题,应该说它必须解决两个问题,一个是kuix的布局问题(kuix的界面是运行时排版的,这可以解决不同分辨率的自适应问题),还有一个问题是解决输入法,你不仅必须接收特殊字符,还要接收汉字,而且最好支持手写输入,这是个大问题

6 滚动条问题,kuix滚动条默认是纵向的,其实它也支持横向滚动条,但是只能选择其中一种,作者不同时支持两种方向的滚动条估计和布局的缺陷有关.

7 不支持本地script,kuix把view独立开确实是方便用户编写界面,但是缺少客户端的脚本判断,这限制了软件的灵活性,比如说我在登录前必须判断用户的账户和密码不为空并提示用户,就必须把代码写死在客户端,所以必须引入客户端的脚本机制,这样Kuix才不失为一个完善的瘦客户端开发组件,另外,结合客户端脚本功能时,最好提供封装好的服务器连接组件,方便客户端的调用.

    问题很多,但其实只是其中很小一部分,希望没吓到希望学习Kuix的人,以后有时间解决其中部分问题的话我会陆续发表一些blog,不过项目差不多结束了,估计会转向其他的方向,有解决部分问题的朋友希望您回复一下,给其他读者作为参考.(我的邮箱[email protected])