分类目录归档:点点滴滴

点点滴滴便是点点和滴滴是也

近期Android开发经验积累

Android中实现动态更改控件尺寸

android中编写控件,通常我们采用XML格式的Layout文件来进行描述控件的大小和位置。当时某些时候我们还是很有必要在程序运行时更改控件的大小。

例如某些时刻程序执行时,控件关联数据发生改变可能导致控件对数据的呈现不能达到最佳,例如有两个ListView在当前窗体中,ListViewAListViewB分别对应两组数据,一组数据对应本月代码提交列表,另一组对应本月Bug修复列表。当两组数据相当之时(即数量相差无几),保持两个控件高度一致,可能两个ListView都会出现滚动条或者均不出现滚动条。但是当本月代码提交列表条目数远远超出本月Bug修复列表时(本月主要任务是新接口的设计和功能开发,其中包含Bug的开发,-_-!)。如果依然保持两个控件高度一致的话,那么显然对于用户来说是不友好的,此时用户的视觉焦点应该更多的是在代码提交列表,所以可以适当地增大代码提交列表的高度而减小Bug列表的高度。更有可能的设计中就存在选择某个视图的功能,例如切换到Bug列表视图时,需要将Bug列表高度扩展到全屏幕高度等等。

其实主要代码就几行,例如程序中是通过某个响应某个控件的某个事件来完成列表高度改变,例如通过单击某个按钮来改变某个列表的高度:

布局文件如下:

<?xml version=“1.0” encoding=“utf-8”?>

<LinearLayout xmlns:android=“http://schemas.android.com/apk/res/android”

android:orientation=“vertical” android:layout_width=“fill_parent”

android:layout_height=“fill_parent”>

<Button android:id=“@+id/change_view_size”

android:layout_width=“wrap_content”

android:layout_height=“wrap_content”

android:text=“ChangeSize” android:onClick=“onViewClick” />

<ImageView android:id=“@+id/logo” android:layout_width=“wrap_content”

android:layout_height=“wrap_content” android:src=“@drawable/logo”/>

<ListView android:id=“@+id/network_infos”

android:layout_width=“fill_parent”

android:layout_height=“wrap_content” />

<ListView android:id=“@+id/network_infos2”

android:layout_width=“fill_parent”

android:layout_height=“wrap_content” />

</LinearLayout>

关键代码如下:

public void onViewClick(View view){

// 单击ChangeSize按钮,改变列表高度

if(view == mChangeViewSize){

mNetInfoList.post(new Runnable() {

@Override

public void run() {

LinearLayout.LayoutParams params = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.FILL_PARENT, mNetInfoList.getHeight()/2);

mNetInfoList.setLayoutParams(params);

mNetInfoList.requestLayout();

}

});

}

}

使用线程避免出现ANR异常

Android中经常会出现ANR错误,因为经常性的Android桌面也会出现该问题,该问题主要是因为当前程序在5秒中内未能完成UI事件的响应,Android认为该程序已经进入了无响应状态,Android主动弹出一个提示框,提示用户是继续等待该程序还是将其强制关闭。

我们来看看Google I/O大会上的一个PPT中的分享:

ANRs (“Application Not Responding”)

ANRs happen when,

main thread (“event thread” / “UI thread”) doesn’t respond to

input event in 5 seconds,

a BroadcastReceiver doesn’t finish in 10 seconds

typically, when

doing network operations on main thread,

doing slow ‘disk’ operations (un-optimized SQL) on the main thread

那么防止这些问题的出现,很多时候都是需要使用线程来进行的,特别是连网的操作通常都是耗时的,而且极有可能出现连接超时的错误(国内的网络环境,你懂的)

还有就是某些有left join right join等的SQL查询也是有可能导致耗时过长的,可以尝试着使用AsyncQueryHandler类来实现异步查询。

另外一定要注意在BroadcastReceiver中的onReceive(Context context, Intent intent)方法中的操作时间不能超过10s,否则也可能出现ANR异常,那么如果觉得有可能触碰到临界值时还是选择使用线程吧

PS:之前一直以为Service是在自身独有的线程中执行的,直到最近才明白,其实并不是这样的。我们来看看官方的说明:

A Service is an application component representing either an application’s desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.

但是接下来的说明才是最重要的:

Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work. More information on this can be found in Application Fundamentals: Processes and Threads. The IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done.

这也就是说Service通常都是在主线程中执行的,也就是说我们通常在ServiceonCreate()onStart(Intent intent, int startId)方法中执行的操作如果耗时耗资源,那么就应该另起线程,或者选择IntentService来实现,因为IntentService拥有自己独有的线程来执行其操作。所以还是建议使用Service时一定要注意。

不要在线程内部使用TOAST

android中,我们通常会使用Toast来通知用户一些信息,例如网络出现异常等等,但是经过实践表明在线程中使用Toastshow()方法似乎是不可行的,因为Toast最终的所有显示操作应该都是处于UI主线程中,如果我们在子线程中做这样的操作,显然是违背了“只在主线程中刷新UI”的原则,不过由于Toast的特殊性,其抛出的异常跟在子线程中改变View控件的异常并不一致,其抛出的异常是你需要在使用handler之前通过Looper.prepare()方法来将当前线程作为一个looper,这显然是不对的。所以在线程中需要作任何UI操作,还是需要通过handler来通知主线程进行操作。

2010的尾巴又要没了

好像说不知不觉2011年已经开始冒头,2010已经见尾这样的话有点假。其实每一天都没有不知不觉,更别说每一年了。那么好吧,这有知有觉中,2011就要来了。据说是带着寒潮一起来的。

2010年同样有很多的第一次,现在开始计数:

  1. 第一次离职换工作
  2. 第一次换房子搬家
  3. 第一次连续两个月加班到12点(甚至以后)
  4. 第一次买超过一千块钱的手机,还是个Android手机
  5. 第一次更换开发平台
  6. 第一次买代理
  7. 第一次参加同事的婚礼
  8. 第一次开始同一部电影主动看两遍
  9. 第一次读库没有追着看
  10. 第一次在手机上看电子书,看了很多,古龙的小说看了有十本以上了

2010年同样有很多的遗憾,现在开始计数:

  1. 直到现在读库才读到1004
  2. 没能还掉09年管同学借的钱
  3. 没能给家里寄钱
  4. 没能写一个自己用的软件
  5. 没能持续写博客
  6. 没能持续购书并读书
  7. 没能每天按时睡觉
  8. 没能每天按时吃饭

2010年比较喜欢的电影有:

  1. 月满轩尼诗
  2. 教父(1,2,3)重看之后觉得很好
  3. 逍遥法外,同上
  4. 让子弹飞,很好
  5. 动作片依然很喜欢,有不少,不列举了,也记不住

2010年的扯淡就到此结束吧,2010年的收获目前还在积累,有很多,不知道如何说起。

我想我还是要回来的

博客停了将近两个月了,自打上次搬家到现在每天都在赶进度,确实挺忙的,不过再忙其实也还是需要生活下去的。

既然生命只有这么长,那么我们也不能老是抱怨自己命太短,时间太少,时间挤不出来的,有就是在那里,没有了,你管谁要也要不来,自己好好把握好分寸就一切皆宜了。生活是需要压力的,压力能积蓄力量,压力能强健筋骨,压力更是生活的主菜单,不论你将这菜单翻到多少页,只要你想吃生活这顿饭,那么压力总是必不可少。享受这份大餐吧,之后才会有甜美的甜点,犹如财富等等身外之物。

博客作为自己一个记录的载体,存在的时间也有一年之久了,回头看记录的东西不多,有价值的东西更是少之又少,看来还是很有必要思考一番,重新整理一下思路。不过我想我还是要回来的,不能置之不理。

搬家了!

十一长假结束后的两周里,真是挺折腾的,先是自家搬家,教主结婚请客吃饭,这周公司搬家,搞得挺累的,不过都还好,一切都非常顺利的完成了。希望接下来的一年里,一切都好,大家都平平安安的,开开心心的!博客更新频率太低了,之后还是要保持好一个不错的更新频率,需要加班了,呵呵!