如何使用PopupWindow:
//初始化popuwindow LayoutInflater mLayoutInflater = (LayoutInflater) SubList.this.getSystemService(LAYOUT_INFLATER_SERVICE); View title_popunwindwow = mLayoutInflater.inflate(R.layout.sublist_popuwindow, null); PopupWindow mPopupWindow = new PopupWindow(title_popunwindwow, LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT,true); mPopupWindow.setBackgroundDrawable(new BitmapDrawable());//点击窗口外消失 mPopupWindow.setOutsideTouchable(true);
显示PopupWindow:
mPopupWindow.showAsDropDown(findViewById(R.id.titlebar_center),-43,0);
pw.showAtLocation(view, Gravity.CENTER, -(view.getWidth()),y);
若需要监听PopUpWindow里控件的事件,如PopUpWindow里面一个按钮的事件,那么就需要调用方法setFocusable(true)获得焦点,并且在调用setFocusable(true)方法后,可以通过Back(返回)菜单使PopUpWindow dimiss;另外调用方法setOutsideTouchable(true)后,点击PopUpWindow外面的控件也可以使得PopUpWindow dimiss。需要顺利让PopUpWindow dimiss;PopUpWindow的背景不能为空。
http://pingguohe.net/2011/09/01/howtojudgewhetheradelegateisreleased/#comment-983
困惑了相当长时间的一个问题了,实际上在Xcode4中会出现
if ((int)delegate->isa == classIsa) {
这行报错,member reference base type 'id<HTTPRequestDelegate>' is not a structure or union
因为ide不认为它是NSObject对象,只要对它转为NSObject对象即可。
//************************************************************************************
Cocoa中回调delegate的方法时判断delegate是否已经被释放
这个需要是因为最近在做网络请求的底层,需要在请求完成时回调某delegate的某方法。
然而回调时经常遇到这种情况:delegate已经被release了。如果delegate已经被dealloc掉,则无法调用其方法,否则引起程序crash。
此篇文章中博客作者也有相同的问题:http://longtimenoc.com/archives/objective-c-delegate的那些事儿
首先,我们此时无法用if (nil = delegate)判断delegate是否已经被dealloc掉,因为被dealloc之后,delegate对象也不是空的,大部分情况下是一个objc_object*类型的C指针。
其次,我们又会想到在本对象中先对delegate retain一次,这样回调时不会崩溃了。但是这样会出现一个retain cycle,本对象和delegate都永远不会被释放了。
再次,我想到是否可以用isKindOfClass判断是否被dealloc。然而此时也不能用[delegate isKindOfClass]判断是否已经被dealloc,因为isKindOfClass是NSObject协议中的方法,此时delegate如果不是NSObject,对其发送isKindOfClass消息会导致crash。
此时很小部分情况下,delegate会是NSObject,可能是NSDictioary,也可能是原本的类。而大部分情况下,delegate已经不是NSObject。所以此时任何形式的[delegate method]都会导致crash,因为任何的[delegate method]的前提都是:delegate是一个NSObject。
无奈之下我又想到,使用delegate->isa判断delegate是不是NSObject。这里介绍一下,objective-c中所有对象都是结构体,每个结构体中都有一个名为isa的指针指向其类。而类也是一种结构体,类的isa指向其父类。处于最底层的结构体是无isa的,NSObject的isa指向的也是NSObject。isa具体的值是运行时确定的。
一开始的思路是用delegate->isa->isa->isa->…一直指下去,如果isa与NSObject的isa相同,则说明delegate是一个NSObject。但是这样是行不通的,因为如果delegate不是NSObject,只是objc_object*,一直指下去却指不到NSObject的话,总会指到最底层的结构体,而此结构体无isa,如果访问结构体内没有的东西,程序又会crash了。
说了这么多,结论就是这个问题很是蛋疼。再做不出来我就要把释放本对象的责任交给用户了。
等等,如果在本对象初始化后,delegate传进来时保存delegate的isa,此时delegate一定未被dealloc(为什么?因为是单线程的),在回调时判断delegate此时的isa和当时保存的isa是否一样,就可以解决了。
代码如下:
协议声明:
@protocol HTTPRequestDelegate <NSObject> @optional - (void) requestDidLoadResponse:(NSString *)responseDictionary; - (void) requestDidFailedLoadResourceURLWithError:(NSError *)error; @end
类声明:
@interface MyClass : NSObject <FooDelegate,BarDelegate> { ... int classIsa; id <HTTPRequestDelegate> delegate; } @property (nonatomic,assign) id <HTTPRequestDelegate> delegate; @end
类实现:
@implementation MyClass @synthesize delegate; - (id)initWithDelegate:(id)requestDelegate { self = [super init]; if (self) { //TODO:Send request,etc. self.delegate = requestDelegate; } return self; } - (void)setDelegate:(id<HTTPRequestDelegate>)iDelegate { delegate = iDelegate; NSString *delegateDescription = [[iDelegate class] description]; classIsa = (int)objc_getClass([delegateDescription UTF8String]); } - (void)callback { if ((int)delegate->isa == classIsa) { if ([delegate respondsToSelector:@selector(requestDidLoadResponse:)]) { NSString *responseString = @"foobar"; [delegate requestDidLoadResponse:responseString]; } } }
然而由于多线程的原因(发出请求和回调发生是在两个线程上的),会有极少数的情况(测试中发生概率在万分之一以内,和CPU有关)在if ((int)delegate->isa == classIsa)判断时,delegate当前的isa会和本对象初始化时isa相等,也就是说delegate未被dealloc,而调用回调时,delegate已被dealloc,导致程序crash。避免这种小概率事件的方法是,在delegate中发送请求前[self retain]一下,然后在回调到达时[self release]一下,这样除了避免崩溃以外,还会确保请求已经发送完毕,不会被发送一半。
以上。
–OpenThread
事故
一级(轻微)
新闻资讯中出现明显错别字,段落折行。标题过长而造成的页面下沉。相应栏目长期疏忽更新。文章分入栏目错误,或因疏忽出现的下线及过期提示没有做出及时修改的。
由内容主管评定,做出书面点名警告,并cc给全体内容部门成员。一个月内重复2次以上,处罚直接进入第二级。
二级(一般)
首页文章链接错误、下线而造成文章不能正常浏览,私自使用CMS修改栏目及他人文章造成混乱的,工作没有按时完成,一篇文章中有三处以上文字错误的。正常情况下延误团队项目进度的。
由内容主管评定,做出书面点名警告,并cc给全体内容部门成员。扣除当月业绩表现分数的10—30%。一个月内处罚2次,直接进入第三级。
三级(严重)
因操作疏忽出现竞争对手,工作多次不能正常完成的,因失误造成重要页面不能正常浏览的,无意中泄露内容部门的商业秘密及重要内容的,首页链接错误出现一天以上仍没有修改的。出现国家法律禁止的言论没有做到及时处理的。
由部门总监及主管评定后,部门内通报批评,扣除当月20—50%的奖金,责任人写出不低于1000字的反省检查及下阶段工作计划。连续两月出现三级事故,直接进入第四级。
四级(不可饶恕)
宣扬竞争对手,故意泄露内容部门重要信息的,连续三次出现第三级事故中的任何一条的,有意无意通过互联网平台诋毁本公司及部门领导声誉的,
由部门总监及主管评定后,通告全部门,并申报人力资源部门,无条件开除或留公司观察,扣除当月奖金等。
奖励
三等功(佳)
一月内成功制作两个专题且网友较关注的,一月内原创文章在5篇以上并发表的,连续3个月无工作事故的,个人所发文章总pv超过上月10%的等其他。
由内容主管评定当月表现分数为100,部门内通报表扬,发放小奖品一份(如布娃娃或一支笔等等)
二等功(优秀)
策划出网站内容新的展现模式并成功实施的,一月内成功制作三个专题且网友较关注的,一月月内原创文章在10篇以上并发表的,连续6个月无工作事故的等等
由内容主管评定,每三个月评选一次,部门内通报表扬,颁发小奖品一份,除公司以外福利部门内可带薪休假1天等。
一等功(超优秀)
完成部门开发的新重大内容项目的,寻求到有利于网站内容流量及品牌推广合作并顺利开展的,12个月内无工作事故的,制作的专题在同行及媒体中有较强影响力的等
由内容总监及主管评定,年底颁发网站内容部最佳员工称号,申请HR部门增加年度奖金30%等其他奖励