前些天去參加了Google的開發日活動，由于之后直接就去郊區所以一直沒有時間寫blog來談談感想。首先是google的OpenSocial，進入大廳簽到之后轉角過去就是個大網站的展臺，每個柱子的一面是一個網站，都是OpenSocial的合作網站，有聚友，天際，天涯等。有幸跟聚友的CTO譚曉生先生和天際網的CTO郭應壽先生聊了聊OpenSocial使用中的益處和遇到的問題，感覺OpenSocial目前還是不太成熟，對比FB來說還有一定的差距，比如沒有照片處理等等問題。而且我始終有一種感覺，OpenSocial是一個google的標準，但是各大網站在使用OpenSocial的時候幾乎都會加上自己的擴展，這樣下去，最終OpenSocial統一平臺的目標很難實現，因為兩個網站的Gidget幾乎不能通用，這些問題OpenSocial的合作網站跟Google也在討論中。另外得到的消息是，OpenSocial可能也會考慮出一套XXml，規范化OpenSocial的使用，并借此加強安全性。
稍后的OpenSocial專題topic中了解到了更多有關OpenSocial的信息，主要是Shindig了, 前一天還在跟白衣提議用ss做一個類似Shindig的東西，主要是做一個OpenSocial的實現，當時就想這玩意估計有了，但是沒想到是host到apache了，在apache的孵化器中大家可以自己找找。會議的時候逮住了一個google的人問了一堆問題，過后才知道原來是google中國sns的負責人。
最大的收獲實在是太意外了，在中午休息的時候，走過過道到樓下吃飯，突然發現一個熟悉的身影坐在角落里一個人在玩電腦，我暈是Andy Rubin，Android的老大。居然就坐在那里，而且旁邊的人沒有人在意他，要知道聽android topic的人可不少呀，居然每一個人認出他來的。我叫了朋友確認一下，準備上前打招呼。剛上去打了個招呼，握了個手，又來了一個人，他一下認出Andy，并且跟Andy簡短的交談了一下。我提議先照個相，照相后簡短聊下那個人就走了。過后Andy說那個人就是Google中國負責android的老大邸爍博士，我狂暈呀兩位老大都讓我給碰上了。稍候跟Andy聊了一下Android的發展，隨后他掏出一個android的原型機，就是google IO大會上的那種機器。這里要說明的是，不管在模擬器上android的表現如何，在真機上你的體驗絕對絕對是不一樣的，太COOL了。尤其是第二屏的widget效果，還有那個street view效果，真機拿在手上體驗就是不一樣呀～～～～ 隨后又了解到了一些android目前的發展情況，這里可以告訴大家的是，android是絕對值得期待的～！！！

經過兩天的努力，終于在Android上面跑起來MSN了。現在實現了基本的聊天功能，打算陸續的把其他功能完善，萬事開頭難，相信以后的工作會很順利。

Gtalk的功能由于有官方支持，早就弄了跟這個差不多的版本。

另外，這個軟件目前是以插件的形式開發，多一個協議就是多一個apk，實現一些intent即可。官方的IM包里面有很多支持，可惜文檔沒有提及。

 

Android中文論壇原帖

今天看到Air1.0和Ext2.0.2的發布消息，很是興奮，要知道Ext的每個版本升級都是很實惠的。

Ext2.0.2的這次升級主要是針對Air的支持，看來他們的關系是越來越近了，我也借機小試了一下Air。

簡單說說Air的開發過程：

1.先要下載jre 和 airSDK

2.jre就不說了，airSDK也是簡單的解壓一下便可。

可以看看SDK下面的bin目錄，一共倆文件，一個adl一個adt，adl是用來測試的，adt使用編輯發布的（ADT怎么讓我想起來android了）

3.創建一個普通的目錄作為項目目錄。OK，可以寫頁面了。就是寫html js flash什么的，都可。

4.編寫一個xml文件，名字不限。內容嘛～～～～

看看這個文件，airSDK\templates\descriptor-template.xml 里面有詳細的解釋，拿過來改改即可，給一個例子：

---

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/1.0.M6">
    <id>examples.html.HelloWorld</id>
    <version>0.1</version>
    <filename>HelloWorld</filename>
    <initialWindow>
        <content>HelloWorld.html</content>
        <visible>true</visible>
        <width>400</width>
        <height>200</height>
    </initialWindow>
</application>

---

5.運行airSDK\bin\adl.exe (那個創建的xml文件名)，運行即可。

PS:我一般用eclipse來編輯，用外部命令的工具來運行adl，很方便。

簡單的說了一下Air的開發方法后，我們來簡單的看一下Ext都對Air提供了什么支持。

1.Ext.air.FileProvider

Ext提供狀態保存的功能，在對AIr的支持中Ext實現了一個Provider，這個Provider把狀態保存在本地目錄的一個文件里。使用方法如下：

---

// Initialize the state provider
Ext.state.Manager.setProvider(new Ext.air.FileProvider({
	file: 'ext.state',
	// if first time running
	defaultState : {
		mainWindow : {
			width:400,
			height:200,
			x:10,
			y:10
		}
	}
}));

---

制定Provider為Ext.air.FileProvider即可，這個操作一般在onReady里面執行。當然需要你先創建一個ext.state文本文件，在程序根目錄下即可。這樣ext的應用運行時，窗口等大小的調整，位置之類的調整都能保存下來了。很方便。

這里包裝的Air代碼主要是：

air.File.applicationStorageDirectory.resolvePath

air.FileStream

等

2.Ext.air.NativeWindow

Ext可以調用Air實現Native的窗口。使用方法如下：

---

	var win = new Ext.air.NativeWindow({
		id: 'mainWindow',
		instance: window.nativeWindow,
		minimizeToTray: true,
		trayIcon: 'ext-air/resources/icons/extlogo16.png',
		trayTip: 'Simple Tasks',
		trayMenu : [{
			text: 'Open Simple Tasks',
			handler: function(){
				win.activate();
			}
		}, '-', {
			text: 'Exit',
			handler: function(){
				air.NativeApplication.nativeApplication.exit();
			}
		}]
	});

---

我們可以看到，其中最吸引人的是系統托盤的功能，可以方便的指定系統托盤的各種屬性。

這里包裝的主要是：

window.runtime.flash.html.HTMLLoader.createRootWindow

air.Screen.mainScreen.visibleBounds

3.Ext.sql.Connection

這個是重頭戲，對db的支持，我們知道Air的DB是采用sqlite3來實現的。Ext封裝了Air的db操作，簡化統一了一些，而且提供了Store的支持，非常強大：

讓我們簡單看一下用法：

首先取得connection

var conn = Ext.sql.Connection.getInstance();

而后打開db

conn.open('ext.db');//這里的文件如果不存在會自動創建

創建Table

---

        conn.createTable({
            name: 'user',
            key: 'userId',
            fields: [
			    {name: 'userId', type:'string'},
			    {name: 'name', type:'string'},
			    {name: 'pwd', type:'string'},
			    {name: 'email', type:'string'}
			]
    	});

---

取得一個Table

var userDao = conn.getTable('user','userId');

查詢

var users = userDao.select();//這里可以寫條件式

添加

---

var newuser = {
    userId : 'sshw',
    name : 'sshwsfc',
    pwd : 'test',
    email : 'sshwsfc@gmail.com'
} 

userDao.insert(newuser);

---

感覺使用上還是蠻不錯的，大家可以一點點試試看。

值得一提的是，在源碼中發現Connection這里設計成了工廠的模式，Connection是一個偽接口，實現除了Air的還有GoogleGear的，會根據所處環境選擇，灰常的好。

功能還在研究中，有心得了一點點給大家分享，

PS:打算搞一個iphone的信息管理軟件練練手。反正都是sqlite的

在朋友和同事的極力推薦下最近開始看上了python,其實主要是還是因為python是2007年度語言,怎么的也要與時俱進呀.最近一路看來有些心得,希望能與大家分享,小弟其實也只接觸不到一周的python,有說錯的地方還望大家指出改正.

不打算從py的語法基礎說起了,直接說說對django的心得:

接觸django首先需要了解可能就是他那個model，建立一個model就什么都有了，這對于搞java得人員來說還是挺有吸引力的（當然貌似對于動態語言這都是小兒科），那么讓我們先看一個model的例子：

偷懶了，直接拿django-admin里面的User出來了

---

class User(models.Model): 
    username = models.CharField(_('username'), maxlength=30, unique=True, validator_list=[validators.isAlphaNumeric])) 
    first_name = models.CharField(_('first name'), maxlength=30, blank=True) 
    last_name = models.CharField(_('last name'), maxlength=30, blank=True) 
    email = models.EmailField(_('e-mail address'), blank=True) 
    password = models.CharField(_('password'), maxlength=128)) 
    class Meta: 
        ordering = ('username',)

---

每個屬性就是一個庫表的字段，定義起來非常簡單明了，models里面提供了很多種類的Field類似上面的EmailField。不同的Field有不同的設置，可以看相應的原來來了解相關的設置．

在model class內部還有一個class Meta，這個Class的屬性制定了這個表的一些存取策略，例如這里的ordering。MetaClass里面的屬性可以用model的_meta屬性取得。OK，那么這樣一個model怎么就能實現對數據庫表的靈活操作了呢。讓我們來看看吧。

首先先分析一下/django/django/db/models/base.py這個文件，其中包含了models.Model這類的定義：

看看class定義的第一行吧，第一行就夠我琢磨一陣子的了：

---

class Model(object):
    __metaclass__ = ModelBase

---

Model采用了new style class定義，關于這個內容大家可以放狗看一下，第一行是一個__metaclass__屬性的定義，該屬性的值是ModelBase，這是一個類。__metaclass__的意思是，指定一個class，這個class的實例就是本class，相信您已經暈了。那么就拿這個Model的例子來說明一下，如果沒有__metaclass__這個屬性，產生一個實例就是正常的流程，有了這個屬性流程會有改變：

首先調用BaseModel.__new__(cls, name, bases, attrs)這個方法，回返回的值是一個class類型，然后用這個class來創建實例。其實BaseModel就是Model的元類，來制定Model這個類的最終樣子。關于元類的更多信息請看這里

那么我們的目光一下轉移到BaseModel這個類上，我有種直覺，Meta這個class最后可以用_meta來取就是在這里做的手腳，看一下BaseModel的定義吧，有點長：

---

class ModelBase(type):
    "Metaclass for all models"
    def __new__(cls, name, bases, attrs):
        # If this isn't a subclass of Model, don't do anything special.

        if name == 'Model' or not filter(lambda b: issubclass(b, Model), bases):    #1
            return super(ModelBase, cls).__new__(cls, name, bases, attrs)

        # Create the class.

        new_class = type.__new__(cls, name, bases, {'__module__': attrs.pop('__module__')})    #2

        new_class.add_to_class('_meta', Options(attrs.pop('Meta', None)))     #3

        new_class.add_to_class('DoesNotExist', types.ClassType('DoesNotExist', (ObjectDoesNotExist,), {}))

        # Build complete list of parents                                      #4
        for base in bases:
            # TODO: Checking for the presence of '_meta' is hackish.
            if '_meta' in dir(base):
                new_class._meta.parents.append(base)
                new_class._meta.parents.extend(base._meta.parents)

        model_module = sys.modules[new_class.__module__]

        if getattr(new_class._meta, 'app_label', None) is None:
            # Figure out the app_label by looking one level up.
            # For 'django.contrib.sites.models', this would be 'sites'.
            new_class._meta.app_label = model_module.__name__.split('.')[-2]  #5

        # Bail out early if we have already created this class.
        m = get_model(new_class._meta.app_label, name, False)                 #6
        if m is not None:
            return m

        # Add all attributes to the class.
        for obj_name, obj in attrs.items():
            new_class.add_to_class(obj_name, obj)                             #7

        # Add Fields inherited from parents
        for parent in new_class._meta.parents:
            for field in parent._meta.fields:
                # Only add parent fields if they aren't defined for this class.
                try:
                    new_class._meta.get_field(field.name)
                except FieldDoesNotExist:
                    field.contribute_to_class(new_class, field.name)          #8

        new_class._prepare()

        register_models(new_class._meta.app_label, new_class)                 #9
        # Because of the way imports happen (recursively), we may or may not be
        # the first class for this model to register with the framework. There
        # should only be one class for each model, so we must always return the
        # registered version.
        return get_model(new_class._meta.app_label, name, False)              #10

---

簡單分析一下這個代碼：

1. 檢查class是否為Model的子類，不是的話，不做任何處理，直接傳給父類處理，也就相當于正常的處理了class，注意super在多重繼承的時候應該嚴格使用

2. 用type來創建類，創建的就是正常的ModelClass

3. 這句很重要，add_to_class是Model里面的class方法，這個方法其實就是傳入name和value，給Model添加class屬性.看到了，原來神奇的_meta就是這么來的. 提到add_to_class方法，簡單看一下它的代碼：

---

    def add_to_class(cls, name, value):
        if name == 'Admin':
            assert type(value) == types.ClassType, "%r attribute of %s model must be a class, not a %s object" % (name, cls.__name__, type(value))
            value = AdminOptions(**dict([(k, v) for k, v in value.__dict__.items() if not k.startswith('_')]))
        if hasattr(value, 'contribute_to_class'):
            value.contribute_to_class(cls, name)
        else:
            setattr(cls, name, value)
    add_to_class = classmethod(add_to_class)

---

最后一句是制定這個方法是class方法，特點就是方法的第一個參數是本class，其實classmethod就是一個裝飾器，在2。4之后可以使用@來簡寫。這里不得不提的是他對Admin的特殊處理，雖然AdminOption不是在admin模塊里面的，但是這么做還是跟一個Admin的東東綁定起來了，在java的世界解耦是一件大事，看到下面還有對'contribute_to_class'這個方法的特殊處理，django為啥不弄的解耦點呢。而且同樣是包裝成Option，一個是在BaseModel里面弄（那個Meta的包裝），一個在add_to_class方法里面弄，實在有點不優雅，可能還沒了解太多，不知道他的深度用意吧。

4. Meta的集成，Option的這個類提供繼承方法

5. 取得applabel，就是把model的名字分割取到數第二個，我很喜歡-2這樣的設定

6. get_model方法取得緩存里面的東西。

7. 把所有的class attr拿出來搞一遍，一般的屬性就setattr弄回去了，要是這個屬性有contribute_to_class這個callable屬性，那就執行之（Admin的處理完全也可以這樣，其實我們常用的objects就是用這個方法弄的）

8. 每個Field調用自己的contribute_to_class方法來進行特殊的處理

9. 進入緩存，，暫且叫緩存吧，里面的東西大家看看很簡單 文件在 /django/django/db/models/loading.py 里面還是有很多內容的

10.看注釋說的很清楚了，我們一定要在緩存里面拿model。

 

其中需要指出的是，new_class._prepare() 這個方法，簡單列出片段：

---

    def _prepare(cls):
        # Creates some methods once self._meta has been populated.
        opts = cls._meta
        opts._prepare(cls)

        ．．．．

        dispatcher.send(signal=signals.class_prepared, sender=cls)

---

中間省略了一些代碼，不是我沒看懂的就是沒意思的，關鍵要看這個dispatcher呀。這里是監聽者模式，dispatcher.send(signal=signals.class_prepared, sender=cls)放松了一個包含特定信號的事件，讓監聽的人可以做相應的處理。這樣的信號還有很多種，我們可以很簡單的截獲信號，處理相應的內容。也許您還記得，在我們創建db的時候，會提示創建一個超級用戶，其實就是用這個方法來弄的。

那我為什么要把這個單獨拿出來說呢，因為監聽這個事件的人不是別人，是"objects"！！！在文件/django/django/db/models/manager.py的開頭就有這樣的代碼：

---

def ensure_default_manager(sender):
    cls = sender
    if not hasattr(cls, '_default_manager'):
        # Create the default manager, if needed.
        try:
            cls._meta.get_field('objects')
            raise ValueError, "Model %s must specify a custom Manager, because it has a field named 'objects'" % cls.__name__
        except FieldDoesNotExist:
            pass
        cls.add_to_class('objects', Manager())

dispatcher.connect(ensure_default_manager, signal=signals.class_prepared)

---

定義了一個callable，然后監聽signals.class_prepared信號，呵呵，連上了吧，只要Class準備好了，就調用這個方法。簡單判斷有沒有_default_manager'屬性和meta里面的objects后，開始插入objects。cls.add_to_class('objects', Manager()) 很熟悉吧，前面講過不多說了。

PS：寫到這里不由得感嘆，為啥同樣是往Class里面加入東東，要搞這么多的花樣呢，我以前也寫過一個Rails配置加載過程的分析文檔，雖然一個簡單的加載配置就把所有動態語言玩個遍，但是這也太不規范了吧，可能不這么玩就不算“動態”語言了吧，哈哈。

 

終于Model的Class造好了，相信大家以后造自己的Class也能玩出更多的花樣。那么可以開始下一步了。我到老家后再寫吧，打算講講神奇的objects，也就是Manager，其實就是玩QuerySet。。那里有很多的__xxx__方法，很好很強大