swift和oc的相互呼叫，其實很簡單（基於swift4.0）
swift呼叫oc: 需要在統一的bridge標頭檔案（xxx-Bridging-Header.h）裡面import，然後即可使用。
oc呼叫swift: 需要在暴露出來的方法和屬性上加@objc否則不可用；且檔案的類需要繼承自NSObject或NSObject的子類。另外需要在工程配置裡面做一些小改動。
相關推薦
swift和oc的相互呼叫，其實很簡單（基於swift4.0）
swift呼叫oc: 需要在統一的bridge標頭檔案（xxx-Bridging-Header.h）裡面import，然後即可使用。 oc呼叫swift: 需要在暴露出來的方法和屬性上加@objc否則不可用；且檔案的類需要繼承自NSObject或NSObjec
IOS WebView中JS和OC相互呼叫
現在有很多專案中都涉及到HTML5，在一個普通的APP裡面嵌入HTML5網頁，嵌入的這些網頁在伺服器把頁面修改之後同樣也能跟著修改，這樣就能很方便的修改程式的展示內容。如果使用tabelView或者其他的控制元件展示內容的話，當展示的內容的樣式需要發生改變的
終於搞定無參“動態呼叫WebService方法”，其實很簡單，大家還是要有信心，還是要有琢磨的精神。
終於搞定“動態呼叫WebService方法”： 我在學習 動態呼叫WebService方法時看到很多網友在呼叫函式（其實往往是“無參”函式）時得到一個錯誤： 未將物件引用設定到物件的例項。 這個錯誤很常見，貌似不好處理，沒明白的人不知所云，所以這裡提醒我們自己：凡是
初學XPath，其實很簡單
XPath 是一門在 XML 文件中查詢資訊的語言。XPath 用於在 XML 文件中通過元素和屬性進行導航。 （我的理解：XPath 就是一個用來查詢xml節點的路徑語言，一個路徑字串語法） XML 例項文件 我們將在下面的例子中使用這個 XML 文件。 <?xml vers
敏捷其實很簡單（5）一個稱職的PO應該做和不應該做的
Product Owner（產品負責人）是Scrum框架中一個非常重要的角色，產品負責人是管理產品待辦事項列表、確保團隊工作價值的唯一責任人。他負責維護產品待辦事項列表，確保每個成員明晰列表內容、明確哪些條目具有最高優先順序，從而瞭解下個需要開發的條目。 在實際工作中， PO的職責可以參考下圖：
敏捷其實很簡單（14）review meeting和demo的關係
今天我們來聊一聊scrum中的一個重要會議，review meeting。 這個概念其實在很多資料裡面都有介紹， 我在這裡就不佔用篇幅來介紹基本概念了，那麼今天我們主要說說review meeting和demo之間的關係。 說到這裡，有的朋友就說了， r
敏捷其實很簡單（7） Scrum Master的7種武器之長生劍和孔雀翎
這個系列的文章來到了Scrum Master這個角色的解讀，其實SM在Scrum以及敏捷流程中也是很重要的一個role，而本人也恰好在此有過一些經驗和教訓，所以便想在此多費一些章節和大家分享一下關於Scrum Master這個角色怎樣在Scrum執行中起到應有的
《Redis的哨兵機制》 模式 原理詳解，其實很簡單
一.什麼是哨兵機制?答：Redis的哨兵(sentinel) 系統用於管理多個 Redis 伺服器,該系統執行以下三個任務: 監控(Monitoring): 哨兵(sentinel) 會不斷
想要開心，其實很簡單
開發十年，就只剩下這套架構體系了！ >>>
敏捷其實很簡單（4）--初識看板
今天我們來介紹一下敏捷開發中常用的第二個實踐，看板方法。其實，看板方法實際上可以說是精益產品開發的重要實踐，與其他敏捷方法相比，它具有更強的可實施性，提升端到端價值交付能力，更好支援系統的改進。而且它也可以和很多其他敏捷方法無縫連結。 看板方法的起源 中文意思帶來誤解 看
敏捷其實很簡單（9）Scrum Master的七種武器之離別鉤霸王槍箱子
離別鉤， 七種武器裡面代表的是戒驕。其實對於Scrum Master，這個武器也很重要。 組織在敏捷轉型的時候，運行了一段時間之後，運用了一些敏捷實踐，而且從各方面，貌似反響很大，這個時候往往會產生如下想法： 1.我們已經敏捷了， 看站會，看板都用上了
敏捷其實很簡單（11）從站會開始
從今天開始我們準備介紹一下scrum中的4個會議中的每日站會。 每日站會的目的我在這裡就不再累述了，因為已經有太多的文章和書籍來介紹了，如果大家有興趣的話，可以聯絡我，我可以給大家推薦一些資料和書籍。 那麼我們在這裡主要講一下什麼樣的站會是一個好的站會，我們
敏捷其實很簡單（12）Scrum中的計劃會議
今天我們來一起聊一聊Scrum中的計劃會議。 那麼，首先，scrum中的planning會議的目的是什麼呢？ 其實從本質上來說，scrum中的planning會議主要有以下幾點 從PB（Product Backlog）中按照優先順序選取這個spr
敏捷其實很簡單（1）重讀敏捷宣言
本人在軟體開發行業中混跡多年，接觸敏捷開發也有３年多的時間了，期間SM, Agile Coach 都曾經從事過，在工作過程中也有過一些對軟體開發流程，敏捷開發的一些思考和總結。這裡想記錄下來，和大家分享一下，也作為自己對個人多年來工作的一個記錄和總結吧。 本篇是這個敏捷系列
敏捷其實很簡單（15） 回顧會議
其實個人以為，回顧會議在scrum所有的events中是最重要的一個 正如上圖所示，我們可以看到在整個scrum的價值流上，每個會議都有不同的對應意義： planning meeting用來將目標分解並給團隊，standupmeeting 則用來對tea
敏捷其實很簡單（8）Scrum Master的七種武器之碧玉刀多情環
段玉是個不諳世事的少年俠士，不曾練達人情，卻以他幾近天真的誠實贏得了一帆風順的“運氣” 碧玉刀 Scrum Master所需要的誠實要體現在什麼地方呢？ 在scrum prime的描述裡面，沒有要求scrum master一定是所在團隊的技術領域專
敏捷其實很簡單（2）--理解敏捷12原則
第一條準則：講明瞭敏捷開發的最高目標，就是儘早和持續交付有價值的軟體來滿足客戶，這裡我們要注意幾個關鍵詞，儘早，持續，有價值和滿足，通過這幾個詞，我們實際上是可以理解第一條原則的意義，那就是將產品對於客戶的價值放在首位，整個產品的交付和開發週期都是為了滿足客戶對於產品價值的滿意度。這也是為了解決傳統軟體開發中
敏捷其實很簡單（6）神壇上的Scrum Master
#敏捷其實很簡單-回顧 因為最近工作的原因，所以有段時間沒有更新這個系列的文章了。其實除了時間原因，還有就是想停下來思考一下，後面要怎麼寫，如何能夠從一些新的角度來剖析敏捷，和各位敏捷從業者一起思考敏捷現在的狀態和未來的趨勢。經過幾天的思考和跟其他一些朋友聊天
敏捷其實很簡單（13） 糾結的故事點
彼此上篇文章說完了計劃會議，我們今天來一起探討一下計劃會議裡面一個很重要的環節，那就是故事點的估計。 故事點這個概念大家應該很瞭解了，實際上就是對在sprint裡面要開發的user story進行一個粗量級的估算，以便於團隊能夠知道這個user story
敏捷其實很簡單（10）--自組織團隊是怎樣煉成的
前面幾期用了很大一個篇幅來講Scrum Master的工具箱，這是因為筆者本人曾經做過幾年的SM，對這個職位可以說是感觸頗深，而SM也是一個Scrum Team非常重要的一個角色，他可以保證團隊始終走在正確的敏捷之路上，幫助團隊成員正確理解敏捷及相關實踐。所以在