@property 的使用

在物件導向設計方法中我們會使用封裝來保護類別成員(成員亦包含了attribute與method),我們通常會寫method來存取attribute,命名為getter與setter,以下示範objective C的getter setter作法:

A.h

#import <Foundation/Foundation.h>

@interface A : NSObject {

int attr;

}

-(int)attr; //習慣上objective C不會在getter寫上get, 而是直接使用attribute作為getter

-(void)setAttr:(int)a;

@end

A.m

#import "A.h"

@implementation A

- (int)attr {

return self->attr; //原則上不加self也可以, 加了就可以跟method內的變數作區隔

}

-(void)setAttr: (int) a {

self->attr = a;

}

@end

當你使用以上的寫法作為getter與setter時,您在程式中使用實體物件時,就可以用"."的方式來作存取, 方在 assignment的左邊代表setter, 在右邊代表getter,示範如下:

main.m

#import <Foundation/Foundation.h>

#import "A.h"

int main(int argc, const char * argv[]) {

A *a = [A alloc];

[a.attr 30]; // assign 30 給這個物件的attribute

printf("The attribute of A is %d", a.attr); //取出a.attr的值, 會印出The attribute of A is 30

[a release];

}

是不是每次都要用傳統的作法才能達成"."的取用呢? 其實Objective C安排了一個比較簡單的作法,就是@property,那為甚麼要先介紹上面的做法呢?很簡單因為使用任何捷徑都應該先知道他的原理吧?知道了原理未來才不會在debug中苦哈哈。使用@property的寫法如下:

A.h

#import <Foundation/Foundation.h>

@interface A : NSObject {

int attr;

}

@property int attr; //這樣就會自動建立gettery與setter

@end

A.m

#import "A.h"

@implementation A

@synthesize attr; // 舊版的xcode需要成雙寫property與synthesize,新版的只要寫property其實就可以了,

//synthesize可以讓你改property的名字, 寫法是 @synthesize attr = ppp; (就改成ppp了)

@end

main.m

#import <Foundation/Foundation.h>

#import "A.h"

int main(int argc, const char * argv[]) {

A *a = [A alloc];

[a.attr 30]; // 一樣可以使用

printf("The attribute of A is %d", a.attr); //取出a.attr的值, 會印出The attribute of A is 30

[a release];

}

基本上使用@property 會自動作三件事情:

  1. 建立了 setPropertyName (setter)
  2. 建立了 propertyName (getter)
  3. 建立了 propertyName (attribute)
*這些method是可以被override的, 所以使用了@property後, 你也可以改寫成自己想用的方式。
@property的設定 //用來設定property的參數
讀寫控制
  1. readwrite (預設): 可以讀寫,setter和getter方法都會自動加入
  2. readonly: 只能讀, 只會加getter的方法

setter相關部分

  1. assign(預設): 用於只會和可量度的數值作用的情況, _abc = b;
  2. retain/strong 在指定時會呼叫物件的retain指令, 然後前一個數值會release掉
  3. copy: 在指定時會呼叫物件的copy指令, 然後前一個數值會release掉 (一定要實作NSCopy的Protocol, 否則會掛點)
atomicity (單一性)
  1. atomic (預設): 會讓屬性有執行緒安全(thread-safe)的特性
  2. nonatomic: synthesize的存取者會直接回傳數值

基礎

  1. Objective C其實是C的superset,所有之前學過的C語言語法在Objective C裡面都可以使用,而Objective C為C增加了一些功能。
  2. 學習Objective C有個要注意的地方,它不像.NET與JAVA那樣會有系統作Garbage Collection,一切記憶體管理都要自己來。
  3. 建議在建立Objective C專案的時候不要使用Automatic Reference Counting,因為他並不是像Garbage Collection那麼的自動化,純粹只是在編譯的時候幫你加一些跟記憶體相關的statement而已,處理不好可能還會造成memory的問題。
  4. 為甚麼Objective C的NSString,NSOject這些物件前面都有"NS"? 其實NS的是"NeXtStep" 的縮寫, 由這家公司所開發的程式語言。
  5. Nil 與 Null的差別?Nil是一個物件,他可以被操作[nil message],但NULL就是一個空物件,操作空的物件程式會死掉,但nil不會。
  6. include的部分 < … > 與 ""…"" 的差別? 前者是系統提供的.h檔,後者是使用自己建立的。
  7. NSLog 與 printf 的差別? NSLog 是真的會寫進程式日誌檔,所以如果只是平常程式debug其實可以用printf (如果不是寫iOS的話)
  8. NSString 的表示方法 @"…" 與 C的char array 用法完全不同, 不能當成同一種東西。
  9. 變數的命名要有意義,原則上如果程式碼寫得夠好,它本身就是一個註解。

使用方法 Method

  1. [myObject someMethod:argument];
  2. 它不像JAVA是用 "." (如 myObject.someMethod), "." 在Objective C有別的意義存在,稍後會解釋。
  3. Method的參數寫法相當特別,它的原意是希望整個Method念起來就像一個句子一樣,參數之間用空格間隔,格式如下:
    -(void)setBrand:(NSString *)brandname isA:(NSString *)type whichcost:(int) price;

Header File

  1. 用來宣告這個物件/協定有哪些成員(如attribute與method),記得在Objective C中不能制定初值(慣性上會在init裡面作初值的指定)
  2. 格式如下:(import後面不需要分號), attribute都是包在{ }之間,method寫在{}之後,"-" 代表的是實體方法。"+"代表的是靜態方法
#import <Foundation/Foundation.h>
@interface A : NSObject {
NSString *brand;
CGFloat size;
BOOL power;
NSDate *creationDate;
}
-(void)ma;
@end
補充: 一般上我們的認知是void是一種不會回傳東西的方法,但事實上(void)本身就是一個型態,回傳的也是void。

建立實體物件的方式

  1. 儘量不要用 new, 用 alloc, 因為 new 其實包含了兩個動作: alloc 加 init, 並不是所有的物件都會以init開始, 可能會initWithXXX, 所以與其這樣不如就自己alloc之後再挑init的方法,我們常看到的寫法就會這樣:
A *a = [[A alloc] init];
[a release]; //物件都要記得release, 他們會成對出現

婚禮APP提供新人更多的便利性

舉辦婚禮是新人一輩子最重要的事,從過去的婚禮佈置、婚禮相簿、婚禮MV、到婚禮小物,都是新人在婚禮中不可或缺的籌備項目之一。在行動市場逐漸擴大的同時,婚禮APP也即將成為新人的焦點。香港藝人周家蔚就曾在婚禮中花費港幣20萬元量身訂作自己的婚禮APP,提供給自己的親友使用。現在行動應用正夯,在台灣與香港已經有廠商陸續推出與婚禮有關的行動APP,打算搭上這波智慧型手機普及率節節攀高的趨勢。在台灣作婚禮APP的廠商主要有三家,在截稿為止(三大廠商都有可能在日後做變動或更新),我們可以來比較看看這三家的差別,新人消費者應該如何作選購?

享幸福典藏APP 愛婚享 inWedding
產品定位 電子喜帖 相簿 賓客統計 互動 電子相簿 電子喜帖 相簿 互動
iPhone 支援 支援 支援
Android 支援 支援 支援 4.x 以上
iPad 支援 支援 支援
Android Pad 支援 支援 部分支援
PC網頁瀏覽 支援 支援 不支援
親友下載方式 Appstore, GooglePlay, 官網下載, 掃描QRCODE安裝, 可公開/新人可決定是否要輸入密語 掃描QRCODE安裝後輸入關鍵字 Appstore, GooglePlay安裝後輸入關鍵字
相簿功能 照片分類彈性大 相簿模板變化較多 照片分類固定
照片數量 相簿15本,相片750張 35張 52張+30張自我介紹照
留言數量 不限 無法留言 9999篇
大頭貼照相 支援 不支援 不支援
賓客統計功能 支援 不支援 不支援
地圖導覽 支援 不支援 支援
婚禮倒數 支援 不支援 不支援
現場刮刮樂 不支援 不支援 支援
婚禮現場即時訊息 支援 不支援 支援
照片和活動內容可隨時更改增刪 透過瀏覽器即可編輯 不支援 需要另外下載Ourinwedding App做編輯
離線瀏覽 不支援 支援 支援
贈品 桌卡20張/捧花/謝卡200張 選一 謝卡200張 支援
網站公布售價* NT3999 NT1999 NT3999

*視促銷方案而定

有人說尋找創業夥伴就如找夫妻,你每天都會跟他朝夕相處待在同一個空間,完成一個共同的目標。有些人會找跟自己背景相似的人來創業,這樣討論起來容易互相理解,也可以一起解決問題;亦有一些人會找跟自己背景不同的人,以補足自己缺乏的知識領域。兩種模式沒有好壞,完全看創辦人本身的個性。

就我個人而言我理想中的創業夥伴應該要具有以下的特徵:

1. 創業的過程一定會有很多的pivot,所有關於公司營運方向的想法都能與夥伴們討論,非擅自作主,最重要是要集體達成共識,創業團隊的價值觀要一致,在短,中,長的目標能夠達成統一。最好是能夠以商業模式圖作為共同的語言。

2. 創業過程一定會遇到誘惑:如曝光的合作機會,其他公司的外包等等。如果公司是以開發自己的平台為目標就應該專注在公司的產品上,而非花費過多的時間去幫助其他公司開發產品。

3. 意見相左也應該聆聽夥伴的意見,如果夥伴中的組長無法接受其他組員的意見,往往會造成其他夥伴失去了提供意見的動力。多向你的夥伴問:「你的看法如何?」他一定會覺得你尊重他。

4. 創業夥伴能在處事風格之間互補,如深謀遠慮人才與執行力人才;分別在技術,市場,營運等環節能獨當一面:必須先是一個優秀的經理人,才能做好創業者的角色。
5. 大家的貢獻要能夠讓彼此感到平衡;不能某人做比較多,某人做比較少;這樣就很容易造成團隊的不平衡。我知道有些東西是很難用「看」跟「感覺」去衡量的,所以每周報告自己對團隊的貢獻就變得很重要了,如果每次會議都保持沉默,誰會知道你對團隊付出了甚麼?

6. 團隊各司其職,各自扮演好自己的角色,最好能先完成給團隊一個榜樣看,證明自己的能力後再進行管理;不應該甚麼事情都請別人處理,尤其指派一些重要的任務其他人去負責,或制定一些不可能達成的KPI,只會讓其他人對公司愈感灰心。

7. 不會公器私用:公司的員工也是公司的財產,若指派公司的員工來處理自己的私事(尤其在上班時間)更會讓其他創業夥伴覺得很不可靠。

其實在沒有共同經歷創業的艱苦磨合之前,是很難真正判斷一個創業夥伴是否適合自己,很多時候往往是不經一事,不長一智。創業者需要做出決定和選擇,有時候需要先「同居」,往後的日子互相磨合後考慮是再「結婚」。

到KTV唱歌是現代人不可或缺的娛樂之一,好朋友三五成群到KTV唱歌就是想好好展現自己的歌喉或是宣洩平日在工作上的壓力。到KTV唱歌最重要的就是點歌系統了,KTV從過去的翻簿子點歌到後來的數位點歌幫助了人們可以快速找到新歌,也讓業者有新歌可以直接上傳到系統即可,不需要花太多錢在印刷上。

數位點歌還有很多優點。你可以看到你點過的歌曲,可以隨時插播,可以快速的透過歌手名字找到歌曲,可以看到點播率最高的熱門歌曲等等。

在台灣去好樂迪點播歌曲時,我們的搜尋順序是 歌手 > 男女歌手 > 筆畫 > 歌曲。要找歌手時得一邊用手畫在腿上,一邊口中碎碎念出筆畫的順序,這樣做可以找到我們要找的歌手,但有時候筆畫算出來後未必能夠直接找到我們要找的歌手,因為很多姓氏的筆畫數是相同的。好樂迪還有一個最令我困擾的功能是插播,一旦進入要播放的前三首歌曲,你就不能預先取消或插播 (可是明明就還沒到這個歌曲,為甚麼不能取消),可見點播系統跟播放系統的同步作業是有很大的時間差的。往往我們不小心點錯的歌曲都必須得在播放的時候再按下"切歌" 來切換下一首。(但這樣就浪費了一些時間啦)

不久後台北出現了星據點,除了吃的部分有更多的選擇外,對於客戶點歌的便利性有考量到更多,你可以在房間的周邊看到小小的觸控螢幕,方便其他的USER不用越過重重人群,只為了跑到點歌系統前點歌,增加了點播的便利性。不過在,在找歌手點歌的部分還不是最佳的。

今年過年回到了馬來西亞新山的KTV 大嘴叭消費,發現大嘴叭的點播系統真的太強大了(比起去年看到的系統更新了不少)。搜尋歌曲的方式除了維持傳統的歌星搜尋外,亦增加了歌手的分類,讓你可以直接分類華人歌手,國外歌手等等;如果不想要一個個瀏覽,你可以使用輸入的方式來搜尋歌曲,我們就不用再大費周章算筆畫啦!你可以用漢語拼音或直接在觸控式螢幕上手寫輸入你要找的歌手或歌曲。(手寫輸入真的很讚,將搜尋歌手的時間降得更低)

一個系統的使用者介面可以看出業者對於客戶的用心。好樂迪也許是最先進入KTV市場的業者,由於系統太久都沒有更新,所以很容易就被後起之秀追過了。星據點在餐飲的服務上有幫消費者考量更多,點歌系統的功能亦比好樂迪更強更友善。大嘴叭的UI背景雖然FANCY了一些(介面的按鈕很多,可能對於很多人來說會很雜亂),但是我用得最友善,最容易找到我想找的點播系統。

每個行業都應該為自己的客戶提供更棒服務,才有辦法提升整體的服務品質,去年與今年兩次到大嘴叭消費我看到明顯的進步,很高興看到馬來西亞的KTV業者有這樣的成長。

色彩對比

在開發網站經驗中,我們有時候希望能讓使用者能夠擁有更多的控制權,如讓使用者自行修改網站的背景顏色或字體顏色,若您遇到的使用者是熟悉網站顏色搭配的則通常不會有太大的問題,但當你遇到不太會配色的使用者時,配出來的字體顏色與背景顏色太接近,造成網站的可讀性降低,不只流失了拜訪者,也讓你的網站整體美感變得不好。

若你的會員有上千個,我們總不可能逐個頁面去檢查配色吧? 這個時候就需要一個"色彩對比分析演算法" 來解決這個問題。

對顏色熟悉的朋友都知道在RGB顏色模式中, R代表RED, G代表GREEN, B代表BLUE,若以rgb(x,y,z) 作為顏色產生的含數來看,x,y,z 的值必須介於0-255之間。紅色代表rgb(255,0,0), 綠色代表(0,255,0),…以此類推。

假設使用者輸入了兩種顏色,你想要知道這兩個顏色的配色是否恰當,根據W3C的建議,我們可以使用以下演算法

我們主要透過兩個指標來判斷,分別是:亮度差異色彩差異

W3C 所建議的亮度差異應大於 125, 而色彩差異則應大於 500(也有人建議400)。若兩色比對的結果小於這些指標則表示不符合。

色彩亮度公式
色彩亮度係以下列公式計算所得:
((紅色值 X 299) + (綠色值 X 587) + (藍色值 X 114)) / 1000
背景色亮度與前景色亮度的差異應大於 125.
註: 這個演算法係由轉換 RGB 值為 YIQ 值的公式中所取得. 這個亮度值得出了色彩的知覺亮度.

色彩差異公式
色彩差異係以下列公式計算所得:
((紅色值 1, 紅色值 2) 的最大值 - (紅色值 1, 紅色值 2) 的最小值 ) + ((綠色值 1, 綠色值 2) 的最大值 - (綠色值 1, 綠色值 2) 的最小值 ) + ((藍色值 1, 藍色值 2) 的最大值 - (藍色值 1, 藍色值 2) 的最小值 )
背景色與前景色的色彩差異應大於 500.

 

參考資料:

1. 親和資訊解決方案 http://ais.z6i.org/web/resources/contrast_analyser/

這幾天在Facebook看到朋友分享了一張圖片,
覺得對網站管理應該滿有幫助的,
於是花了一些時間去研究這兩種Test的使用時機.
這張圖是長這個樣子的 (圖片取自: https://www.facebook.com/UXLabsIndia)

AB Test And usability
AB Testing 與 Usability Testing 的使用時機

 

HOW MANY

當你想知道一件事情的效率有多高, 有多好, 或者比較兩個活動所帶來的效益時, 我們會用A/B Testing來做測試,在Google上搜尋, 可以找到Google Adsense對於 A/B Testing的定義如下:

A/B 測試是指測試兩種 (或多種) 不同情況的成效:情況 A 或情況 B。要找出哪一種 AdSense 廣告設計可為您帶來最多收益,A/B 測試就是您的最佳選擇。舉例來說,您可以測試「戶外」色調和「海濱」色調,看看哪一種成效比較好,或是拿 728×90 超級橫幅廣告與小型 468×60 橫幅廣告做比較。

那麼 A/B 測試要如何進行呢?有兩個重點:

-兩種情況之間只能有一個相異的部分
-這兩種情況必須同時執行

當我們對自己的網站做一些行銷活動的時候,如:發送電子報,會想知道這些活動所帶來的效益。試想狀況如下:我在電子報中放了三個不同的按鈕(每個按鈕都是不同的活動圖片),透過統計這些按鈕被點擊的次數來了解客戶的喜好,這種時候就適合使用A/B測試。

WHY

那甚麼時候我們會用到"可用性測試" Usability Test呢? 當你的問題是屬於"為甚麼"的時候。如:為甚麼使用者不是用我的應用程式?為甚麼使用者不進行註冊來留言?等等諸如此類的問題,可用性測試就能夠為您的問題提供一些答案。

根據維基百科的,可用性測試的定義如下:

可用性測試(Usability testing),是一項通過用戶的使用來評估產品的技術,由於它反應了用戶的真實使用經驗,所以可以視為一種不可或缺的可用性檢驗過程。也就是說,可用性測試是指讓用戶使用產品(服務)的設計原型或者成品,通過觀察,記錄和分析用戶的行為和感受,以改善產品(服務)可用性的一系列方法。它適用於產品(服務)前期設計開發,中期改進和後期維護完善的各個階段,是用戶中心設計的思想的重要體現。
可用性測試是可用性評估方法中最為常用的一種,作為人機互動研究的一個重要領域,已經被廣泛研究。

簡單來說,其實我們常把Google Analytics的Tracking Code安裝到網站中,透過GA後台就可以看到很多使用者的使用數據(亦包含了使用者網站流程),幹這些事其實目的就是為了做可用性測試,看看你的網站到訪者到底有多「黏」你的網站。黏度越高表示你提供的內容對使用者來說是有價值的。跳出率(Bounce Rate)越高代表了你的網站雖然吸引人點了進來, 但很快就跳出去了(表示內容不符合期望)。透過不斷的分析與調整,我們可以從數字看出一些端倪,了解使用者離開或停留或使用的原因,以提高網站的「易用性」與「轉換率」。

在GOOGLE找到了一篇關於設計簡單快速的可用性測試供大家參考:http://uedc.163.com/4151.html

當各大智慧型手機大廠正在爭奪市占率的同時,
內容提供者也一直在思考到底應該投資於Android還是iOS,
亦有些企業選擇同時開發兩種平台, 但開發手機App其實需要投入不少的資源.
為了讓不擅程式開發的內容提供者能夠快速的擁有自己的App,
Miiroad提供了一個免費且方便的平台, 讓內容提供者迅速跨入Social-Local-Mobile (社群-位置服務-行動)的領域.

Miiroad提供了幾種模板讓使用者選擇: 商店, 活動, 診所, 甚至目前最流行的婚禮APP也能夠在Miiroad上找到.

婚禮APP
使用Miiroad的服務可以讓您的婚禮更添創意

 

目前為市場推廣期,招募結婚新人大放送,開放給50對新人,
可以免費幫新人做一支專屬於的婚禮app,(價值3999元)做為宣傳用,
這支app有報名喜宴的功能和分享婚紗照及塗鴉牆等等功能,
當然您也會免費擁有這支app,還可以獲得統一超商200圓禮卷,
如果您有意願,請林小姐 iris聯絡: 02-8219-2977

http://www.wretch.cc/blog/miiroad
http://www.wretch.cc/blog/miiroad/21703320
http://www.miiroad.com/wedding-app.php

婚禮APP是現在越來越流行的結婚夯物
從之前流行的流行電子婚帖
到雙方的成長MV.感恩MV……等
現在有結合新人的感人成長故事.新人的美美婚紗照.電子婚帖….等
更可以讓新人的親友團們直接透過手機平板直接留言變成小型親友論壇
也可以讓親友直接在APP裡上傳親友們在結訂婚當天所拍的照片
讓新人可以輕輕鬆鬆收集屬於自己那天的幸福
迷路的[享幸福APP] 更提供報名功能
讓新人可以直接利用手機及平板來統計欲要參加結訂婚的親友數量或是特殊飲食狀況

/usr/share/zoneinfo
透過上述指令可以看出此主機的時區資訊

更換時區的方式:

# 不正確的時間
$ date
Wed Oct 1 07:43:58 CDT 2008
#
# 解決方式
#
$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Asia/Taipei /etc/localtime
#
# 變正常了
#
$ date
Wed Oct 1 12:42:33 GMT 2008

#不要忘記重啟其他的服務
# service mysqld restart
# service httpd restart