Xcode 5.1 不編譯 64bit 的方法

Xcode 升級到 5.1 後, Architectures 預設都會包含 arm64 ,若你之前是設定 armv7 armv7s ,竟然會變成 $(ARCHS_STANDARD_INCLUDING_64_BIT) ,預設值則變成 Standard architectures(armv7,armv7s,arm64) ,這兩個不管怎麼選都會包含 arm64。未選預設值編譯時也會出現建議你 Automatically Select Architectures 的黃色驚嘆號提示。




64biterror2

但是我使用的一些第三方 SDK 不支援 64bit ,例如 AdMob 與百度地圖,編譯時會出現以下錯誤訊息:
missing required architecture x86_64 in file
Undefined symbols for architecture x86_64

解決方法是 Architectures 選擇 Other... 刪除 $(ARCHS_STANDARD) 並輸入 armv7 armv7s ,這樣編譯時就不會包含 64bit 了。這只是暫時的解決方法,還是等第三方 SDK 出新版比較實在。

隱藏 navigation bar 的陰影底線

從 iOS 6 開始, navigation bar 最下方都有一條陰影。

在 iOS 6 上我都是使用偷吃步來處理,用 320*45px 的圖片蓋住1px的陰影。

[self.navigationController.navigationBar setBackgroundImage:[UIImage imageNamed:@"header.png"] forBarMetrics:UIBarMetricsDefault];


到了 iOS 7 上發現陰影永遠都在最上層,我把圖片改成 320*64px ( 多出的 20px 是 status bar),第一行方法名稱也換了。

[self.navigationController.navigationBar setBackgroundImage:[UIImage imageNamed:@"headerIos7.png"] forBarPosition:UIBarPositionAny barMetrics:UIBarMetricsDefault];
[self.navigationController.navigationBar setShadowImage:[UIImage new]];


這方法不適用於 setBackgroundColor ,因為 setShadowImage 似乎要與 setBackgroundImage 一起使用。

The app references non-public selectors in Payload ... id

此文章已經過期 SDK v4.0.1 之後變不再有此問題

這是一個在編譯時都沒甚麼徵兆,在上傳到 iTunes Connect 檢查才會冒出的警告。
雖然只是警告而非錯誤,怕審核不通過,所以還是處理一下。(好像也有人選擇註記在審核的欄位裡)

The app references non-public selectors in Payload/{Appname}.app/{App name]}: id

花了許多時間才發現是 Facebook SDK 惹的禍,原因是裡面的 property 名稱使用了保留字 id 造成的。
這問題好像存在很久了,只是 Facebook 一直沒去修正。
例如 FBGraphUser.h 這檔案打開來看...


@protocol FBGraphUser<FBGraphObject>
...
@property (retain, nonatomic) NSString *id;
...
@end

 

這樣的檔案不只一個,最簡單的修改方法就是用 [user objectForKey:@"id"] 或 user[@"id"] 來取代原來的 user.id。


/*
 * Callback for session changes.
 */
- (void)sessionStateChanged:(FBSession *)session
                      state:(FBSessionState) state
                      error:(NSError *)error
{
    switch (state) {
        case FBSessionStateOpen:
            if (!error) {
                // We have a valid session
                //NSLog(@"User session found");
                [FBRequestConnection
                 startForMeWithCompletionHandler:^(FBRequestConnection *connection,
                                                   NSDictionary<FBGraphUser> *user,
                                                   NSError *error) {
                     if (!error) {
                         self.loggedInUserID = [user objectForKey:@"id"];
                         self.loggedInSession = FBSession.activeSession;
                     }
                 }];
            }
            break;
        case FBSessionStateClosed:
        case FBSessionStateClosedLoginFailed:
            [FBSession.activeSession closeAndClearTokenInformation];
            break;
        default:
            break;
    }

    [[NSNotificationCenter defaultCenter]
     postNotificationName:FBSessionStateChangedNotification
     object:session];

    if (error) {
        UIAlertView *alertView = [[UIAlertView alloc]
                                  initWithTitle:@"Error"
                                  message:error.localizedDescription
                                  delegate:nil
                                  cancelButtonTitle:@"OK"
                                  otherButtonTitles:nil];
        [alertView show];
    }
}



這類錯誤警告只要用最後的關鍵字搜尋整個專案大概可以找到要改的地方,只不過以 id 這種前後都可以組很多單字就只能用猜的...

巴哈姆特板主申請攻略

本文只會提到申請表單填寫的部分,其他例如申請資格請到網頁查閱。
其中的該板近3個月10篇文章是有包括回覆,該板3篇好文請記得一定要選文章而非回覆。

 

自我介紹:除了基本介紹最好也提到有閒暇時間管理該板,若是有甚麼跟本板相關的專長加分條件也寫出來。

任職心得:若有擔任過板務才需填寫,我是寫目前管理的方式。

遊戲心得:就是指三篇以上對該板有貢獻的文章,一定是要自己生產或是經過整理的內容,轉貼資訊就免了。

您的動機:這裡寫的內容會公開,常見的是寫甚麼本板無人管理、精華區資訊過期,除此之外最好寫一些不一樣或是讓大家心動的內容。

抱負與期望:我是寫我心目中的本板走向,心目中的板友是甚麼樣子,反正越正面越好!

刪文規則:我是依照文章內容種類以及輕重分成兩大類,倒扣刪文及不倒扣刪文兩大類。

申論題:有兩題情境題,一是有語氣欠佳的板友對您的管理方式連續提出質疑,二是副板主與您意見相左,無法達成共識。
前者我是回答語氣欠佳只是表達方式錯誤,還是會聽聽看他的意見,也許能指出我管理上的盲點,但若是沒有言之有物甚至人身攻擊,則會以站規與板規來解釋。
後者我是回答先嘗試溝通,若他的意見比較好可直接拿來參考,或是做出兩個意見的折衷方案,但若是從根本上就是不同的方向,當然是以板主最後的決定為主。

 

三篇文章的選擇及表單內容的填寫非常重要,要寫得看起來很專業又有點嚴肅,不要有錯字及注音文。另外審核期間最好每天都去該板看看,能回文就回文,不知道是我錯覺還是怎樣,那幾天都會有幾個很老但上站次數很少的帳號會發文,疑似是這些審核人員的分身帳號。

獲取 App Store 指定 App 的詳細資訊

有兩種搜尋方式,一是用 bundle id ,二是用 app id 。
http://itunes.apple.com/tw/lookup?bundleId=com.twister.snakesandladders
http://itunes.apple.com/tw/lookup?id=489788712

以上兩組會吐出 json (內容不太一樣),請使用 json 閱讀器方便觀看。
我想那種追蹤 app 版本及售價應該是用這方法儲存資料到自己的資料庫。

若懶得寫提醒使用者升級的功能, iVersion 是個好選擇。

nsurl 網址拆解

    NSURL *url = [NSURL URLWithString:@"http://www.test.com/member/index.php?name=cat&age=6"];
    NSLog(@"%@", url.scheme);  // http
    NSLog(@"%@", url.host);  // www.test.com
    NSLog(@"%@", url.path);  // /member/index.php
    if ([url.pathComponents count] >= 2) {
        NSLog(@"%@", [url.pathComponents objectAtIndex:1]);  // member
    }
    NSLog(@"%@", url.lastPathComponent);  // index.php

子網域以及傳入的參數要自行處理。

Space Qube - My First Indie Game Adventure 筆記

本文是 2013 台北遊戲開發者論壇 的其中一個主題演講筆記

Space Qube - My First Indie Game Adventure
Owen Wu(Qubit Games 共同創辦人)

發想是給小孩玩的樂高編輯器,使用的是自製引擎,考慮到手機效能以無背景的太空射擊遊戲做出雛形。之後找了美術與音樂合作,做出融合復古風格與先進畫面技術的射擊遊戲,遊戲主打 play, create, share 。分享的角色除了可在 App 裡看到,也能在網站觀看,這使的分享範圍更廣了。更有趣的是還能把你做的角色透過3D列印實體化,連結提供3D列印服務的廠商,並寄到玩家的地址。

宣傳的部分,App Review 的網站都沒甚麼回應,社群網站有人看但是沒甚麼回覆,效果其實都不好,透過參加各項展覽、競賽知名度都有所提升,但最有效的還是上了App Store 的編輯精選。

下載量部分澳洲比預期的多,IAP則是日本、澳洲、印尼,其中印尼下載量少但是IAP金額很高。經過修改一些介面,IAP的營收也有改善。亞洲玩家普遍已經習慣免費,歐美雖然還有付費,但已經在萎縮,日本雖然花在IAP的很多,但都只玩免費的。

順便一提,我有參加過這遊戲的BETA喔,所以才知道 TestFlight 這個好用的工具。

Rayark開發經驗分享: 對APP遊戲的定位探討 筆記

本文是 2013 台北遊戲開發者論壇 的其中一個主題演講筆記

Rayark開發經驗分享: 對APP遊戲的定位探討
游名揚 (雷亞遊戲 製作人)

一開始提出遊戲欣賞值與互動值的概念,簡單說欣賞值比較像是聲光效果、顯而易見的東西,像是畫面、音樂、音效、人設、劇情...等等,使玩家更容易融入遊戲裡。而互動值則是像遊戲系統、耐玩度、收集要素、成長要素...等等可從中獲得成就感。

欣賞值由於不易複製,屬於高風險,互動值相對好複製,屬於低風險。由於技術一直在進步,聲光效果越來越好,核心玩家胃口已經被養大,欣賞值已占大部分。

在早期都是透過雜誌得知遊戲訊息,後來可以從實況或是遊戲社群網站取得資訊,直到智慧型手機的出現,遊戲市場出現變化,甚至出現新的休閒玩家,這些新興玩家可能都沒受到荼毒,所以對畫面的要求都不高,比較容易滿足。

由於手機效能不高,所以手機遊戲比較注重互動與社群,並且用免費或極低的價格吸引玩家玩再推到IAP,這種模式的成功使得越來越多使用類似系統的同類型遊戲出現,這類型的遊戲互動值佔一大部分。

而雷亞的作法是為每個作品找到定位,每款都有2~3個特點,與同類型的其他遊戲做出區隔。
Cytus 漂亮的畫面與超值的售價
Mandora 快速獲得樂趣、吸引人的收集要素(虛擬或實體)
Deemo 力道回饋的真實演奏、故事性
Implosion 家用機的畫面、硬派遊戲搬到手機

還特別提出 堅持到最後的 -1 刻,通常在完成90%時,剛好都是主管訂出的時限,若這時候堅持到100%,會有很多新的想法冒出來,但礙於產品的推出時程這些都不會加進去,以後可能也不會,這些想法若實現會使得產品變得更好,但這必須仰賴對開發團隊的信任與技術,同時是資助者也是開發者的雷亞這樣搞當然沒甚麼問題。

最後還提到免費榜競爭太激烈,所以 Cytus 才會選擇付費。(不過 Deemo 的 IAP 怎麼比較貴XD 雖然跟其他音樂遊戲比還是很佛心)