我参加了今年的百度开发者大会，感觉他们准备的不足，礼品太烂了。
主题
应用万象，云创未来
地点：北京国际会议中心 ，早上8点中开始签到（通过手机后4位）签到领证入场，到10点中开发者论坛演讲正式开始
首先由李彦宏致辞，他讲的比较泛，比较随意，其中讲到hao123 的创业者是一个初中生，那时候我们大家都在学习，做的开发的大多是企业级应用，hao123 就是一个导航，技术来说的话，现在任何一个人都能做。李兴平：hao123作者，他快速的迎合了网民的需求，发现机会,他成功了。李彦宏还讲到之前他们是做产品，做应用，给客户提供好的产品以及应用，百度过去十几年做了一件事——搜索引擎，搜索引擎的主要作用是让网民平等获取信息，对互联网产业的作用的流量分发。流量分发帮助了一大批站长走向成功。现在他们来做服务，做平台、做云----百度云，给开发者提供很好的资源与服务（百度将资源打包，提供平台，让开发者为百度的用户服务，开发出好的应用）。
接下来的演讲主要围绕着百度的开放平台、百度云、未来互联网以及手机应用的介绍，听一听，了解一下概念，其中纽约留学生：尤雨溪，（独立开发者）他讲到：HTML5是当前的大热趋势，对于个人开发者，尤其是对应用开发还不是很熟悉的个人开发者而言，学习这个是一个好的选择。但是html5的时代还不成熟。
未来基于html5的应用会代替原生app，主要针对 web应用，手机应用等。
目前比如手机开发最困惑的是：开发出android的app，还要做一遍ios的开发，同时还要提供pc上的网站（太痛苦了）。
但是html5 现在还处于发芽阶段，还不成熟，现在互联网上的巨头都在推html5。具体多长时间能够成熟，这个说不好。因为这是一个w3c规范。
我下午也关注了他的技术演讲，让我认识到真正的html5应用（技术上理念就是用html+css3+javascript + 后台服务 来完成）
javascript 来完成目前做的web系统上的MVC全部功能,并且使用js直接调用后台的服务(后台只是服务)。
还有一点印象深刻的是其中javascript 一个用法：
针对全局变量，最好当参数传递到闭包函数内，这样速度会快一些
比如
var PageInfo = (function(win){
return {
init:function(){
//.......
win.alert("你好");
}
}
})(window);
window.onload = function(){
PageInfo.init();
}
调用：
PageInfo.init();//比如进行初始化页面的所有工作,对外只提供单一变量。
这些属于开发的细节，个人开发习惯。
我个人觉得百度论坛最大的亮点当属于13岁的天才开发者：郑博闻。IOS开发者，是kindle3 中文输入法的作者，太利害了，13岁。
他的演讲内容：比较精彩：
“大家好，我是郑博闻，我是一名IOS开发者，今年13岁。首先进行一个简短的自我介绍。这就是我，大家好，我是郑博闻，今年13岁，在简短的自我介绍之后，让我们开始今天的话题，开发是大家非常熟悉的单词。但是我为何选择开发，这也是大家非常感兴趣的问题。。。。。演讲也很有意思。”
其中讲到三个单词：simple，touch，green。
Simple：极简主义是乔布斯一种贯彻的理念，何为简洁，简洁是一种简单的美，来源色彩的搭配、工程的排版。我在我的产品中一直追求简洁的美，我的生活中，简洁一直是我的首选。
Touch：未来得世界是可以触摸的世界，也是触手可及的世界。
Green：绿色环境，人人有责。
“Simple、Touch、Green，三者结合在一起的时候，那就是未来。未来它是APP的未来，是Simple的未来，是Touch的未来，更应该是Green的未来，每个人心中都有创新之火，只有点燃才会燃烧，如果放在一边，随着时间的车轮滚动，会慢慢的腐朽，当你想用的时候，你会发现似乎已经并不属于你了，再也用不到了。所以我们抓紧时间让创新之火在我们心中燃烧出最动人的光彩光芒。我想说，Anyone can make a Startup，只要有足够的热情，肯定能在热爱的事业中获取成功。”
……………………………
他的讲解：应用是为了满足需求，非常简单的应用能够满足需求，它就是成功的。未来是app的时代，应用为王的时代，谁也不知道啥是杀手级的应用，但是：满足需求是应用的本质。年仅13岁给3千多的开发者演讲。他觉得是焦点，亮点。
百度的这个开发者感受：未来是 移动+ 云 的时代，(满足需求)应用的时代。百度基于自己的资源给出了，提供出很多开放式API，让开发者能够更好的开发出好的应用。并且百度在当天正式上线：百度开发者中心(developer.baidu.com),聚合百度内：开发、部署，运营、变现 全部资源，提供给合作方全流程的服务支持。
开放平台
<!--[if !supportLists]-->1、 <!--[endif]-->百度数据开放平台（open.baidu.com/data）
<!--[if !supportLists]-->2、 <!--[endif]-->百度应用开放平台（app.baidu.com/developer）
<!--[if !supportLists]-->3、 <!--[endif]-->移动应用开放平台（mobileapp.baidu.com）
<!--[if !supportLists]-->4、 <!--[endif]-->百度连接开放平台（dev.baidu.com/connect）
<!--[if !supportLists]-->5、 <!--[endif]-->百度地图API（dev.baidu.com/wiki/map）
<!--[if !supportLists]-->6、 <!--[endif]-->百度移动定位API(dev.baidu.com/wiki/geolocation)
<!--[if !supportLists]-->7、 <!--[endif]-->百度站长平台(zhangzhang.baidu.com)
<!--[if !supportLists]-->8、 <!--[endif]-->百度分享（share.baidu.com）
<!--[if !supportLists]-->9、 <!--[endif]-->百度移动开放平台（open.shouji.baidu.com）
<!--[if !supportLists]-->10、 <!--[endif]-->百度游戏开放平台( youxi.baidu.com/open)
<!--[if !supportLists]-->11、 <!--[endif]-->百度知道开放平台(open.zhidao.baidu.com)
<!--[if !supportLists]-->12、 <!--[endif]-->百度百科合作平台（baike.baidu.com/hezuo）
<!--[if !supportLists]-->13、 <!--[endif]-->百度开放云平台(cloud.baidu.com)
其中：
百度移动开放平台：
依托百度无线搜索和百度优势移动技术能力，为站长提供全方位的支持，立足于通过平台建立于无线各类型合作伙伴的良性合作关系。
百度云开放平台：
提供给中小型创业团队，开发创新互联网运用的一个平台，分享百度云端架构，能够帮助中小开发团队开发更好的运用。
今天在做自定义的可选文本的 TextView 类时，用到了 View 类的 setOnTouchListener（OnTouchListener l）事件监听,在构造 OnTouchListener 对象时需要重写 onTouch（...）方法，这个方法的返回值是布尔类型，
刚开始我按默认给定的返回值 false运行，发现只能监听到这个 view 的“按下”事件，“移动”和“抬起”都不能够监听到；于是把返回值改为了 true，就都监听到了。
但是随后又遇到了一个问题，那就是：点击其他组件后，再点击这个 view 的时候获取不到焦点！也就是click事件不响应了。我猜想一定是受到了 onTouch 方法的影响，查资料发现：
设为true 和 false的效果是有区别的：
setOnTouchListener 单独使用的时候返回值需要为true，这样才能保证移动的时候能后获取相应的监
听，而非一次监听（即每次只有一个按下的事件）
setOnTouchListener 和 setOnClickListener 同时使用时，onTouch 的返回值要设为 false，这样既可
以保证按下移动抬起事件可以被监听，并且点击事件也会被监听。
于是，我又对这个 view 设置了setOnClickListener（虽然重写的方法体中什么也没写），并将onTouch 的返回值要设为 了false，结果就 既监听到了Touch 也能监听到 click 事件了，可以重获焦点了！
One of the things I like most about Apple’s iOS SDK is the consistent and easy-to-use API they provide. Across all their different frameworks there’s a pattern at work that makes using their classes easy to understand. This is due in part to the simplicity for configuring those objects. In most cases you don’t need to call cryptic methods to setup or teardown classes. If you want to change a label’s font, you just set a property. If you want to add a new set of tabs to a UITabBarController, you simply have to assign an array of view controllers to the “viewControllers” property and away you go.
This up front simplicity comes at a cost however: somebody had to write code to intercept the setting of those properties and update the view to reflect the changes made. Fortunately for those developers at Apple, Cocoa and Cocoa Touch makes this simple through the use of Key-Value-Observing (KVO). If you know how to use it, you can do the same thing in your applications as well. Read on to see what I do to make implementing KVO in my projects easy and intuitive.
Key-Value-Observing, or more commonly KVO, is a mechanism by which you can observe changes to keys and their values bound to an object. It lets you make arbitrary objects aware of changes made to values in other objects that are important to you. When those values are changed at all, theobserveValueForKeyPath:ofObject:change:context: method is invoked on the listener, or “observer”. In essence, it lets you listen to when people change properties on your object.
You might say “Really? That’s all it does? I can get the same by creating a custom setter!” and you might be right, but there’s several reasons why creating custom setters to handle update logic might be undesirable:
Using KVO in a class essentially buys you flexibility and easy-to-read code, and with a few general practices can be made easy to read and easy to extend.
Many developers getting started with KVO, myself included, typically start by assigning observers for one or two keyPath properties in either their init or viewDidLoad methods. Then, within theirobserveValueForKeyPath:ofObject:change:context: method they will have code to respond to those setting changes.
As an example lets assume we’re creating a UIView subclass that has a UIColor property that controls the display of several subviews.
When that property changes lets make our view update all our sub-views to the appropriate color. We could do this with a custom setter, like so:
For the purposes of this example though, lets utilize KVO for this.
In the initWithFrame: method we add ourselves as an observer of the keyPath “color”, passing in the default options. We also define a method that Cocoa Touch uses to notify the observer, in this case “self”, when a keyPath has been changed. This method is invoked for different properties that are changed, so you should always pass the message along to “super” if this method is called for a property you didn’t explicitly add as an observer.
While the above code does look longer than the custom setter equivalent, in the long-run this code is much easier to extend over the life of your class, especially as you add more complex behaviors.
As my experience with KVO improved, so did my techniques for managing my observers, responding to keyPath value changes, and generally keeping my code clean. One of the things I found was that it is useful to keep a list of the keyPaths you’re observing so that you can conveniently iterate over them programmatically.
To illustrate my point, consider an example where you expose multiple subviews as properties, and when some values change you would like to perform some sort of redraw operation.
As you can see not only would this be impossible to do with custom setters, but we managed to respond to several different property changes using a single block of code.
Additionally, keeping a static NSSet object around with a list of the keys you’re observing is convenient for several reasons:
There are other advantages, but this is just the tip of the iceberg.
In order to illustrate how to build a more complicated feature using KVO, lets create a UITableViewCell subclass that makes it easy to create a gloss icon in your table cells, just like the iTunes App Store app. If we’re successful we should be able to create a table cell whose icon looks like the screenshot to the right.
Instead of requiring us to worry about the details of rendering the gloss icon overlay every time we want to display an app icon, lets create a property on our table cell that encapsulates this behavior. Ideally we should be able to set the app icon’s original image once, and the UITableViewCell imageView.image property should be set to the appropriate content. We could do this with a custom accessor, but I’d like to show you an easy way to do this with KVO.
You can see from our interface declaration that we’re adding two properties for the icon image itself, and a boolean indicating whether or not we want the gloss effect. Now lets look at the implementation.
This code may seem complicated, but in the end it is very straight-forward. I’m also introducing a few additional concepts here that I’d like to call out specifically.
KVO allows you to specify different options for when you’re observing a set of keyPaths. It’s a bit-mask, so you can enable multiple options simultaneously. In this example I’m indicating that I want to be notified of both the old and new values of these properties. When the icon is changed, the change dictionary supplied to our callback tells us both the old and new values of the property.
This is a pattern I use which helps for simplicity of code, as well as a defensive coding mechanism. By declaring static NSString variables for each keyPath you’re observing, it ensures you won’t accidentally type the wrong keyPath somewhere in your code. It also gives you a single place for defining, or changing, the keyPath you’re interested in observing.
In this example I’m returning early in the block, when the keyPath is not in my set of “ObservableKeys”. This makes the callback code cleaner since you eliminate one extra nested “if” block, and helps to prevent mistakes.
I find it useful to extract values from the change dictionary as early as possible, and then cast those values as needed.
If you’re not careful your observer callback can get quite large. It’s powerful to be able to have a single point where complex behaviours and patterns can be established between different properties, but you should make sure it doesn’t become overgrown with logic. It’s better to start out by pushing complex logic into private methods, and simply invoke that from within your callback.
Apple’s own documentation, as always, is a good source of information but it can tend to be a lot to take in. At this point you should have a basic understanding of how KVO works, and how you can use it in your application. You can also download the sample application created above at Github.
Once you get started, finding answers to your questions becomes simpler when you’ve gotten the hang of KVO. Good luck, and happy coding!