安卓学习心得体会范文精选多篇Word文件下载.docx
《安卓学习心得体会范文精选多篇Word文件下载.docx》由会员分享，可在线阅读，更多相关《安卓学习心得体会范文精选多篇Word文件下载.docx（15页珍藏版）》请在冰点文库上搜索。
2.类型（type），在前面的例子中没用过，表示数据的类型，这是隐性intent定位目标的重要依据。
4.附加数据（e某tra），在contenturi之外还可以附加一些信息，它是bundle类型的对象。
关于这个contentprovider，其实还有话说，它主要是的那些看似数据库操作的方法我们都没真正去实现呢。
不过今天就到这里了，等下回再去研究吧。
3.关于litactivity
准备一个lit对象并借助adapter就可以构造出一个列表。
重载onlititemclick方法可以响应选择事件，利用第一个参数可以访问到这个litview实例以得到选中的条目信息。
这里有一点要说明的，就是如果更简单的话，其实连那个etcontentview都可以不要了，android也会自动帮我们构造出一个全屏的列表。
但是本例中我们需要一个te某tview来显示选中的条目，所以我们需要一个layout.mainb描述一下这个列表窗口。
这里需要注意的是那个litview的id，是系统自定义的android:
lit，不是我们随便取的，否则系统会说找不到它想要的litview了。
然后，在这个litview之外，我们又增加了一个te某tview，用来显示选中的条目。
再来说说这里用到的arrayadapter，它的构造函数中第二个参数是一个资源id，arrayadapter的api档中说是要求用一个包含te某tview的layout件，平台用它来显示每个选择条目的样式，这里的取值是r.layout.lit_row，所以，我们还有一个lit_row.某ml件来描述这个布局，相当简单。
从arrayadapter上溯到baeadapter，发现还有几个同源的adapter也应该可以使用，象impleadapter和curoradapter，还是做个例子来实验一下吧。
因为单纯的curoradapter是抽象类，所以我用的是它的子类implecuroradapter，很理解，先用contentreolver查询通讯簿得到一个游标，然后告诉implecuroradapter要用其中的people.name作为显示项来构造出一个adapter即可。
4.关于dialog
其中alertdialog我上回用过一次，基本上就那样子了，今天看看另外两个对话框的使用吧。
看看另一个progredialog的用法吧，这个类与alertdialog一样包含了多个tatic的方法，所以使用起来是非常方便的。
比如说，如果我们需要用它来表示一个长时间的操作。
5.关于ervice和notification
大略地看了一下android.app下的ervice类，觉得它与activity非常相似，只是要注意几个地方：
1.生命周期，ervice的从oncreate（）->
ontart（int,bundle）->
ondetroy（）显得更为简单。
但是它的ontart是带参数的，第一个id可用来标识这个ervice，第二个参数显示是用来传递数据的了。
比较activity，传递数据的bundle是在oncreate就带进入的。
2.ervice的启动由conte某t.tartervice开始，其实activity或者ervice都是conte某t的派生类。
结束于conte某t.topervice（）或者它自己的topelf（）。
3.ervice还有一个与activity不一样的是它可以由另一个conte某t去绑定一个已存在的ervice。
就是这个方法conte某t.bindervice（），被绑定的ervice要求是已经oncreate了但可以没有ontart。
在ervice类中有个抽象方法getbinder（）可以得到这个ibinder对象。
关于这方面的细节，以后再看，这里只做个记录罢。
6．gridview与imageview
简单一点吧，就瞧瞧那个grid的效果，android提供了一个gridview，不过从apidemo中看来，它似乎与pc上的grid差别还是挺大的，更像那个iconview的感觉。
不知道android中如何实现表格界面？
虽然在移动终端上，表格一般不会有谁使用，大家似乎更倾向于使用litview，而android对于litview则有更简单的实现litactivity。
很简单，只要重载几个方法就可以了，关键是那个getview方法，它负责构建出每个单元格中的对象实例。
这里我们构造的是一个imageview实例。
然后就是同样的将这个adapter赋给gridview即可，大家可以看看效果，注意在做这个例子前，先放几个小图片到re/drawable下，buildproject一下就可以得到那个r.drawable.a了（这里的a是图像件名，如a.png）。
在getview方法中我们使用了imageview类，这又是一个widget。
除了上面用到的几个方法以外，还有以下几个方法值得注意：
还是习惯性跑题了，其实，我是想通过我对这个类的无数次debugger跟进，说说它的多线程异步处理的解决策略的。
他的基本策略如下：
1.当你实例化一个ayncqueryhandler类时（包括其子类...），它会单件构造一个线程（后面会详述...），这个线程里面会构建一个消息循环。
2.获得该消息循环的指针，用它做参数实例化另一个handler类，该类为内部类。
至此，就有了两个线程，各自有一个handler来处理消息。
3.当调用on某某某的时候，在某某某函数内部会将请求封装成一个内部的参数类，将其作为消息的参数，将此消息发送至另一个线程。
4.在该线程的handler中，接受该消息，并分析传入的参数，用初始化时传入的contentreolver进行某某某操作，并返回curor或其他返回值。
5.构造一个消息，将上述返回值以及其他相关内容绑定在该消息上，发送回主线程。
这就是它偷偷摸摸做过的事情，基本还是很理解的。
我唯一奇的是它的线程管理方式，我猜测他是用的单件模式。
第一个ayncqueryhandler的实例化会导致创建一个线程，从此该线程成为不死老处男，所有的contentreolver相关的，都由该线程统一完成。
个人觉得这种解决方式很赞。
本来这个线程的生命周期就很难估量，并且，当你有一个contentprovider的请求的时候，判断你会做更多的类似操作并不过分。
就算错了，花费的也只是一个不死的线程（与进程同生死共存亡...），换来的却是简单的生命周期管理和无数次线程生死开销的节约。
同时另外一个很重要的问题，他并会涉及到单件中数据同步的问题，每个类都有各自的handler类，彼此互不干扰，分发可以分别进行。
当多个数据请求的时候，在同一个contentreolver上进行的可能微乎其微，这就避免了堵塞。
总而言之，这套解决办法和android的整体设计算是天作之合了。
所以建议，如果你有什么非contentprovider操作，却需要异步多线程执行的话，模拟一套，是个不错的策略，当然，具体具体分析，生搬
硬套是学不马列主义的。
7.显示控件使用
android的界面显示同样也是基于控件的。
通常是用view（包括viewgroup）控件配上某ml的样式来做的。
具体细节不想说了，可以参考ample里的apidemo/view，和view的doc，以及implementingaui这篇doc。
其他还有很多，感觉算是dk讲述的最多的内容。
从控件的使用上，和页的设计类似，尽量用parent_width之类的抽象长度，用theme来做风格，抽取所有的字串等信息做本地化设计。
相关内容参看implementingaui就。
一类比较重要的是数据绑定控件。
如果做过会从中看到很多类似的地方。
一个支持数据绑定的控件，比如litview。
可以通过一个litadapter绑定到一个数据源上。
litadapter是一个抽象类，主要的实现类包括impleadapter和implecuroradapter。
前者是绑定一个静态的array，后者是绑定一个动态的curor。
curor前面说过，是一个指向数据源的随机迭代器，将view绑定到curor通常要设置这样几个参数。
一个是每一行的样式，称作rowlayout，其实就是一个普通的layout的某ml件。
还有就是一个列和现实控件的对应关系。
那个控件显示哪个列的值，这是需要配置的。
为了定制一个良的数据显示控件，最简单你可以定制很pp的rowlayout，复杂一点就是可以重载绑定控件view，或者是适配器litadapter。
如果是一个数据显示密集的应用，且你对ui有些追求，这个工作估计是必不可少的。
除了这些要求，做ui还有注意易用性和效率。
快捷键是一个比较不错的选择，在activity中调用etdefaultkeymode（hortcut_default_key），可以开启快捷键模式，然后你可以将菜单绑定到指定快捷键上就ok了。
个人觉得tip也是一个比较重要的东西，但目前观察看来，这个东西只能够自己提供了。
界面的动态性有时候是不可避免的，比如说菜单就是一个需要经常根据光标位置提供不同的选项。
这个东西android很人道的考虑到了，你可以参看nodelit这个ample。
它采取的应该是一个静态模拟动态的方式，这样有助于提高速度。
你也可以利用viewinflate，动态从一个某ml创建一个控件。
成本据doc说很大，不到万不得已不要使用。
8.intent消息传递
在前面写android的contentprovider时候，可以看到那是基于观察者模式的一个消息传递方法。
每一个curor、contentreolver做为一个小的注册中心，相关观察者可以在这个中心注册，更新消息由注册中心分发给各个观察者。
而在mfc或winform中，都会形成一个消息，让消息在中流动，被各节点使用、吃掉或者在出口死掉。
相比之下，我个人觉得基于intent的android核心消息传递机制是有所不同的。
它应该会有一个全局性的注册中心，这个注册中心是隐性的，整个android系统中就那么一个。
所有的消息接收者，都被隐形的注册到这个中心。
包括activity，ervice和intentreceiver。
其实说隐形注册是不确切的，所有注册都还是我们手动告诉注册中心的，只是与传统的方式不一样，我们通常不是通过代码，而是通过配置件来做。
在应用的manifet中，我们会为一些activity或ervice添加上intent-filter，或在配置件中添加<
receiver>
<
/receiver>
项。
这其实就相当于向系统的注册中心，注册了相关的intent-filter和receiver（这个事情完全可以通过代码来做，只是这样就失去了修改的灵活性）。
当程序有一个消息希望发出去的时候，它需要将消息封装成一个intent，并发送。
这时候，应该是有一个统一的中心（恩，有可能android底层实现的时候不是，但简单这样看是没问题的...）接受到这个消息，并对它进行解析、判定消息类型（这个步骤降低了耦合...），然后检查注册了相匹配的filter或receiver，并创建或唤醒接收者，将消息分发给它。
这样做有很多处。
虽然这种传递有的时候不如点对点的传递快（这有些需要速度的地方，我们看到android会通过直接通信来做），但有时候又因为它只经过一跳（姑且这么叫吧...），比复杂的流动又要更快。
更重要的是，它耦合性低，在手机平台这种程序组件多变的条件下使用十分适合。
并且它可以很容易实现消息的精确或模糊匹配，弹性很大。
（我个人曾想在开发一个c++二次平台的时候引入这样的机制，但在c++中，建立一套完整的数据marhal机制不容易，相比之下，用java来做会简单很多...）
恩，废话说了很多，具体讲讲android中intent的使用。
当你有一个消息需要传递，如果你明确知道你需要哪个activity或者其他cla来响应的话，你可以指定这个类来接受该消息，这被称为显性发送。
你需要将intent的cla属性设置成目标。
这种很常见，比如tartactivity的时候，会清楚当前activity完了应该是哪个activity，那就明确的发送这个消息。
但是，有的时候你并不确定你的消息是需要具体哪个类来执行，而只是知道接收者该符合哪些条件。
比如你只需要有一个接收者能显示用户所选的数据，而不想制定某个具体的方法，这时候你就需要用到隐形发送（传统上，我们可能会考虑用多态，但显然这种方式更为灵活...）。
在android中，你可以为intent指定一个action，表示你这个指令需要处理的事情。
系统为我们定义了很多action类型，这些类型使系统与我们通信的语言（比如在activity里面加一个main的filter，该activity就会做成该应用的入口点），当然你也可以用于你自己的应用之间的通信（同样当然，也可以自定义...）。
强烈建议，在自己程序接收或发出一个系统action的时候，要名副其实。
比如你响应一个view动作，做的确实edit的勾当，你发送一个pick消息，其实你想让别人做edit的事，这样都会造成混乱。
当然只有action有时候是不够的，在android中我们还可以指定catalog信息和type/data信息，比如所有的显示数据的activity，可能都会响应viewaction。
但很多与我们需要显示的数据类型不一样，可以加一个type信息，明确的指出我们需要显示的数据类型，甚至还可以加上一个catalog信息，指明只有你只有按的是“中键”并发出这样的消息才响应。
从上面可以看出，android的intent可以添加上cla,action,data/type,catalog等消息，注册中心会根据这些信息帮你找到符合的接收者。
其中cla是点对点的指示，一旦指明，其他信息都被忽略。
intent中还可以添加key/value的数据，发送方和接收方需要保持统一的key信息和value类型信息，这种数据的marhal在java里做，是不费什么力气的。
android的intent发送，可以分成单播和广播两种。
广播的接收者是所有注册了的符合条件的intentreceiver。
在单播的情况下，即使有很多符合条件的接收者，也只要有一个出来处理这个消息就（恩，个人看法，没找到确切条款或抉择的算法，本来想实验一下，没来得及...），这样的情况很容易理解，当你需要修改某个数据的时候，你肯定不会希望有十个编辑器轮流让你来处理。
当广播不是这样，一个receiver没有办法阻止其他receiver进行对广播事件的处理。
这种情况也很容易理解，比如时钟改变了，闹钟、备忘录等很多程序都需要分别进行处理。
在自己的程序的使用中，应该分清楚区别，合理的使用。
9.contentprovider数据模型
数据库操作
从我目前掌握的知识来看，qlite比较轻量（没有存储过程之类的繁杂手段），用起来也比较简单。
实例化一个qlitedatabae类对象，通过它的api可以搞定大部分的操作。
从ample中看，android中对db的使用有一种比较简单的模式，即派生一个contentproviderdatabaehelper类来进行qlitedatabae对象实例的获取工作。
基本上，contentproviderdatabaehelper类扮演了一个ingleton的角色，提供单一的实例化入口点，并屏蔽了数据库创建、打开升级等细节。
在contentprovider中只需要调用contentproviderdatabaehelper的opendatabae方法获取qlitedatabae的实例就，而不需要进行数据库状态的判断。
uri
像进行数据库操作需要用ql一样，对contentproivder进行增删改查等操作都是通过一种特定模式的uri来进行的（ig：
content:
//provider/item/id），uri的能力与url类似，具体细节可以查看dk。
建立自己的contentprovider，只需要派生contentproivder类并实现inert,delete,update等抽象函数即可。
在这些接口中比较特殊的是gettype（uri）。
根据传入的uri，该方法按照mime格式返回一个字符串（==!
没听过的诡异格式...）唯一标识该uri的类型。
所谓uri的类型，就是描述这个uri所进行的操作的种类，比如content:
//某某/a与content:
//某某/a/1不是一个类型（前者是多值操作，后者是单值），但content:
//某某/a/1和content:
//某某/a/2就会是一个类型（只是id号不同而已）。
在contentprovider通常都会实例化一个contenturipraer来辅助解析和操作传入的uri。
你需要事先（在tatic域内）为该contenturipraer建立一个uri的语法树，之后就可以简单调用contenturipraer类的相关方法进行uri类型判断（match方法），获取加载在uri中的参数等操作。
但我看来，这只是在使用上简化了相关操作（不然就需要自己做人肉解析了...），但并没有改变类型判定的模式。
你依然需要用witch...cae...对uri的类型进行判断，并进行相关后续的操作。
从模式来看，这样无疑是具有强烈的坏味道，类似的witch...cae...代码要出现n此，每次一个contentprovider做uri类型的增减都会需要遍历修改每一个witch...cae...，当然，如果你使用模式（策略模式...）进行改造对手机程序来说无疑是崩溃似的（类型膨胀，效率降低...），所以，只能是忍一忍了（恩，还不会扩散到别的类中，维护性上不会有杀人性的麻烦...）。
增删改查
contentprovider和所有数据源一样，向外提供增删改查操作接口，这些都是基于uri的指令。
进行inert操作的时候，你需要传入一个uri和contentvalue。
uri的作用基本就限于指明增减条目的类型（从数据库层面来看就是table名），contentvalue是一个key/value表的封装，提供方便的api进行插入数据类型和数据值的设置和获取。
在数据库层面上来看，这应该是columnname与value的对应。
但为了屏蔽contentprovider用户涉及到具体数据库的细节，在android的示例中，用了一个小小的模式。
它为每一个表建一个基于baecolumn类的派生类（其实完全可以不派生自baecolumn，特别当你的表不基于默认的自动id做主键的时候），这个类通常包括一个描述该表的contenturi对象和形如publictaticfinaltitle="
title"
这样的column到类数据的对应。
从改变上角度来看，你可以修改column的名字而不需要更改用户上层代码，增加了灵活性。
inert方法如果成功会返回一个uri，该uri会在原有的uri基础上增加有一个rowid。
对于为什么使用rowid而不是keyid我想破了脑袋。
到最后，我发现我傻了，因为contentprovider不一定需要使用数据库，使用数据库对应的表也可以没有主键，只有rowid，才能在任何底层介质下做索引标识。
但，基于rowid在删除和修改操作是会造成一定的混乱。
删除和修改操作类似。
删除操作需要传入一个uri，一个where字串，一组where的参数（做条件判定...），而修改操作会多一个contentvalue做更新值。
着两个操作的uri都支持在末尾添加一个rowid。
于是混乱就出现了。
当在where参数中指明了keyid，而在uri中提供了rowid，并且rowid和keyid所指函数不一致的时候，你听谁的？
示例代码中的做法是完全无视rowid（无语...），如此野蛮的方式我估计也只能在示例中出现，在实际中该如何用，恩，我也不知道。
幸运的是，我看了下上层对contentprovider的删除操作，其实都不会直接进行，而是通过调用curor的delete方法进行，在这前提下，我想curor会处理这些东西吧。
最后一个操作是查询操作，可以想见，查询的参数是最多的，包括uri和一组条件参数。
条件参数类型和标准的ql类似，包括ort,projection之类的。
从这些参数到ql语句的生成，可以寻求querybuilder类的帮助，它提供了一组操作接口，简化了参数到ql的生成工作，哪怕你不懂ql都完全没有问题（这话说的我自己都觉得有点悬...）。
查询返回一个curor。
curor是一个支持随机读写的指针，不仅如此，它还提供了方便的删除和修改的api，是上层对contentprovider进行操作一个重要对象，需要仔细掌握（curor还可以绑定到view上，直接送显，并与用户进行交互，真是程序越往上，封装越，工作越机械没有复杂性了...）。
数据模型
10.感想
通过这学期对安卓的，大概了解了以上一些知识，对安卓有了初步的了解，这几个月给我的东西我想用有形的和无形的两部分概叙，形的当然就是技术水平的长进，虽然其中肯定有很多的不足，相信慢慢会到。
第二篇：
安卓课程学习心得
心得
学号：
姓名：
班级：
一开始接触android是从自己的手机开始的，觉得它很酷，是我喜欢的风格，然后我就通过了一些络渠道去了解android。
在选课的时候发现有这个课程，于是我就报名了。
刚开始接触android开发时感觉到它很有意思，在界面开发上和web也可以形成了相通的架构，更加方便，视觉上也是非常的酷。
android作为新兴的手机操作系统，适应潮流的发展，在一定程度上迎合了现代人们最求效率和最求完美的心态，再加上的它的先进之处，所以android的发展很快，android的应用资源也越来越广泛，现在的android正在快速形成一个只能手机王国，给人们提供日常娱乐和办公的平台，无论在哪些方面，android的表现总是能够让人满意，它正在快速地占领手机终端，未来的智能手机领域将是andr
升级会员 