iPhnoe Nano !!?
版主: bryanchang、jimmy1019、Bianca
- bryanchang
- 討論區管理員
- 文章: 7057
- 註冊時間: 04/19/2001 1:01 am
- 來自: The '60s
- 聯繫:
我是不知道有沒有什麼 iPhone nano or iPhone shuffle, 但是用 iPhone SDK 寫的軟體,只要是按照正規方式寫的軟體,螢幕解析度改變沒有什麼關係。yr 寫:簡單的解釋一下這應該不太可能發生的原因:所有 App store 的程式都要重寫後才能拿來用。
除非螢幕縮小了,解析度還是一樣,不然 App store 的程式都要改過,才能放進去那個螢幕,而這是一個很大的工程,那些寫程式的有沒有意願維持兩個版本的程式也是很難說。
預測:應該不太可能推出,如果有推出,可能沒辦法用 App Store ,只能用 Apple 提供的程式,這樣就降低很多購買的吸引力了,銷售量也不會很好,那 Apple 幹嘛推出一個可以預知銷售量不好的產品呢?

關係大了,用 TapDefense 這個遊戲來作說明好了,整個遊戲畫面的大小就是剛好跟 iPhone 一樣,如果畫面解析度變了,在不犧牲畫面清晰度的情況下,那只能呈現部份畫面,多出來的部份只好截掉。如果要做 scaling ,那麼很多東西(箭塔、惡魔等等)都會變成一小團,後果就是看不清楚到底是什麼東西。bryanchang 寫:我是不知道有沒有什麼 iPhone nano or iPhone shuffle, 但是用 iPhone SDK 寫的軟體,只要是按照正規方式寫的軟體,螢幕解析度改變沒有什麼關係。yr 寫:簡單的解釋一下這應該不太可能發生的原因:所有 App store 的程式都要重寫後才能拿來用。
除非螢幕縮小了,解析度還是一樣,不然 App store 的程式都要改過,才能放進去那個螢幕,而這是一個很大的工程,那些寫程式的有沒有意願維持兩個版本的程式也是很難說。
預測:應該不太可能推出,如果有推出,可能沒辦法用 App Store ,只能用 Apple 提供的程式,這樣就降低很多購買的吸引力了,銷售量也不會很好,那 Apple 幹嘛推出一個可以預知銷售量不好的產品呢?
其他用 cocoa touch 做的使用者界面也是,就拿很多應用程式最下面都會有的工具列來說好了,五個按鈕在最下面擺成一排,剛剛好是螢幕的寬度,螢幕解析度變小之後,解決方案也是跟遊戲差不多,不是截掉就是對應螢幕的大小坐 scaling ,這些圖示都是一個檔案裡的一個像素對應螢幕上的一個像素,那麼縮了以後的後果跟上面提到的遊戲是一樣的,最根本的解決之道就是重新設計該程式的 UI layout 給解析度比較小的螢幕用。
原圖
長寬各變成 70% ,勉強還算清楚
截掉變成 70% (用 scroll 滾到其他沒顯示的區域?相信我你不會想這樣玩)
最後由 yr 於 12/17/2008 4:10 am 編輯,總共編輯了 1 次。
- bryanchang
- 討論區管理員
- 文章: 7057
- 註冊時間: 04/19/2001 1:01 am
- 來自: The '60s
- 聯繫:
跑是當然有辦法弄到可以跑,但是使用者能不能『用』是另一回事,如果要比喻,這就像十幾年前,有些在 DOS 下面的彩色遊戲,沒有用先跑類似 Magickey 的程式模擬 CGA ,就直接跑,程式的確是可以跑,但是單色螢幕顯示的就是一堆雜訊,比較厲害的可以聽聲辨位,還是可以玩。bryanchang 寫:我不覺得我們兩人講的有什麼關連。你這邊提的是螢幕影像大小問題。我講的則是程式的相容性問題。iPhone 的螢幕未來要是變大 100%,現在寫的程式還是可以照跑,至於影像大小則是另外一回事。yr 寫: 關係大了,用 TapDefense 這個遊戲來作說明好了,整個遊戲畫面的大小就是剛好跟 iPhone 一樣,如果畫面解析度變了,在不犧牲畫面清晰度的情況下,那只能呈現部份畫面,多出來的部份只好截掉。如果要做 scaling ,那麼很多東西(箭塔、惡魔等等)都會變成一小團,後果就是看不清楚到底是什麼東西。
如果使用者界面顯示的正確性不是相容性的一部份,那你絕對是對的。
- bryanchang
- 討論區管理員
- 文章: 7057
- 註冊時間: 04/19/2001 1:01 am
- 來自: The '60s
- 聯繫:
這樣說好了,下面這個是 Interface Builder 產生的界面程式碼的其中一行。bryanchang 寫:我蠻確定要是螢幕解析度變了,SDK 裡的使用者介面一定可以根據機種繼續正確顯示。yr 寫:如果使用者界面顯示的正確性不是相容性的一部份,那你絕對是對的。
反觀自己煉出來的訂製介面 (Custom View),要是作者在寫程式的時候沒有考慮過未來螢幕大小可能會改變,那在不同機器上那自然是要改版,這點也沒什麼好說的。寫 Mac OS X 的軟體就沒聽說有人要擔心軟體在 13" MacBook 或是在 30" 螢幕上跑會有什麼介面要重寫的問題。
<string key="NSFrame">{{0, 44}, {320, 216}}</string>
這行是描述一個元件的大小與位置, (0,44) 是該元件左上角的位置, (320,216) 是右下角的位置,螢幕大小一變,旁邊就會被裁切掉了。
Mac OS X 是一種視窗系統,大多數視窗大小是可以隨著使用者的喜好來調整大小,所以如果程式的視窗大小可以改變,那麼程式開發者會在程式裡面會有處理視窗重繪的部份,所以問題比較不是那麼大。但是 iPhone/iPod touch 並不是使用視窗為概念來設計程式,頂多只有直立跟橫放的概念,而且這部份也是都由程式來控制,並不是作業系統自己幫你把畫面改成橫的,而是要由程式設計者來人工決定橫放後視窗該長什麼樣子。
其實在 Mac OS X 上面也是有這個問題,連 Apple 自己的程式都會有類似的狀況會發生,最簡單的例子就是打開你的 System Preferences ,然後選 Displays ,接著把解析度改成 640 x 480 ,你就可以看到你從來沒聽過傳說中因為螢幕大小不一樣界面要重寫的例子,如果 Apple 把視窗弄長一點,把最下面那個 check box 放得更下面一點,那它還會跑到螢幕外面,按都按不到,因為視窗沒辦法往上拉到更高,不過現在螢幕解析度只會變更大,不會變更小,所以 Apple 並不會認為這會是個問題。如果 iPhone 螢幕解析度變低,那麼情況就跟這個很類似了,程式的界面不改一下,就會影響使用者的操作。
- bryanchang
- 討論區管理員
- 文章: 7057
- 註冊時間: 04/19/2001 1:01 am
- 來自: The '60s
- 聯繫:
你要是用 IB 設計版面時正確的設定元件與螢幕四邊相對關係的話,螢幕變大變小自然東西不會亂跑。yr 寫:
這樣說好了,下面這個是 Interface Builder 產生的界面程式碼的其中一行。
<string key="NSFrame">{{0, 44}, {320, 216}}</string>
這行是描述一個元件的大小與位置, (0,44) 是該元件左上角的位置, (320,216) 是右下角的位置,螢幕大小一變,旁邊就會被裁切掉了。
之前我就說過,要是用 Cocoa 正規寫法的話,在產生 view 之前去叫 [UIScreen mainScreen] 自然馬上就會知道目前螢幕大小。接著再自己看要怎樣讓每個 View 根據螢幕尺寸相對調整在 Frame 裡 SubView 大小。
寫程式的時候多花點時間在這些細節上,以後才不會被不同的硬體搞得哇哇叫。
你講的是程式已經啟動後才改變螢幕解析度,我說的則是軟體在啟動時自動調整大小。在 iPhone 沒有動態改變螢幕解析度功能之前,談這麼多題外話實在沒什麼意思。yr 寫: Mac OS X 是一種視窗系統,大多數視窗大小是可以隨著使用者的喜好來調整大小,所以如果程式的視窗大小可以改變,那麼程式開發者會在程式裡面會有處理視窗重繪的部份,所以問題比較不是那麼大。但是 iPhone/iPod touch 並不是使用視窗為概念來設計程式,頂多只有直立跟橫放的概念,而且這部份也是都由程式來控制,並不是作業系統自己幫你把畫面改成橫的,而是要由程式設計者來人工決定橫放後視窗該長什麼樣子。
其實在 Mac OS X 上面也是有這個問題,連 Apple 自己的程式都會有類似的狀況會發生,最簡單的例子就是打開你的 System Preferences ,然後選 Displays ,接著把解析度改成 640 x 480 ,你就可以看到你從來沒聽過傳說中因為螢幕大小不一樣界面要重寫的例子,如果 Apple 把視窗弄長一點,把最下面那個 check box 放得更下面一點,那它還會跑到螢幕外面,按都按不到,因為視窗沒辦法往上拉到更高,不過現在螢幕解析度只會變更大,不會變更小,所以 Apple 並不會認為這會是個問題。如果 iPhone 螢幕解析度變低,那麼情況就跟這個很類似了,程式的界面不改一下,就會影響使用者的操作。

http://sean1968.blogspot.com/
http://www.flickr.com/photos/seanandzoe/

我很低調...,所有好機銘鏡在我手上絕對看不出優在哪兒...
http://www.flickr.com/photos/seanandzoe/

我很低調...,所有好機銘鏡在我手上絕對看不出優在哪兒...