上一个应用中的下拉刷新我是自己摸索着写的，不过是针对 UITableView 的，这次的应用是要针对一个 UIScrollView ，就想用现成的，反正大概原理都差不多，没有必要重复造轮子。于是选择了 EGORefreshTableHeaderView 。
下午就边网上搜索边尝试使用，但是发现这个组件里的文字使用了多语言设置，诶呀我去，我的应用根本不需要多语言，估计写代码的多少都和我一样有点强迫症，于是按照它的结构来添加多语言处理，没有修改源码，顺便就当学习下如何使用多语言呗。
添加语言时，弹出了一个对话框，大概是问是不是要引用系统默认的英文。一想应用又不上国外市场，要着毛用。就取消，然后选择英文，点击删除。列表里干净了，洁癖的人你伤不起。准备添加中文，但是这个时候添加不了了。
对话框里只有一个 Choose files and reference language to create **** localization ，无法下一步了，在这下班的点来了这么下，网上一顿好找，google 时不时和谐，后来终于在 stackoverflow 的某个网页上发现了方法，现在放出来，方便和我一样E文是个半吊子的人。
右键点击*.xcodeproj 文件，选择显示包内容，然后编辑 project.pbxproj 文件，搜索/* End PBXSourcesBuildPhase section */字符，在这个段落的后面添加一个新的段落如下：
/* Begin PBXVariantGroup section */
27548D921611B0BE008EA1CD /* Localizable.strings */ = {
isa = PBXVariantGroup;
children = (
27548D941611B0BE008EA1CD /* en */,
);
name = Localizable.strings;
path = ../Code;
sourceTree = “<group>”;
};
/* End PBXVariantGroup section */
到这里都还算简单，后面的步骤我是摸索了才明白。
接下来，在项目中添加 Localizable.strings 资源文件，然后在project.pbxproj文件中搜索 /* Localizable.strings in Resources */ 字符串，找到前面的字符串标志，替换我红色标记的部分。记得喔，绿色部分的不要替换，我给替换了然后 xcode 直接崩溃掉。蓝色部分的 path 我就不清楚啥意思了，原帖中只是说让大家自己尝试就知道什么情况了。我看了下project.pbxproj里其它地方对于 Localizable.strings 文件有 path 关键字的描述，最后给修改成 Localizable.strings 这个字符串了，而非上面的 ../Code。
重新打开项目，系统默认的语言就又回来了。接下来就是该怎么办就怎么办了，真长姿势。
后面的总结就是，XCode 真心木有 VS 好用。
昨天编译的时候，突然间给跳出了编译错误。File was built for archive which is not the architecture being linked (arm7s)。反正也看不懂英文，就拿错误信息在网上搜索了下，有人说是修改 build setting ，按照操作，发现木有效果。
于是又重新搜索，发现了解决的方法。XCode -> Project Setting -> BuildSettings -> Build Active Architechure Only 从No改成Yes .
问题解决，编译后果断提交审核。
在我们的 metro/modern 应用中，如果我们的程序想实现直接跳转到微软的windows store中的话，可以参考下面的方法，这些也是我在翻 MSDN 的文档中看到的。
使用协议，关于自定义协议的文章，可以看衣服自己洗的文章。
通过ms-windows-store协议来实现。目前该协议支持3种行为，分别为 PDP、Updates、Search。首先我们要知道应用程序的包名，把应用程序的包名作为参数传递过去就可以了。如果是应用程序本身的话，可以通过 Package.Current.Id.FamilyName 来获得。
完整的程序代码：
await Launcher.LaunchUriAsync(new Uri(“ms-windows-store:PDP?PFN=” + Package.Current.Id.FamilyName));
PDP 是打开应用的列表页，参数 PFN 为应用程序的包名。Updates 是打开 store 的更新页。Search 是打开store 的搜索结果列表页，参数 query 是搜索关键词。
最近在一个android 项目中，想对一个字符串变量做 switch 判断，居然提示说有语法错误，感觉太不可思议了。然后按照 Eclipse 的智能提示，自动做修复。但是在对话框中给出了错误信息，Android requires compiler compliance level 5.0 or 6.0. Found ‘1.7’ instead. Please use Android Tools > Fix Project Properties.
在网上搜索了一把，很多文章都写的是在项目上右键 ->android tools->Fix Project。如果不可以，检查Project->Properties->Java Compiler ，确认是 1.6 。
按照这个操作了后，无论修改成 1.6 还是 1.7还是不可以，很是气愤呀。后来无意见看到到了一个，说是需要确保android sdk中有Android1.6（API4）。果断去下载了，然后把 java compiler 改成 1.7 后，问题解决了。
这真是太奇怪了。
最近工作中有遇到这样的一个需求，就是在metro应用中，想调用指定的windows桌面程序来做一些事情。于是就琢磨了下，使用自定义协议来实现的。
其实我们接触自定义协议，用的最多的就是腾讯的 tencent:// 了，可以实现在网页中调用QQ的添加好友界面了。我们常见的协议有 http ftp svn 等。当由于实际业务中这样或者那样的实际需要时，我们可以使用自定义协议来满足我们的要求。
为系统添加自定义协议很简单，最简洁的是2步。首先，我们在注册表 HKEY_Classes_Root 下添加协议的名称做为项，例如 zyx，为该项添加一个字符串“URL Protocol”，值为空字符串。接下来，我们再为该协议设置关联程序，在 HKEY_Classes_Root\zyx 下创建项 shell ，在 shell 下创建项 open ，在open 下创建项 command ,为该项设置默认值为应用程序的绝对路径，如果再路径的后面再添加 “%1” 的话，就表示可以接受额外的参数。
这里我给出 .reg 文件好了，很方便开发时使用。
Windows Registry Editor Version 5.00
;添加自定义协议
[HKEY_CLASSES_ROOT\zyx]
“URL Protocol”=””
;设置关联程序
[HKEY_CLASSES_ROOT\zyx\shell\open\command]
@=”c:\\launch.exe %1″
把上面的代码直接保存为reg文件，双击导入到注册表即可。这里有几个小知识点可以说下，reg文件里的注释是以;开头的，如果是多行注释，那么每一行都需要添加分号。如果路径不存在，那么系统会自动创建路径。设置关联程序时，默认值的内容文本里如果包含斜杠的话，那么应该使用双斜杠，和注册表路径区分出来。如果是反注册的话，只用在 HKEY 字符的前面添加一个-，同时去掉设置即可。
在一开始的时候，为注册表添加协议关联，我还犹豫是选择 bat 格式呢还是选择 inf 格式，后来还是决定用 reg 格式了。容易理解，很方便。
我们的项目中，想在metro下启动windows应用程序，下面来讲述如何使用。
比如说代码中直接这样执行，bool flag=await Windows.System.Launcer.LaunchUriAsync(new Uri(“zyx://ooxx-with-you”)); 在运行的时候，就会运行我们在注册表里设置的关联程序 launch.exe ，同时把 zyx://ooxx-with-you 作为参数传递过去。
有了参数传入，那么程序就可以做各种逻辑操作了。对于参数，我衣服自己洗这里就多啰嗦2句，虽然对于协议来说，zyx 是协议的名称，但是为了和其它协议作为格式上的一致，我们还是要添加上 :// 标志，作为区分也是好的嘛。另外，在参数中需要考虑2个问题，第一个是符号的问题，如果是特殊符号例如空格什么的，需要考虑编码问题。如果是网页中的地址，IE 会自动帮我们转码，但是其它的部分程序又不会例如资源管理器。所以为了避免编码问题带来的潜在风险，就不要使用特殊符号了。第二个问题是，自定义协议是在注册表里设置的，谁都可以调用，为了安全考虑，关联程序需要对接收到的参数进行检查。当然咯，检查的方法是需要自己来实现的。
有的同学还不是很了解应用场景，这里说一个。metro 应用程序是运行在沙盒中的，metro IE 同样也是的，在有网银、ActiveX的页面中，可能会有些问题，虽然未来可能会有解决方案，但是目前的一个思路就是，系统跳回桌面，使用 desktop 下的 IE 来打开，这么一来，使用自定义协议不就可以解决我们的问题了么。
其实，还有扩展名的解决方案，在我的demo中也实现了，和自定义协议大同小异，就留给大家去思考啦。
前几天需要用到字符串拼接的地方，突然短路了，不知道怎么写了。
在 java 和 c# 中，字符串的拼接是直接用 + 来操作的。在 OC 中，说是有下面3种方法，
- NSString *str=[NSString initWithFormat:@”%@,%@” , a , b];
- NSString *str=[a stringByAppendingString: b];
- NSString *str=[string stringByAppendingFormat:@”%@,%@”, a , b];
网上的说法是第二种方法效率更好一点，不过我就感觉不出来什么，具体情况具体对待好了。
上一篇日志我不是说票不好买的嘛，然后某一天又看到了了一个3号晚上的票，所以就提前走了。
虽然回家了，但是仍在处理一个事情，笑死我了。
3年前，某单位试水互联网，推出了一款基于互联网内容的软件。刚开始的时候，很受欢迎，加上自身的优势，用户增长的是越来越快了。在节前的时候，老板做了一个决定，也就是我们现在要处理的事情，就是把这个软件从用户电脑上给主动卸载掉。
这是我工作以来，遇到的最搞笑的事情，而且这样的事情居然发生在这样的一个单位。无论是做软件也好，还是做互联网应用也好，都是想着尽量地吸引用户，占领用户的电脑。老板决定通过各种技术的或者非技术的手段，想法设法地把已经出货的电脑上的软件给卸载掉，于是我在回家后仍然不得不测试如何完全卸载掉。
软件前后几个版本，功能也都有很多变更，对于一个软件来说，在已经出货到用户手里，要满足老板提出来的“只要用户联网了，就给干掉”要求，确属不容易。
我们将推出的更新包就一个功能，更新的时候卸载自身的主程序。对于曾经花了时间和精力在上面的我来说，很是心痛。然后让老板这么做的原因就在于一个潜在的可能的法律风险。不通过商务或者法务层面去解决，而直接的干掉，对于一个总监来说，感觉武断了些。总结经验教训，可能有以下几点：
1、不是亲生儿子不受重视。曾经的部门调整，让这个项目有点不受重视，虽然亲生儿子也凡善可陈。
2、老板没有互联网意识，还只是停留在软件层面。对于互联网的东西，不懂也不想学习。
3、不愿意承担任何风险。部门间的相互扯皮。
4、后期运营跟不上。用户上来了，但是高层不愿意投入资源来负责运营，做技术的干着急。每年的预算要的多，后来用都用不完，宁愿挥霍也不愿意投入。
事已至此，某单位第一次试水互联网应该以失败画上句号。
今年一来是由于某些无下限浏览器的干扰把相对公平变得更不公平。另外由于某2货部门推广高铁，减少了直达的车次。
所以我就木有票拉。
本来夕发朝至的车，换成高铁后，价格多了200多，另外在转车的时间安排上变的不太合理了。我一直在犹豫要不要多出那200多块钱。口袋里的钱增长速度都跟不上物价的速度，连火车的更新换代速度都跟不上，真TM的惭愧。
上一个星期，都在解决一个问题，c# 调用 c++ 的 dll 。
问题出现在字符串上，在 win8 64位+vs2012 环境下，64位的c#去调用64位的 c++ dll。在调试的时候，总是自动退出调试，没有进入异常，也没有什么输出。dll 方法是接收2个参数，并返回一个字符串。c# 通过调用获得返回的字符串。
一开始的时候，我以为是由于 c# 和 c++ 之间不同的类型转换时，我给设置错了类型导致，然后又仔细拿网上的好几篇文章做对比，发现这块没有问题。dll 文件并不是我们这边提供的，没有源码所以也不好联调。我就给 dll 那边发邮件，描述情况，并期待他们的反馈。
对方那边就只会c++，我提供的c#代码他们看不太懂，再加上对方没有64位环境，同时也不愿意提供dll的源码给我这边调试，进度比较慢。白天就是邮件来邮件去，晚上的时候我就各种安装系统，发现这问题只在64 位系统上出现，在 32 位系统上是可以正确调用的。
后来突然想到，如果我这边新建一个 c++ 项目的话，能不能够复现呢？果然，问题复现了，现在抛开对方的 dll 文件，也可以进行调试了。经过跟踪，发现 c++ 代码完全成功执行了，但是在 c# 调用这边就崩溃了。这么看起来，似乎和 c++ 代码方面的关系不大。于是又仔细检查了 c++ 的导出函数设置，没有问题。我以为是我c#项目的问题，删掉重建了个简单的，还是不行。
接下来，我又怀疑是不是 vs 本身的问题，因为是用的 2012 的版本，恰好这个时候，vs2012 sp1补丁包出来了，果断地升级。升级后发现还是崩溃了。
到这里似乎没有进展了，最后我请教了 c++ 方面的救兵。雪飞同学果然很是强悍，不多会就给出了我一个解决方法。在 c# 这边的函数申明这里设置返回类型为 IntPtr 类型，然后使用 Marshal.PtrToStringAuto 方法进行转换为托管字符串。问题就解决了。
我们一起还讨论这个问题出现的原因，一个可能的原因是在64位平台上，c++ 返回的是一个64位的指针，但是c#在调用的时候，并没有作为64位指针来获取，或者说拿了一个错误的指针，导致字符串获取失败。有可能在 c# 64位平台上字符串的初始化的时候，从非托管代码到托管代码的构造函数里存在缺陷。当然这个问题，是不是这样的，我们就不清楚了。获取给 vs 的开发team发个邮件可以得到更详细的信息。
在今天的时候，我越想越愤懑，为什么别的语言可以，c# 就非得这样，在32位和64位平台上还要做区分代码编写。碰巧下午我测试时先申明了字符串，然后再调用，发现问题居然解决了。似乎验证了和雪飞同学一起讨论的结果。
可是，最好的一个解决方法居然是这样的。这一刻，我觉得太蛋疼了。真的。
string s=””;s=GetInfo(); 的写法和 string s=GetInfo(); 之间对于托管代码和非托管代码居然有这样的区别。
还有另外一个问题，就是结构体转换成字节时，进入了异常。也是字符串的问题，后来根据 google 上面的搜索解决了。如果结构体里包含字符数组，在转换成字节时，需要先定义长度，不然会转换失败。具体来说就是在结构体里字符数组前面添加属性定义。例如
[MarshalAsAttribute(UnmanagedType.ByValArray, SizeConst = 6)] public char[] device ; //这里的 device 为 “iphone”，长度为6，所以 SizeConst=6