objectively的专栏

一、前言 Cookies想必所有人都了解， 但是未必所有人都精通。本文讲解了Cookies的各方面知识，并且提出来了最佳实践。这是笔者在日常工作中的积累和沉淀。 二、基础知识 1.什么是 CookiesCookie 是一小段文本信息，伴随着用户请求和页面在 Web 服务器和浏览器之间传递。Cookie 包含每次用户访问站点时 Web 应用程序都可以读取的信息。例如，

用VC++访问网页，一般都是用微软提供的Wininet、WinHTTP（基于HTTP协议）或WebBrowser（加载整个网页）。当然还有libcurl之类的第三方类库，因为暂时没接触过，就不说了。在使用上述三种方式访问网页的编程过程中，默认情况下是由它来管理Cookie，但有时候程序员想手工干预，比如清除Cookie、修改Cookie、添加Cookie。在网上搜索了一下，大概有这么三种方

一、 int PASCAL FAR setsockopt( SOCKET s, int level, int optname, const char FAR* optval, int optlen); 设置套接口的选项。 s：标识一个套接口的描述字。 level：选项定义的层次；目前仅支持SOL_SOCKET和IPPROTO_TCP层次。 optname：需设置的选项。 opt

在掌握了socket相关的一些函数后，套接字编程还是比较简单的，日常工作中碰到很多的问题就是客户端/服务器模型中，如何让服务端在同一时间高效的处理多个客户端的连接，我们的处理办法可能会是在服务端不停的监听客户端的请求，有新的请求到达时，开辟一个新的线程去和该客户端进行后续处理，但是这样针对每一个客户端都需要去开辟一个新的线程，效率必定底下。     其实，socket编程提供了很多的模型来

大家都知道,Windows程序的内存机制大概是这样的,全局变量(局部的静态变量本质也属于此范围)存储于堆内存,该段内存较大,一般不会溢出; 函数地址、函数参数、局部变量等信息存储于栈内存,VC6中栈内存默认大小为1M,对于当前日益扩大的程序规模而言,稍有不慎就可能出问题。(动态申请的内存即new出来的内存不在栈中)即如果函数这样写：void test_stack_overflo

分析一，转自独奏的同名Blog      今天调试程序时在Debug版跳出这个错误，我程序根本没设置断点，而其好像说是我的堆有问题，而编译了个Release版本运行正常，后来google下，查到如下解释：      说是调试状态下，操作系统用DebugWin32Heap来替代正常的heap分配内存空间。在这个堆上的任何操作debug的堆管理器会检查堆的数据完整性，如果它发现了一个错

一、什么是instancetypeinstancetype是clang 3.5开始，clang提供的一个关键字，表示某个方法返回的未知类型的Objective-C对象。我们都知道未知类型的的对象可以用id关键字表示，那为什么还会再有一个instancetype呢？二、关联返回类型（related result types）根据Cocoa的命名规则，满足下述规则的方法：1、类方法中，以alloc或

UIResponder Class ReferenceManaging the Responder Chain[plain] view plaincopy1.- (UIResponder *)nextResponder  返回接收者的下一个相应，如果没有就返回nilUIResponder类不自动存储和设置下一个响应者，而是默认

UIResponder Class ReferenceManaging the Responder Chain[plain] view plaincopy1.- (UIResponder *)nextResponder  返回接收者的下一个相应，如果没有就返回nilUIResponder类不自动存储和设置下一个响应者，而是默认

//----- View 在响应链中查找属自己的 ViewController（递归查找）------ (id)traverseResponderChainForUIViewController{ id nextResponder = [self nextResponder]; if ([nextResponder isKindOfClass:[UIViewController

//把 xxx.app 包里的文件拷贝到 Documents 目录下，并指定是否覆盖，YES 则覆盖- (void)BundleToDocuments:(NSString *)fileName existsCover:(BOOL)cover{ BOOL success; NSError *error; NSFileManager *fileManager = [NSFi

@implementation TempView{ BOOL isSelfTouche;}- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event{ if(isSelfTouche) [self removeFromSuperview];}#pragma mark - hitTes

注：以下讨论都是在ARC模式下我们在iOS开发中最经常碰到的“引用(reference)”的使用是在error上，比如如下代码[objc] view plaincopyNSError *error = nil;  BOOL success = [myContext save:&error];  if (!success) { 

在2011的WWDC上，苹果推出了GCD，从此多线程增加了一种新的方法。GCD要求运行在iOS4.0版本以上或者OS X10.6版本以上。GCD是Grand Central Dispatch的缩写，是一组用于实现并发编程的C接口。GCD是基于Objective-C的Block的特性开发的，基本的业务逻辑和NSOperation很像。都是添加一个任务到一个队列，由系统来负责线程的生成和调度。因为直接

前面了iOS的NSThread方法来实现多线程，这篇就简单的讲讲NSOperation和NSOperationQueue。      NSOperation是一个抽象类，定义一个要执行的任务。NSOperationQueue是一个任务队列，帮助对NSOperation所定义的任务进行管理。当任务加入到任务队列后，会自动按照优先级和依赖关系自动运行。      NSOperation

多线程这个概念的接触是蛮早的时候了，当时还是单核单CPU的时候，Thread这个概念已经出现了，当时比较流行的方案是时间片轮流，线程可以优先级抢占，但一次只能运行一个线程，实际上多线程是不能真正并行处理的，只是宏观上表现的多线程在齐头并进。现在硬件进步了很多，多核的CPU时代来临了，于是线程开始了真正意义上的并行处理，多线程也作为越来越重要的一个部分需要掌握。        iOS中关于线

前面分析了一通iOS事件的分发，主要介绍了事件如何找到处理的view，又是如何按照responder chain逐级传递的。这篇文章主要介绍iOS事件的拦截以及特殊处理。        我们知道事件的分发是由Application到Window再到各级View的，所以显然最安全可靠的拦截地方是Application。这里拦截事件后如果不手动往下分发，则进入hit-test View过程的机

移动平台上的开发主要关注数据以及数据的处理，事件的处理以及UI。所以事件的分发处理是很重要的一个环节，对于一个平台的优劣来说也是一项重要的参数。如果事件的分发设计的不好，一些复杂的UI场景就会变得很难写甚至没法写。从小屏没有触摸的功能机开始到现在大屏多点触摸的智能机，对于事件的分发处理基本思路都是一样的——链（设计模式中有个模式就是职责链chain of responsibility），只是判定的