至此终于调用了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,不过项目差不多结束了,估计会转向其他的方向,有解决部分问题的朋友希望您回复一下,给其他读者作为参考.(我的邮箱shappy1978@sohu.com)