LightNote: 告别“猴子掰玉米”式的网页资料收集方式

背景

互联网的繁荣发展,使的我们在网上能找到海量的资源,供我们学习和娱乐,在我们匆匆浏览完毕这些网页之后,尤有一些片段值得收藏起来,值得我们后面回顾;亦或作为加深阅读理解的一部分,希望对某些片段做些评论,和网页内容一起收藏起来,供以后整理再加工。还有一些特定的人群,那些以稿件为生、搜集资料做学术论文的人,他们都会在动笔之前搜集更多的素材、更多的数据来支撑自己的观点、丰富数据的说服力。

所以如何高效的搜集到足够多的资料、经过整理后填充到自己的文章里?

目前已经有很多优秀的工具来辅助实现——传统的 Evernote 作为素材、笔记的存储和同步工具,它还提供了 Cliper——来帮助用户保存当前网页内容。还有一些小众的如 LINER 的 Safari 插件专门高亮网页文字,选中、收藏、评论。

用 Web 技术为 Safari 编写扩展

首发自 https://xiaozhuanlan.com/topic/2746058139,重新创作自 Session 10665, Meet Safari Web Extensions

今年(2020)苹果宣布引入一种新的 Safari 扩展类型,这种类型使用 Web 技术来为 macOS 上的 Safari 增强功能。在进入正题之前,让我们先回顾下目前 Safari 业已存在的扩展生态系统。目前包含以下类型的扩展;

  • 内容拦截扩展(支持 iOS、macOS)
  • 分享扩展(支持 iOS、macOS)
  • Safari App 扩展(只支持macOS)

现在的 Safari 插件开发对于熟悉 Objective-c 或者 Swift 的开发者来说非常容易入门上手,但事实上,熟悉 JavaScript、HTML 和 CSS 的 web 开发者要比熟悉 Objective-C 或者 Swift 的开发者多的多;而且除了 Safari 插件外,其他主流的浏览器的插件技术都是基于 HTML 等 web 技术来构建(事实上,Safari 扩展在历史上也是可以用 Web 技术来实现的)。

为何你的 App 在 IPhone 12 上显示异常,而别人的不会?

背景

10月14日 iPhone 12 系列正式发布,当我观看直播看到介绍 iPhone 12 系列的分辨率后,我注意到这些分辨率是全新的,我立即在群里吐槽——又需要适配一波了。我以为只是宽高变化会导致字号、间距的变化,然而更严重的问题是我们判断是否是刘海屏使用了如下代码(这种写法是不完善的,但我相信很多 App 里都是这么写的);

1
self.is_iphonex =  (SCREEN_MAX_LENGTH==812.f || SCREEN_MAX_LENGTH==896.f);

是否是刘海屏是枚举所有符合预期的设备高度来判断的,它的好处是快速稳定,但遇到新机型就悲催了。 在新 iPhone 12 系列中,屏幕高度分别为

Device Retina 屏幕点(pt) 物理像素 (px)
iPhone 12 Pro Max 6.7″ 3X 926 x 428 2778 x 1284
iPhone 12 Pro 6.1″ 3X 390 x 844 2532 x 1170
iPhone 12 6.1″ 3X 390 x 844 2532 x 1170
iPhone 12 Mini 5.4″ 3X 360 x 780 2340 x 1080
iPhone 11 Pro Max 3X 414 x 896 2688 x 1242

所以如果 (SCREEN_MAX_LENGTH==812.f || SCREEN_MAX_LENGTH==896.f) 代码来判断刘海屏,定位导航栏位置肯定是错误的。预期表现是导航栏被刘海遮住。

每周技术评论(2020年第33周)——为什么 Figma 会赢

路旁的中国电信公共电话厅

这是位于杭州市萧山区建设一路的一个公用电话厅,平时走路也没有留意到这些老东西,直到这天晚上遛弯我注意到上面的小广告。

我很好奇电话还能不能用,拿起来,话筒里还有忙音,还能工作。想想大学的时候,买的多少 ip 卡,有一大盒子不止,路旁电话亭对于我们这种没有手机的人来说真是太方便了。而如今,移动电话变成必需品,这些固定的移动电话厅,失去了本来的意义,只是没想到中国电信还没有拆掉。听朋友说,有些地方把固定的电话亭改成了 WiFi 热点——倒也是个不错的改造方案。

这让我加深了如今社会全面转向移动化势不可挡趋势的印象。在互联网领域,从单机走向联网早已不可阻挡,今天从两种作图工具—— Sketch 和 Figma 的不同形态、定位来分析“移动、云端”的力量。

本文是对Why Figma Wins一文的翻译概括和评论。本文中“我”都是指【原作者】

WWDC20 10149 打造更容易 Preview 的 SwiftUI 应用

首发自 https://xiaozhuanlan.com/topic/4718293506,重新创作于 Structure your app for SwiftUI previews

简介

在开发中使用 SwiftUI Preview 功能,帮助我们开发更灵活、可维护、易懂的 Apps。 本文将介绍一些小技巧,改进提升项目工程的 Preview 体验。如,如何一次性 Preview 多个文件;如何管理数据流;如何使用样例代码提升 Preview 效率。 本文将介绍一些方法,分析数据模型,帮助你定义视图的输入,让这些视图更易可视化编辑、更具有可测性。阅读本文需要你已经熟悉 SwiftUI和 SwiftUI Preview(可参考阅读 “Visually Edit SwiftUI Views” from WWDC20

WWDC20 10185 SwiftUI 的可视化编辑工具

首发自小专栏, 重新创作自 Session,Visually edit SwiftUI views

前言

SwiftUI 带来的描述性构建界面能力,为 Xcode 引入诸多的可视化工具奠定了基础。可视化界面搭建,早期在网页开发中,曾经流行过,最著名的代表 Dreamweaver。如果把 html 源码视为因,那么浏览器渲染的界面则为果。从最后的界面上修改,反馈到源代码,这个过程非常直观,也高效(得益于 html 可以及时渲染)。人人都想可视化搭积木式编码, Apple 在可视化编程上从一开始就有布局—— xib、Storyboard ,至今还在迭代。但不得不承认,Storyboard 编程范式在 iOS 领域并不是主流。如果 Dreamweaver 为代表的所见即所得(WYSIWYG )编辑器没落是因为从因到果逆方向,生成的代码质量不高。而 xib、Storyboard 无法成为主流的一大原因是中间层——xml 中间层的引入的复杂度。

WWDC20 10649 为 Xcode Library 添加自定义 views 和 modifiers

首发于 小专栏 https://xiaozhuanlan.com/topic/6920751348

前言

Xcode Library 最早是作为 Storyboard (xib)的配套功能引入。在制作 Storyboard 时,开发者打开右下角的 Object Library,从中选择合适的组件,通过拖拽快速引入组件对象。它和所有可视化搭建系统一样,是组件展示区,方便开发者快速浏览引入。后面的 Xcode 版本慢慢引入了色盘、图片资源等功能,到 Xcode10 时, Object Library 的重要性进一步提高,位置从右下角可能被隐藏的位置提升到 Xcode 右上角功能 toolbar 按钮区,常驻界面。到了 Xcode11, Object Library 升级为 Library,成为添加某些对象等的总入口,包括代码片段、文档。