iOS9帶來了許多新的特性來讓我們的開發生涯更簡單,Stack Views的簡介就是一個很好的例子.之前給你們簡單的介紹了auto layout.這個例子讓我們工作起來很簡單.但是,隨著你的app UI變得更複雜,你會發現給所有的iOS設備完美的提供界面約束變得更難.這是蘋果在最[……]
編程開發
Swift 現在開源了。今天蘋果啟動了開源 Swift 社區，同樣驚豔的新工具和資源包括：
- Swift.org ——一個用來做開源 Swift 社區的網站；
- 公共代碼倉庫 github.com/apple；
- 一個新的 Swift 包管理器項目以簡單地分享和編譯代碼；
- Swift[……]
現在回想起來，我從5月份開始學 Swift 語言到現在斷斷續續也算有近六個月，從對程序一點感覺也沒有，到現在的“開壇做法”，一路經歷了很多。可能說對於工作多年的高手來說，這些都太膚淺了，一句“你還需要項目經驗”就可以把我殺的血槽-1，不過對於大多和我一樣的“小白”來講，我覺得我這半年走來的路是可以復[……]
在進行開發的時候，你難免會用到隨機數。還有更多的時候，我們需要隨機數來生成一系列的數字串備用。不過好在各種編程語言裡都提供了一個簡單好用的偽隨機數生成器供你使用，比如C#裡的 隨機。
不過，C#的 Random 默認是以系統時鐘為種子的——這種方法簡單粗暴，可惜一旦遇到短時間生成大量隨[……]
有時候我們要做一個簡單的佔位頁面出來，這個頁面不需要任何的內容，只要簡單的一章背景圖片即可，但是簡單的東西卻往往更難以實現。
這是我在直接寫一個頁面時候遇到的問題，代碼是這樣的：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Coming soon...</title> </head> <body> <div id="Layer1" style="position:absolute; width:100%; height:100%; z-index:-1"> <img src="BJ.jpg" height="100%" width="100%"/> </div> </body> </html> |
看上去很完美的解決辦法對吧？但是實際上卻遇到[……]
首先這個翻譯並不是開源翻譯，根據將來的捐贈收入，大家會得到補償（可能不多
其次作為貢獻者你自己翻譯的爽是前提。
基本規則
- 首先你會得到這個博客的一個作者帳號，用這個號在這個博客發布你的翻譯，正在翻譯的章節請使用“保存草稿”功能持續更新。——你保存草稿我能[……]
泛型是面向對象裡另外一個重要的概念，除了多態，它進一步增加的代碼的重用範圍，而對於 Swift 語言來說，泛型貫穿了它的始終。
從 Print() 說起
我們從上課的第一天開始就在使用這個全局函數了，它讓我們得以在屏幕上顯示語句，用起來十分簡單，傳入一個字符串即可。
傳入字符串就顯示字符串[……]
這節課我們一起來認識一下 Swift 中的錯誤處理
在調用方法和寫一個輪子的時候，總會有各種各樣奇奇怪怪的錯誤，就是已經正常編譯的軟件，也會出現一些不可預期的錯誤。不過，這些錯誤當中，有一些是可以被識別和捕捉的——它們可預期。
可預期的錯誤
為什麼我們說有一些錯誤是可以預料得到的呢？比如說[……]
不全都是動態
我們都知道，方法是放在實例裡運行的。也就是說方法執行的結果是依據實例屬性而來的，而實例的屬性是根據當前狀態而變化的——我們稱其為“動態”。
但真的全都是動態的嗎？其實不是，有些方法它會直接根據你的調用而給出結果，並不需要依據實例屬性的變化來產生變動——也就是說它是無論如何都會產[……]
前邊鋪墊了那麼多，現在終於要講到垃圾回收這個東西了。
弧
這不是方舟……這是自動引用計數（Automatic Reference Counting），這個東西是蘋果用來管理內存的。
它的功能就是那個垃圾堆上的垃圾回收器。它能夠保證所有在堆上運行的對像被釋放後不會一直駐留在堆上。保證了那[……]
在上一節課的末尾，我們最終明確了一個對象的創建過程，那麼，說起來創建一個對象的樣子很像是調用了一個方法，可這個方法到底是什麼呢？
初始化器
沒錯的，當我們初始化了一個類為對象的時候，我們確實調用了一個方法——初始化器。
初始化器其實就是一個特殊規定了的方法，它能夠為類進行初始化。
想像一下，[……]
是時候來看看對象和方法的生存空間了——想要了解面向對象，不知道方法和對象放在哪裡是一件很尷尬的事情——畢竟我們還是要面對垃圾收集器的，想要讓垃圾收集器幫你做更多的事情，我們就得一定程度上了解它的工作機制，了解方法和對象存放在哪裡，否則的話，你就又要寫出一個不堪一擊的程序來了！
我們在前邊的課程[……]
上節課我們提到了協議，但是只講了它的一種應用方式，這節課我們就來深入地了解一下這個用起來和 class 差不多的協議究竟有什麼高深奧義。
現在，我們要再一次回顧那個可恥的繼承樹：
這裡我們寫了武器……是用來進行攻擊和防守的。那麼，作為一個遊戲，武器的模型不能夠單單只用在這一個地方[……]
說了方法的重寫，我們再回過頭來看看那個繼承樹：
這個看起來應該還行，我們可以創建大刀的實例，創建手槍的實例……
但是如果我要這樣寫呢？
|
1 |
var 武器 = 武器() |
那麼問題來了：挖掘機……
不，我們的問題是“武器”到底是個什麼東西？[……]
說了那麼多次的重寫，這次我們就來認真的對待一下方法的重寫。
合約
我們說了，繼承就相當於是簽訂合約，我們繼承出來的子類一定要遵守這個合約，那麼就算你想要做一些合約裡沒有的事情，也要遵守合約的規範，所以，你重寫方法，也一定要符合方法的類型。
我們講過方法的類型，它以 ()->() 這樣[……]
上一節課我們說完了繼承，那這節課我們就繼續深入，來看看繼承樹的大招是什麼。
可能我和你說起多態這個發音，你最先想到的應該是高中生物裡講的“多肽”；好吧，這兩者之間唯一相同的可能就是發音了。
繼承的意義
我們說繼承實現的意義非凡，它大大降低了我們代碼中的冗餘行數，降低了代碼的維護難度……[……]
上節課我們具體地講述了繼承的機制，並且也設計了一個繼承樹，那麼問題來了：我不是要問挖掘機技術哪家強？我是要問如何來確定一個類是另一個類的子類呢？我們又如何設計一個類而不是某個類中的屬性呢？
“是一個”與“有一個”
這裡我們就要用這麼一個方法來檢驗它們二者之間的關係了：
我們說，手槍是槍械——O[……]