1、参考文档安卓学习心得体会精选多篇范文模板 13页本文部分内容来自网络整理,本司不为其真实性负责,如有异议或侵权请及时联系,本司将立即删除!= 本文为word格式,下载后可方便编辑和修改! = 安卓学习心得体会(精选多篇)第一篇:安卓学习心得android学习心得-093380117计算机应用(1)张峰1.关于activity1. 在一个activity中使用多个view如果把activity看作mvc中的control?它负责管理ui和接受事件(包括用户的输入),虽然说一个activity通常对应一个屏幕,但事实上,我们是可以只用一个activity管理多个不同的view来实现简单的逻辑。 首
2、先,我们增加一个新的资源描述layout/second.xml。除了一个“hello中国”以外,增加一个按钮可以返回前一个界面。然后,在代码中我们要为hellotwo增加两个方法,setviewonecommand和setviewtwocommand,分别处理一下在不同界面时,从资源里加载组件并为组件绑定一个事件处理器最后,我们需要在oncreate的时候,也就是启动后的main界面上设置一下按钮事件处理器。 2. 还是回到正道上,多个activity之间的跳转android中提供一个叫intent的类来实现屏幕之间的跳转,按文档的说法,似乎他们也建议采用这种方法,intent的用法比较复杂,
3、现在我先看看它最简单的用法。这里的跳转功能用intent来操作,它的最简单用法就是用函数setclass()设置跳转前后两个activity类的实例,然后调用activity自己的startactivity(intent)即可。最后一句finish()表示将当前activity关掉(如果不关掉会如何?你可以自己试一下看效果,事实上有时我们是不需要关掉当前activity的)。 然后,我们同样弄一个activity类hellothreeb,代码与前面的差不多,只是将setclass的两个参数反一下,这样就可以简单地实现在两个activity界面中来回切换的功能了。2.关于 intent的使用in
4、tent分为两大类,显性的(explicit )和隐性的(implicit)。一般来说,intent要定位事件的目的地,无外乎需要以下几个 信息 : 1.种类(category),比如我们常见的 launcher_category 就是表示这是一类应用程序。2.类型(type),在前面的例子中没用过,表示数据的类型,这是隐性intent定位目标的重要依据。3.组件(component),前面的例子中用的是setclass,不过也可以用setcomponent来设置intent跳转的前后两个类实例。4.附加数据(extras),在contenturi之外还可以附加一些信息,它是bundle类型的
5、对象。其实,如果是在一个应用内部,这种隐性的intent实在有点别扭,个人觉得,这种松藕合的实现方法,只适用于那些较大的系统或者多个不同的应用之间的调用,可手机上又有什么“较大”的系统呢?无非是可以与不同来源的多个应用之间方便地互操作而已,那么会是什么样的场景呢?比如,给qq好友发送gmail邮件,用googlemap查找qq好友所在的位置?看上去挺不错的。 关于这个contentprovider,其实还有话说,它主要是的那些看似数据库操作的方法我们都没真正去实现呢。不过今天就到这里了,等下回再去研究吧。3.关于listactivity准备一个list对象并借助adapter就可以构造出一个列
6、表。重载onlistitemclick方法可以响应选择事件,利用第一个参数可以访问到这个listview实例以得到选中的条目信息。这里有一点要说明的,就是如果更简单的话,其实连那个setcontentview都可以不要了,android也会自动帮我们构造出一个全屏的列表。但是本例中我们需要一个textview来显示选中的条目,所以我们需要一个layout.mainb描述一下这个列表窗口。 这里需要注意的是那个listview的id,是系统自定义的android:list,不是我们随便取的,否则系统会说找不到它想要的listview了。然后,在这个listview之外,我们又增加了一个textv
7、iew,用来显示选中的条目。 再来说说这里用到的arrayadapter,它的构造函数中第二个参数是一个资源id,arrayadapter的api文档中说是要求用一个包含textview的layout文件,平台用它来显示每个选择条目的样式,这里的取值是r.layout.list_row,所以,我们还有一个list_row.xml文件来描述这个布局,相当简单。 从arrayadapter上溯到baseadapter,发现还有几个同源的adapter也应该可以使用,象simpleadapter和cursoradapter,还是做个例子来实验一下吧。然后,在hellotw(请你继续关注:)ob中的o
8、ncreate函数中,修改代码,有几个不同:items的元素是hashmap实例,这是一点变化,然后构造函数除了要求items以外,还要求提供一个string来说明用hash表中的哪个字段显示在列表中,而后是一个资源id的数组。 因为单纯的cursoradapter是抽象类,所以我用的是它的子类simplecursoradapter,很好理解,先用contentresolver查询通讯簿得到一个游标,然后告诉simplecursoradapter要用其中的people.name作为显示项来构造出一个adapter即可。 4.关于dialog注意到android.app包下除了dialog(可用
9、于制作复杂的对话框)以外,还包括了几个系统定义好的对话框类,如datepickerdialog、timepickerdialog及alertdialog。其中alertdialog我上回用过一次,基本上就那样子了,今天看看另外两个对话框的使用吧。很简单的,无非是需要一个ondatesetlistener接口的实现而已,在它里面的dateset方法中就可以得到选择的日期了。而timepickerdialog与datepickerdialog使用如出一辙。看看另一个progressdialog的用法吧,这个类与alertdialog一样包含了多个static的方法,所以使用起来是非常方便的。比如说
10、,如果我们需要用它来表示一个长时间的操作。5.关于service和notification大略地看了一下android.app下的service类,觉得它与activity非常相似,只是要注意几个地方:1.生命周期,service的从oncreate()-onstart(int,bundle)-ondestroy()显得更为简单。但是它的onstart是带参数的,第一个id可用来标识这个service,第二个参数显示是用来传递数据的了。比较activity,传递数据的bundle是在oncreate就带进入的。 2.service的启动由context.startservice开始,其实act
11、ivity或者service都是context的派生类。结束于context.stopservice()或者它自己的stopself()。3.service还有一个与activity不一样的是它可以由另一个context去绑定一个已存在的service。就是这个方法context.bindservice(),被绑定的service要求是已经oncreate了但可以没有onstart。在service类中有个抽象方法getbinder()可以得到这个ibinder对象。关于这方面的细节,以后再看,这里只做个记录罢。 4.与service有关的还有一个安全的问题,可以在androidmanifes
12、t.xml中用标签来声明一个service的访问权限,关于android的安全问题也留待以后再解决吧。6gridview与imageview简单一点吧,就瞧瞧那个grid的效果,android提供了一个gridview,不过从apidemo中看来,它似乎与pc上的grid差别还是挺大的,更像那个iconview的感觉。不知道android中如何实现表格界面?虽然在移动终端上,表格一般不会有谁使用,大家似乎更倾向于使用listview,而android对于listview则有更简单的实现listactivity。 很简单,只要重载几个方法就可以了,关键是那个getview方法,它负责构建出每个单
13、元格中的对象实例。这里我们构造的是一个imageview实例。然后就是同样的将这个adapter赋给gridview即可,大家可以看看效果,注意在做这个例子前,先放几个小图片到res/drawable目录下,buildproject一下就可以得到那个r.drawable.a了(这里的a是图像文件名,如a.png)。 在getview方法中我们使用了imageview类,这又是一个widget。除了上面用到的几个方法以外,还有以下几个方法值得注意:与图像来源有关的方法,我们只用了资源文件的方式。还是习惯性跑题了,其实,我是想通过我对这个类的无数次debugger跟进,说说它的多线程异步处理的解决
14、策略的。他的基本策略如下:1. 当你实例化一个asyncqueryhandler类时(包括其子类.),它会单件构造一个线程(后面会详述.),这个线程里面会构建一个消息循环。2. 获得该消息循环的指针,用它做参数实例化另一个handler类,该类为内部类。至此,就有了两个线程,各自有一个handler来处理消息。3. 当调用onxxx的时候,在xxx函数内部会将请求封装成一个内部的参数类,将其作为消息的参数,将此消息发送至另一个线程。4. 在该线程的handler中,接受该消息,并分析传入的参数,用初始化时传入的contentresolver进行xxx操作,并返回cursor或其他返回值。5.
15、构造一个消息,将上述返回值以及其他相关内容绑定在该消息上,发送回主线程。6. 主线程默认的asyncqueryhandler类的handlemessage方法(可自定义,但由于都是内部类,基本没有意义.)会分析该消息,并转发给对应的onxxxcomplete方法。7. 用户重写的onxxxcomplete方法开始工作。这就是它偷偷摸摸做过的事情,基本还是很好理解的。我唯一好奇的是它的线程管理方式,我猜测他是用的单件模式。第一个asyncqueryhandler的实例化会导致创建一个线程,从此该线程成为不死老处男,所有的contentresolver相关的工作,都由该线程统一完成。个人觉得这种解
16、决方式很赞。本来这个线程的生命周期就很难估量,并且,当你有一个contentprovider的请求的时候,判断你会做更多的类似操作并不过分。就算错了,花费的也只是一个不死的线程(与进程同生死共存亡.),换来的却是简单的生命周期管理和无数次线程生死开销的节约。同时另外一个很重要的问题,他并会涉及到单件中数据同步的问题,每个类都有各自的handler类,彼此互不干扰,分发可以分别进行。当多个数据请求的时候,在同一个contentresolver上进行的可能微乎其微,这就避免了堵塞。总而言之,这套解决办法和android的整体设计算是天作之合了。 所以建议,如果你有什么非contentprovide
17、r操作,却需要异步多线程执行的话,模拟一套,是个不错的策略,当然,具体情况具体分析,生搬硬套是学不好马列主义的。7.显示控件使用android的界面显示同样也是基于控件的。通常是用view(包括viewgroup)控件配上xml的样式来做的。具体细节不想说了,可以参考 samples里的apidemos/view,和view的doc,以及implementing a ui这篇doc。其他还有很多,感觉算是sdk讲述的最多的内容。 从控件的使用上,和网页的设计类似,尽量用parent_width之类的抽象长度,用theme来做风格,抽取所有的字串等信息做本地化设计。相关内容参看implement
18、ing a ui就好。一类比较重要的是数据绑定控件。如果做过会从中看到很多类似的地方。一个支持数据绑定的控件,比如listview。可以通过一个 listadapter绑定到一个数据源上。listadapter是一个抽象类,主要的实现类包括simpleadapter和 simplecursoradapter。前者是绑定一个静态的array,后者是绑定一个动态的cursor。cursor前面说过,是一个指向数据源的随机迭代器,将view绑定到cursor通常要设置这样几个参数。一个是每一行的样式,称作row layout,其实就是一个普通的layout的xml文件。还有就是一个列和现实控件的对应
19、关系。那个控件显示哪个列的值,这是需要配置的。为了定制一个良好的数据显示控件,最简单你可以定制很pp的row layout,复杂一点就是可以重载绑定控件view,或者是适配器listadapter。如果是一个数据显示密集的应用,且你对ui有些追求,这个工作估计是必不可少的。 一个主要用于显示数据内容的activity,可以选择派生自listactivity。它提供了一个具有listview 的layout,还有simple_list_item_1, simple_list_item_2, two_line_list_item等默认的row layout,还有一些比较不错的api,和可供响应选择
20、item的事件。可以满足你比较基础的需求。如果你觉得只有一个listview的界面太突兀,你可以为这个listactivity指定一个layout,需要注意的是,你需要提供一个id为android:id/list的listview控件,避免activity在内部偷偷寻找该控件的时候失败。 除了这些要求,做好ui还有注意易用性和效率。快捷键是一个比较不错的选择,在 activity中调用setdefaultkeymode(shortcut_default_keys),可以开启快捷键模式,然后你可以将菜单绑定到指定快捷键上就ok了。个人觉得tip也是一个比较重要的东西,但目前观察看来,这个东西只能
21、够自己提供了。界面的动态性有时候是不可避免的,比如说菜单就是一个需要经常根据光标位置提供不同的选项。这个东西android很人道的考虑到了,你可以参看nodelist这个sample。它采取的应该是一个静态模拟动态的方式,这样有助于提高速度。你也可以利用viewinflate,动态从一个xml创建一个控件。成本据doc说很大,不到万不得已不要使用。 8.intent消息传递在前面写android的contentprovider时候,可以看到那是基于观察者模式的一个消息传递方法。每一个cursor、contentresolver做为一个小的注册中心,相关观察者可以在这个中心注册,更新消息由注册中
22、心分发给各个观察者。而在mfc或winform中,都会形成一个消息网,让消息在网中流动,被各节点使用、吃掉或者在出口死掉。 相比之下,我个人觉得基于intent的android核心消息传递机制是有所不同的。它应该会有一个全局性的注册中心,这个注册中心是隐性的,整个android系统中就那么一个。所有的消息接收者,都被隐形的注册到这个中心。包括activity,service和intentreceiver。其实说隐形注册是不确切的,所有注册都还是我们手动告诉注册中心的,只是与传统的方式不一样,我们通常不是通过代码,而是通过配置文件来做。在应用的manifest中,我们会为一些activity或s
23、ervice添加上intent-filter,或在配置文件中添加项。这其实就相当于向系统的注册中心,注册了相关的intent-filter和receiver(这个事情完全可以通过代码来做,只是这样就失去了修改的灵活性)。 当程序有一个消息希望发出去的时候,它需要将消息封装成一个intent,并发送。这时候,应该是有一个统一的中心(恩,有可能android底层实现的时候不是,但简单这样看是没问题的.)接受到这个消息,并对它进行解析、判定消息类型(这个步骤降低了耦合.),然后检查注册了相匹配的filter或receiver,并创建或唤醒接收者,将消息分发给它。这样做有很多好处。虽然这种传递有的时候
24、不如点对点的传递快(这有些需要速度的地方,我们看到android会通过直接通信来做),但有时候又因为它只经过一跳(姑且这么叫吧.),比复杂的流动又要更快。更重要的是,它耦合性低,在手机平台这种程序组件多变的条件下使用十分适合。并且它可以很容易实现消息的精确或模糊匹配,弹性很大。(我个人曾想在开发一个c+二次平台的时候引入这样的机制,但在c+中,建立一套完整的数据marshal机制不容易,相比之下,用java来做会简单很多.) 恩,废话说了很多,具体讲讲android中intent的使用。当你有一个消息需要传递,如果你明确知道你需要哪个activity或者其他class来响应的话,你可以指定这个
25、类来接受该消息,这被称为显性发送。你需要将intent的class属性设置成目标。这种情况很常见,比如startactivity的时候,会清楚当前activity完了应该是哪个activity,那就明确的发送这个消息。 但是,有的时候你并不确定你的消息是需要具体哪个类来执行,而只是知道接收者该符合哪些条件。比如你只需要有一个接收者能显示用户所选的数据,而不想制定某个具体的方法,这时候你就需要用到隐形发送(传统上,我们可能会考虑用多态,但显然这种方式更为灵活.)。在android中,你可以为intent指定一个action,表示你这个指令需要处理的事情。系统为我们定义了很多action类型,这些
26、类型使系统与我们通信的语言(比如在activity里面加一个main的filter,该activity就会做成该应用的入口点),当然你也可以用于你自己的应用之间的通信(同样当然,也可以自定义.)。强烈建议,在自己程序接收或发出一个系统action的时候,要名副其实。比如你响应一个view动作,做的确实edit的勾当,你发送一个pick消息,其实你想让别人做edit的事,这样都会造成混乱。当然只有action有时候是不够的,在android中我们还可以指定catalog信息和type/data信息,比如所有的显示数据的activity,可能都会响应view action。但很多与我们需要显示的数
27、据类型不一样,可以加一个type信息,明确的指出我们需要显示的数据类型,甚至还可以加上一个catalog信息,指明只有你只有按的是“中键”并发出这样的消息才响应。 从上面可以看出,android的intent可以添加上class, action, data/type, catalog等消息,注册中心会根据这些信息帮你找到符合的接收者。其中class是点对点的指示,一旦指明,其他信息都被忽略。intent中还可以添加key/value的数据,发送方和接收方需要保持统一的key信息和value类型信息,这种数据的marshal在java里做,是不费什么力气的。 android的intent发送,可
28、以分成单播和广播两种。广播的接收者是所有注册了的符合条件的intentreceiver。在单播的情况下,即使有很多符合条件的接收者,也只要有一个出来处理这个消息就好(恩,个人看法,没找到确切条款或抉择的算法,本来想实验一下,没来得及.),这样的情况很容易理解,当你需要修改某个数据的时候,你肯定不会希望有十个编辑器轮流让你来处理。当广播不是这样,一个receiver没有办法阻止其他receiver进行对广播事件的处理。这种情况也很容易理解,比如时钟改变了,闹钟、备忘录等很多程序都需要分别进行处理。在自己的程序的使用中,应该分清楚区别,合理的使用。 9.contentprovider数据模型数据库
29、操作从我目前掌握的知识来看,sqlite比较轻量(没有存储过程之类的繁杂手段),用起来也比较简单。实例化一个sqlitedatabase类对象,通过它的apis可以搞定大部分的操作。从sample中看,android中对db的使用有一种比较简单的模式,即派生一个 contentproviderdatabasehelper类来进行sqlitedatabase对象实例的获取工作。基本上, contentproviderdatabasehelper类扮演了一个singleton的角色,提供单一的实例化入口点,并屏蔽了数据库创建、打开升级等细节。在contentprovider中只需要调用conten
30、tproviderdatabasehelper的opendatabase方法获取sqlitedatabase的实例就好,而不需要进行数据库状态的判断。 uri像进行数据库操作需要用sql一样,对contentproivder进行增删改查等操作都是通过一种特定模式的uri来进行的(ig:content: /provider/item/id),uri的能力与url类似,具体细节可以查看sdk。建立自己的contentprovider,只需要派生 contentproivder类并实现insert, delete, update等抽象函数即可。在这些接口中比较特殊的是gettype(uri)。根据传
31、入的uri,该方法按照mime格式返回一个字符串(=!没听过的诡异格式.)唯一标识该uri的类型。所谓uri的类型,就是描述这个uri所进行的操作的种类,比如content:/xx/a与 content:/xx/a/1不是一个类型(前者是多值操作,后者是单值),但content:/xx/a/1和content:/xx/a/2 就会是一个类型(只是id号不同而已)。 在contentprovider通常都会实例化一个contenturipraser来辅助解析和操作传入的uri。你需要事先(在static域内)为该contenturipraser建立一个uri的语法树,之后就可以简单调用 cont
32、enturipraser类的相关方法进行uri类型判断(match方法),获取加载在uri中的参数等操作。但我看来,这只是在使用上简化了相关操作(不然就需要自己做人肉解析了.),但并没有改变类型判定的模式。你依然需要用switch.case.对uri的类型进行判断,并进行相关后续的操作。从模式来看,这样无疑是具有强烈的坏味道,类似的switch.case.代码要出现n此,每次一个 contentprovider做uri类型的增减都会需要遍历修改每一个switch.case.,当然,如果你使用模式(策略模式.)进行改造对手机程序来说无疑是崩溃似的(类型膨胀,效率降低.),所以,只能是忍一忍了(恩,还好不会扩散到别的类中,维护性上不会有杀人性的麻烦.)。 增删改查contentprovider 和所有数据源一样,向外提供增删改查操作接口,这些都是基于uri的指令。进行insert操作的时候,你需要传入一个uri和 contentvalues。uri的作用
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1