首先,这篇文章基本没什么技术含量,它主要是我对最近业余时间的WinPhone开发工作的一个总结.而且以我以往的学习经验来说，这篇文章很可能对读者中的大部分人都毫无用处，因为所谓学习方法因人而异,这我深有体会,所以这里我贴出自己关于WinPhone开发工作的一个阶段性总结只是希望里面哪怕能有一点点对你有所启示,那应该就算这篇文章的最大成功了.

自从去年工作方向由.NET转向PHP之后,C#基本就只能算我的一个业余爱好了,虽然仍然关注着这个圈子,也喜欢着这门语言,不过毕竟不是工作,没有实践,自己实在是感觉写不出怎样深刻的东西来,不过好在有了微软的WinPhone,纠结了几个月之后终于还是下手了HD7,也开始了自己WinPhone开发者的纯业余生活.到现在,虽然做的东西仍然很简单,但终于有了看得见的东西出来,我的手机号码归属地应用和中国地铁应用总算是成功挂到Market上了, 因此想想还是对这个阶段的开发工作做个总结比较好, 希望能给大家以参考.

额,好像我总是如此啰嗦,还是上正文吧.

1.写一行代码胜于看十页书.
    可能是因为之前已经有一定WPF/SL的经验,因此开发WinPhone应用时,除了微软官方的UI交互指南(因为WinPhone的UI设计理念确实和以前的应用不一样),我并未看一页书.大部分问题都是在遇到的时候才去网上查找资料解决的,当然,这并非说我没有查阅任何资料,实际上,直到现在,我每天仍然都会在WindowsPhoneGeek,MSDN和博客园上逛逛,看到不错的文章或者代码也会动手实践下.
    因此,以我的感受来说,对大部分的有一定的C#开发经验的园友来说,其实WinPhone的应用开发都不会太有难度以至于完全无法动手(当然,如果你做的是超级复杂的东西就另说啦),而且我始终认为从实际写代码中遇到问题->解决问题的过程所收获的经验要比从书本中别人讲解的经验要深刻得多.如果你真的对WinPhone开发有兴趣,那么从现在开始就动手吧,不用纠结于去看哪本书,就我从目前介绍WinPhone开发的书本目录介绍来看,这些书本一定都是第一章和第二章都是毫无意义的(第一章介绍WinPhone的设计理念,第二章介绍VS的WinPhone开发环境部署,对很多人来说,很是浪费纸张).动手不仅能更快发现你应用中存在的设计问题,还能解决实际运行中你永远无法想到的意外.
   当然,我并非反对看书,我的建议是如果你真想学WinPhone开发,那就多动手吧,这样你能更快进去开发的过程.

2.不要一开始就想把应用的功能做得够大够强够完美.
   不要一开始就想着做一个超级复杂,让人能一看就过目不忘的完美应用,这个我在开发过程中确实深有体会.其实我一开始并非想做上面的归属地应用和地铁路线图应用,而是一个斗地主的游戏,并且由于那时候WinPhone还不支持Socket,因此我一开始就计划设计一个足够聪明的AI系统,还为此复习了下很早之前丢掉的AI书籍,但越做下去发现越没信心做好,挫败感也越强.于是在经历了一个星期的空手而归之后,我开始进行反思,发现自己的AI知识实在是太过贫乏,这也不是我的优势所在,而且我的目的是至少前面一个应用是用来练手的,现在所做的工作实在不像,于是在下周开始果断放弃之前的工作,而该从手机归属地应用开始,一个界面简单,而是够实用.这样决定之后后面的工作就顺利了,并且有了第一个实用的工具第二个的思路也有了.这样在经历了一个多月的工作之后,终于还是将两个应用提交了,虽然知道所做仍然还是很浅薄,但看到能有东西挂在market上面的那种感觉确实完全不一样的.

3. 做出应用的特色, 但不一定要复杂.
    好的应用不一定要非常强大,老实说, 归属地应用确实简单,就一个界面,四个按钮,其他没啥了.但我从Nokia3230到Samsung i900再到现在的HD7,我一直都认为这个功能是我们日常生活中一个不可缺的功能.而且有了核心的功能你就可以围绕它做更多的文章了.这样做到后面也许你会发现你一开始很简单的一个东西到后面可能会越来越强大.
    反之,如果一开始想太多,各种扩展,各种架构,那你反而可能一直在徘徊, 在浪费时间,结果到头来一无是处.
    所以,如果你有了想法,并觉得这个想法确实会对别人的使用有很不错的帮助,那就开始动手吧,哪怕它实现起来并无太大技术含量.

4. MVVM? 框架?
   是否使用MVVM框架?这个问题我觉得因人而异,但你更应该看哪种方式你更顺手,我其实蛮喜欢SL的INotifyPropertyChanged,我甚至想要是C# 5中能实现属性自动双向绑定的特性(比如在要双向绑定的属性上加个特性[Bind(Ways.DoubleWay)])那C#该有多好哦.不过我对Command确实不太感冒(~~明显是因为境界不够),因此在实现时我保留了ViewModels,但对于事件还是用自己习惯的Click方式来实现,虽然这让MainPage.cs里的代码看起来太多太乱,不过现阶段来看这更有利于我书写代码的效率,同时修改代码我也更加习惯.因此我的建议是在初期你应该将很快提交能很好工作的应用这个目标放在首位,至于框架,以你自己习惯的方式来进行吧.哪种更有效则更适合你.
   当然,上面的话也并非说我们可以一直这样,每个人都会在阶段性的工作之后对之前的代码进行总结,MVVM确实是SL/WPF一个不错的代码架构方式,同时它在单元测试时也更优异.因此,在总结的时候,你需要对之前的工作做一个权衡,而不是不经思考,一成不变的用最初的思考方式进行下去.

5. 从实例开始
   如果纠结于如何开始编写应用的话,那我建议你不妨从这里(http://create.msdn.com/en-US/education/catalog/)下一个示例代码开始.绝对不要小瞧这些实例代码的,我已经看到Market上面N多人直接把各种实例代码(比如BlackJack)改改就放上去了.这些代码不仅能给你一个比较标准的代码结构,而且能迅速带你进入正常的应用运行流程,这种过程我觉得比你在枯燥的书本上看一章要好得多.你可以看看GameStateManagementSample这样的例子,里面的架子基本上都已经帮你搭好了,菜单有了,主界面有了,唯一缺失的TODO就是player和enemy,这些只需要你按照自己设想的去填充就好了.微软别的不说,在对开发人员的引导方面,确实是做得不错的.

6. 给用户提供做够多的反馈通道
   可能你的应用开始的功能非常简单,但你要相信用户,很多你看不到的东西,他们都能看到和想到,因为用户不像你,你只有一个脑袋,但他们则是千千万万个聪明的脑袋,他们可能遇到你没遇到过的问题,这些都是用户反馈的好处,所以,一定记得在你的应用里面留下至少一个反馈的通道.我的第一个应用并没有留下自己的email链接进行反馈,因此看到的大部分反馈都是来自于review里面的.于是从中国地铁开始,我在关于页面中留下自己的邮箱,并提供了很方便的邮件编写链接.这之后我收到了两个很不错的反馈建议(如果他们有看到,我在这里谢谢所有提供反馈的WinPhoner).虽然最近因为工作的关系没办法马上发布新版本,不过我会尽快提交.

7. 不要一开始就考虑赚钱
   如果你一开始时抱着赚钱的想法来做Win Phone开发的话,那我想你很可能会有两个结果,一是因为失望而热情丧失并最终离开,二是因为需要纠结于怎样才能做出别人愿意花钱的应用而一事无成.当然,你也可能会成功,但对个人开发者来说,我建议大家一开始不要抱有太高期望值,你就把做应用当成一件结交朋友,锻炼能力的事情就够了.看到应用的发布,看到别人给你应用不错的评价,看到能给别人带来实打实的帮助,那种愉悦感也是相当不错的,至少能在以后的生活中给予你自己更多的信心,我个人认为这些东西有时候比那点点钱来得更快.

8. 保护好你自己的核心代码
   老实说,微软在代码保护上做得并不好,虽然没用过,但我曾在论坛上看到已经有人做出工具可以直接下载XAP文件,也看到很多win phone论坛放出了各种付费应用的破解文件.对.net应用来说,得到了XAP文件,如果你一点保护没做,基本就是赤裸裸的了,因此,虽然你永远无法防住那些真正想要偷窃你代码的无德份子,但一些基本的工作你还是得做,特别是如果你的应用基本没有需要与服务器交互的功能的时候. 当然,如果你的大部分核心逻辑都放在服务端这个问题就不用太担心了.
   虽然如此,大家也不必太看重劳动果实偷窃这种事情,这样的人毕竟是少数.所以虽然很不幸,我的两个应用的优势都是本地数据存储, 我一开始有担心自己的劳动成果会被偷走(貌似也确实怀疑有人偷走过,当然我没有证据),也因此降低过热情,但想开了就淡定了.应用这玩意,本来自己的就是免费的,别人要偷也卖不了钱,那就偷去吧.这里我给大家的建议也是如此,你一定要做好最坏的打算,接受它但也不要放弃希望,这世界总有些事我们无法阻挡,但我们还能阻挡大部分的事情,不是么?

好像我其实本来还有更多的体会,没有记东西的习惯,以后记起来再加上吧.下面写些工作总结吧.
1. 生成代码时不要不设置项目的Netual Language,也不要设置成中文,至少目前不要这样设置,不然你在提交应用的时候会得到完全摸不着头脑的错误提示.如下图: