微信小程序開發備忘
小程序開發已經用三脚貓功夫做了一些粗略的實現，接下來就是學習這個技術框架中的細節，并且返工之前粗略、粗糙的地方。今天學習了一下幾個技術技巧： 一、子控件向父控件發送帶參數事件消息 頁面上的button按鈕是我做的一個子控件、這個按鈕是放在panel控件中的。現在我想點擊button按鈕的時候，button按鈕完成響應、并將事件通知給panel，由panel接收並繼續處理事件。 此前的實現非常拙劣，就是只使用panel進行事件的處理： 這樣做的壞處是顯然的：觸摸會發生在整個panel中。而我希望的是觸摸僅由裏面的button受理。改造過程如下： 1、首先panel的頁面層，調整代碼如下： 這樣調整之後，panel不再接受bind:tap消息，而是會接收名爲customEvent的事件，一旦接收到customEvent事件，則進行running執行。此時的customEvent事件將由button發出，所以button的代碼寫成下面的形式： 這樣只要點擊了button，就會運行sendEvent方法，這個方法内實現向父層發出消息的過程，具體js代碼是： 通過triggerEvent發出了一個customEvent事件，父控件因爲綁定了這個事件、接收到並開始處理就可以了。 二、動態成員訪問的方法 類似如下的PHP代碼： 在JavaScript中的實現方式是： 三、控件數據初始化 微信小程序的components控件，似乎沒有（我不確定）如pages頁面那樣的onLoad()方法，儅加載了一個小控件之後，向這個控件中傳入一些初始變量，便沒有辦法找到一個Init()或onLoad()的地方，對這些傳進來的變量進行預處理、以被在頁面上使用。 此時可以使用控件的observers監聽服務，對傳遞進來的變量進行監控，一旦傳遞進來的變量生效，observers服務啓動，以便進行數據的預處理操作。具體代碼如下： 四、頁面中的if/else流控方式 此前頁面中一直是這麽寫： 現在有了更好的方法： 雖然在頁面上的if/else流控寫法我已經瞭解了，但感覺并不如C/C++那樣直觀，總感覺有些奇怪，擔心它的嵌套不準確。不過也不重要，總之今天掌握的，就是這些。
着手开始基于微信小程序的APP开发
虽然我对《又大又杂的APP》充满了厌恶，但既然已经答应了朋友，无论如何也只好硬着头皮开始了这个微信小程序的开发。才开始两天，就发现真的是太痛苦了。整个项目杂乱、庞大，而且连基本的规则都是混乱的。 它期望利用微信小程序完成一个SNS社交平台类应用的构建，这几乎就可以看作是痴人说梦，甚至可以说是“梦中梦中梦”。 微信其实就已经是“梦中梦”了，原本微信只应是一个IM工具，而诸如社交、分享、朋友圈的功能，应该是分散在手机系统的各个APP中，然而微信却将这所有的功能整合到了一个应用中，好像在手机系统中嵌入了一个子系统，加之微信提供的公众号、服务号、小程序等扩展能力，它真的可以完成“梦中梦”的实现。 然而我那个朋友想做的APP，是一款宠物兴趣人群的SNS应用，但他却只想在微信的小程序中实现，他的理由很简单：小程序开发成本低、推广起来用户基础好。 但是他想做的本身也是一个平台级应用，例如：这个应用是具有SNS属性的、拥有SNS属性就意味着有好友关系、好友之间能够进行短信短消息的交换…… 如此一来，相当于你打开手机之后想分享一个照片，不需要使用手机中的、成熟的SNS社区，只要进入微信那个“子系统”就可以操作了。 而当你想将自己的猫咪日常生活分享给你的“猫咪好友”时，这个好友其实即不再某个SNS平台中、也不再微信中、而是在微信的小程序的某个小程序服务商列表中，于是你就要：打开手机、进入微信、启动小程序，使用这个小程序APP分享照片。这不就是“梦中梦中梦”么？ 我自己的电脑性能差、手机性能也很差，所以平日中我使用微信都比较费劲、卡顿的，有些时候去商场买东西必须使用店家的小程序时我总会皱眉——几乎可以肯定很难快速启动他们的小程序，几乎可以肯定大概率会加载慢、崩溃。而那些商家的小程序其实功能还算简单、页面也不复杂呢。 我现在都可以想象出朋友那个宠物SNS小程序，果真实现出来之后将会何其缓慢、问题重重。 事实上，它很可能实现不出来，因为是我在开发这个APP呀，我的电脑老旧得甚至连开发者工具都运行不起来。只一个非常简单的页面组件的开发，都会崩溃好几次。所以两天下来，连一个页面都没有完成。如此缓慢的进度，想实现出来？又是有点儿“痴人说梦”了。 开发过程的技术细节我觉得到没什么太多可以记录的，至少现在还没有遇到值得记录的内容。毕竟现在刚刚开始，只是做了一些基本的页面，而这些页面也就只是html代码和css样式的编写，其中不存在什么高新技术。 如果往后的日子里，这个项目能够持续开发，并且真能向着最终目标一点点的前行，那我就将开发过程中遇到的问题、值得写上几笔的地方，当作日记记录在这里，也方便自己今后回顾这段“痛苦不堪”的帮忙经历吧。
我对又大又杂的APP一点兴趣也没有
朋友拜托我做一个新的网络应用，是要基于小程序进行开发。但是我看了一下原型设计，又大又杂。本来只是一个很小的网络服务，非要做的好像一个门户、好像一个社区一样，臃肿无比，这是令我反感且毫无兴趣的。 如果不是因为抹不开面子，我是一定不会做这样的门户级应用的。原因在于：你做的像个门户，却没有足够多的内容支撑其内容，有没有足够的技术支撑其底层，最后就一定会烂尾。即便有足够的内容和技术将它强行的承托起来，但这样的门户感给人的感觉就是专业和庞大，这种“装”出来的庞大，如果没有真实的用户基础，依然会在运营过程中渐渐的枯萎、最终无疾而终。 所以这样的项目基本上是三岁看老，一眼就能看到头的。 我更喜欢小巧的、纯粹的、单一的服务，一个事情就是一个功能，一个功能就是一个应用。但这样形态的产品现在好像不吃香，至少在我生活的地方不吃香，大家都更喜欢大而全。 花里胡哨的华丽，是他们更喜欢的，在他们看来这才叫“应用”。这样的应用我曾经不知道做过多少，但这么多年下来，一个活着都没有，导致我在自己的“成功案例”里面完全是空白的。有的时候甲方会问我为什么没有成功案例，我怎么回答呢？全都死掉了？如果这样回答，甲方一定会觉得我做的不行、或者我骗人其实从来没有做过，所以最终谈项目的时候会荒掉。 如此陷入的就是恶性循环，累死累活不说，还总也没有拿得出手的东西，没有成功的作品。但事实就是这样。 这次朋友找到我，我就和他说的十分明白，一定要小而精，一定要纯粹。他答应的好好的，结果今天原型图出来给到我，我头就大了。这那里是小而精了？ 产品原型规划中，仅仅APP端的业务页面就有173个，还不计后台、接口层，只是单纯的前端数据展现页面，不是那种可以复用的、而是彼此毫无无用关系的，每个页面都是独立功能的，整整173个不同的数据类型和相关的展现页面！！！ 除了慢慢的一屏幕的SNS味道，还有无数的通栏广告位，还有各种点赞与收藏的机制，还有分享，还有开屏广告……这不是小程序，这活生生的又是一个巨大的门户网站啊！ 没有办法，只能硬着头皮答应朋友做。2个月之后交工。这个工期其实也十分的扯，因为我们约定的是个“小程序”，所以2个月其实时间上都比较长了。但实际上他最终要的东西是个门户，我内心估计至少需要4-6个月才能有个模样。可是当我说出需要3个月的时候（这还是我咬着牙说出来的），朋友已经瞠目结舌，问为什么一个“小程序”需要那么长的时间？ 这种尴尬的时刻，再多的解释其实都没有意义，解释的多了反而徒增烦恼，所以我就垂头丧气的告诉他那就加加班、2个月做出来吧。其实看得出来，当他听到“2个月”时，还是觉得太久了，但朋友终究没有再压缩时间，只是说尽量赶。我心想：这样赶出来的，能是什么狗熊样子呢？ 翻翻自己曾经做过的项目，拿一个差不多的出来给他改吧，反正这个项目我也不看好。如果真的能够（几乎不可能）做出一些客户和流量来，我再对细节进行返工就是了。但我现在的估计是——指不定又是那个天使倒霉蛋儿，要亏钱了。