1樓:範雨楠
恰巧最近在做專案的Table頁相關,故斗膽前來。
先簡單介紹下Table頁相關背景:
如上圖,Table頁內包含不同的Group(組群),而Group包含各個Cell(子專案)。
題主指的「iOS列表分割線為什麼不是通欄」應該是在講iOS7、iOS8中子專案間的分割方式。
在iOS6年代擬物(Skeuomorph)的設計語言下,Group的設計是用圓角矩形包裹;而其中Cell的區分則是使用題主說的「通欄」的設計方式。
在擬物設計語言的前提下,這樣的設計很好的區分開了Group與Group,同時也很好的區分開組內的Cell與Cell。整個頁面一目了然,很有秩序。
到了iOS7年代,「光頭強納腎」小手一揮帶來了Niubility的扁平化設計。
Less is more,特效滾蛋了,內容為先。
我們現在看到的iOS8內的Table頁與iOS7一脈相承。扁平化設計語言下,Group作為頁面內主要元素打通布局;Cell作為次重要元素,分割線採取文首透氣的設計方式,視覺優先順序弱於Group的通欄布局。
事實上iOS7、8的Cell分割線透氣這塊,還有些細節的文章。
Cell間的透氣分割線始終與文字首字母對齊,當Cell內包含圖示時,透氣分割線與文字一起右移避開圖示顯示區域。
(下圖中, Notifications View組的Cell是沒有圖示的,Include組的Cell有圖示)
那麼問題來了,Edit狀態下,Include裡的Cell是可以移動位置的。這個短丁丁的透氣線腫麼展示移動狀態呢?
「光頭強納腎」笑而不語……
(擬物style陰影亂入)
(BG居然還是透明的……和win7水晶風格一樣如絲般透明!說好的毛玻璃透明特效呢啊喂?!)
至此,我已對「光頭強納腎」變通的設計語言跪拜了……
ok,還沒完!!!
iOS7下拉出的Today裡也有Table,這裡還存在乙個編輯狀態的情況!
然後我驚奇的發現
當Cell內包含兩個圖示時,透氣分割線與內容相關的圖示一起右移避開編輯圖示的顯示區域。
……臥槽
以上為拋磚引玉。
鑽牛角尖之處見笑了,原諒我只做1%的事兒逼^_^
2樓:
我們需要對各種資訊做區分、排序,特別是在乙個複雜的系統中。
非通欄的設計當然是可以的,他們之間的區別就類似於:
123456
與123456
為了突出34,上文做了加粗,下文不僅加粗,還做了傾斜這一切的努力都是為了讓資訊更加井然有序。當然蘋果的方案非常優雅,不僅有通欄與非通欄之分,線色、線寬都不一樣。這些不被看見的努力,加強了整個視覺的秩序感。
3樓:
當然是層次感啊,乙個table包含若干group,乙個group又包含若干cell。因為group分割線是撐滿的,如果cell分割線再撐滿,就沒有層次感了啊。你拉開自己的抽屜,是不是發現檔案分類層次越深越小?
4樓:Ying Zhong
如果你問的是為什麼「會」這樣,那麼答案如下:
iOS7以前都是滿的,iOS7之後UITableView的separatorInsets的左邊留了一點點,所以導致了這個現象。如果要撐滿解決方案就是 separatorInsets = UIEdgeInsetsZero
如果你問的是為什麼「要」這樣,那麼摺疊我的答案吧
python不用臨時列表怎麼修改原列表?
sanlee 這個問題的時間複雜度為O n 空間複雜度為O 1 j 1 for i in range len lst if lst i 2 0lst i lst j 1 lst j 1 lst ij 1 元素 不考慮大小的話很容易。要求奇數在前,偶數在後。那麼就設兩個指標 偏移量 分別在頭和尾。分別...
Python的元組巢狀列表,列表方法改變元組內列表,那元組還算不可變麼?
黃哥 這個問題這樣去理解 t 繫結的tuple 物件是不可變,但內部的元素可以是可變的資料型別 t 2 是list 所以t 2 是可變資料型別。 t 2233,1,2,3 id t 2771807698688 id t 2 2771807698368 t 2 4 id t 2 27718076983...
Python中列表(1,2, 2,3 )怎樣遍歷
文魚 defmy print t forein t iftype e tuple for sub eine print sub e else print e if name main a 1,2,2 3 my print a 如果是巢狀比較多的話,明顯就不是適用了。稍微改動下就可以了,如下 defm...