黑 程 式
2014年1月23日 星期四
2013年12月25日 星期三
2013年12月16日 星期一
[iOS] posing class
最近發現好久沒看技術文章了 orz
看到了一個有趣的少用的技術 posing
http://www.tutorialspoint.com/objective_c/objective_c_posing.htm
http://www.cnblogs.com/IT-Chris/archive/2013/03/10/2953176.html
裡面提到
hmm.... 在某些情況下確實可以用用看
可以很輕鬆的阻斷加入要做的事情@@
看到了一個有趣的少用的技術 posing
http://www.tutorialspoint.com/objective_c/objective_c_posing.htm
http://www.cnblogs.com/IT-Chris/archive/2013/03/10/2953176.html
裡面提到
Posing (扮演)和Categories(类目)的区别是:对于子类override父类方法的
情况,Categories 不能再调用父类的被重写的方法了;而Posing 可以通过“
[super 方法];”方式来调用父类被重写的方法。
hmm.... 在某些情況下確實可以用用看
可以很輕鬆的阻斷加入要做的事情@@
2013年12月12日 星期四
[ROR] 後台建立 - 權限建立
這裡使用了 cancan這個有名的library
目標
1. 用 Device註冊帳號的初始帳號都是一般權限
2. 有一個網頁可以修改某個user為 admin的權限
3. 每個user都可以看某個頁面,但是因為權限不同而會不同
目標
1. 用 Device註冊帳號的初始帳號都是一般權限
2. 有一個網頁可以修改某個user為 admin的權限
3. 每個user都可以看某個頁面,但是因為權限不同而會不同
2013年12月9日 星期一
2013年11月16日 星期六
[iOS] Web api with CoreData
當然 已經有很多好用的api
像是 AFIncrementalStore
但是其實我沒有用過
現在也沒有空去改用
原因是.... 遇到太多的廠商開的api是在亂七八糟....
因此還是得自己針對案子去設計model
不過最近遇到下面的問題
-> 當 api 有 paging的功能,卻設計了一個 infinite scroll view
一般來說我常用的作法是
api -> 接到的data 直接存在 CoreData中
view -> 透過 NSFetchedResultsController 拿 CoreData的資料
但是如果加上了 page呢?
page意味著說每頁的資料在每次拿可能都不一樣
api 是"一頁一頁"的呈現資料
但是 UI 設計的是一個 infinite scroll view
並不會知道轉到了哪一頁(往往後端又想保留每頁可以動態調整資料數量的權力),即便是每個資料都有id
例如cache了10的資料,
當下次在開啟時,api 應該要更新哪些資料?第一頁?一到十頁?
似乎都不太對,
因此,試想了一下規則
1. 用一個Global 變數去儲存該api 已經拿到第n的頁數 (假設頁數為連續)
2. 離開app時(或剛進入app時),清除掉所有跟page api 有關的object
3. 如果設計需要,在離開該頁面時,清除掉所有跟page api 有關的object
造成的結果會是
在這次開啟app的狀況下,使用者會看到cache的結果,頁面資料只會拿一次(不會更新資料,因為global 變數去記錄該api已經拿到第幾頁)
在下次開啟該app 則會清除上次看過的資料,然後重新向server拿新資料
這樣應該可以解決大部分的問題吧
像是 AFIncrementalStore
但是其實我沒有用過
現在也沒有空去改用
原因是.... 遇到太多的廠商開的api是在亂七八糟....
因此還是得自己針對案子去設計model
不過最近遇到下面的問題
-> 當 api 有 paging的功能,卻設計了一個 infinite scroll view
一般來說我常用的作法是
api -> 接到的data 直接存在 CoreData中
view -> 透過 NSFetchedResultsController 拿 CoreData的資料
但是如果加上了 page呢?
page意味著說每頁的資料在每次拿可能都不一樣
api 是"一頁一頁"的呈現資料
但是 UI 設計的是一個 infinite scroll view
並不會知道轉到了哪一頁(往往後端又想保留每頁可以動態調整資料數量的權力),即便是每個資料都有id
例如cache了10的資料,
當下次在開啟時,api 應該要更新哪些資料?第一頁?一到十頁?
似乎都不太對,
因此,試想了一下規則
1. 用一個Global 變數去儲存該api 已經拿到第n的頁數 (假設頁數為連續)
2. 離開app時(或剛進入app時),清除掉所有跟page api 有關的object
3. 如果設計需要,在離開該頁面時,清除掉所有跟page api 有關的object
造成的結果會是
在這次開啟app的狀況下,使用者會看到cache的結果,頁面資料只會拿一次(不會更新資料,因為global 變數去記錄該api已經拿到第幾頁)
在下次開啟該app 則會清除上次看過的資料,然後重新向server拿新資料
這樣應該可以解決大部分的問題吧
訂閱:
文章 (Atom)