遊戲/程序/更新/二次開發/小作品相關發佈
Sep 29
在实际项目踩坑过程中,我们主要到Set-Cookie存在多个的情况。有两种做法:

- 一种是一条Set-Cookie,但是这一条中有多个cookie key-value,通过逗号“,”连接。
- 一种是haeder中有多条Set-Cookie字段,

当然也有上面两条组合的情况,但是一般就是这样了。不过这次讨论的是,在实际开发过程中,这两种情况都有踩坑的问题。
Sep 3
偶尔会遇到前端访问遇到httpcode431和414的错误。具体情况划分起来,会遇到以下三种:

- 414 Request-URI Too Large:即URL过长
- 400 Request Header Or Cookie Too Large:即Header过长
- 431 Bad Message reason: Request Header Fields Too Large:即Header Fields过长(HTTP整个前半部分,包括url+header)

虽然明白意思,但是实际遇到的时候晕乎乎的,特别是431的情况。因此梳理这几个异常的来源。
Aug 29
背景

在我们电商企业应用开发过程中,不可避免的遇到了现在行业里常用的蓝牙热敏票据打印机,这类打印机不同于标准的ESC/P编程打印机,往往会自定义自己的简化操作指令并进行相对固定的动作,一方面是本事功能受限,另一方面也能让小票打印编程更简单。我们使用的一款打印机的指令设计就很直接,纯字符的:
//初始化打印区域
SIZE 58 mm,30 mm
GAP 2 mm
//清除图像缓冲区全部数据
CLS
//往图像缓冲区填写数据
TEXT 50,50,"4",0,1,1,"这是一行文字"
BITMAP 200,200,2,16,0,xxxxxxxxxxxxxxxxx //这是一张图片,图片是二值图二进制数据
BOX 100,100,200,200,5 //这是一个矩形框
QRCODE 20,20,L,4,A,0,"这是一个二维码"
//打印缓冲区图像1次
PRINT 1
Jul 9
背景:我们做一些辅助工具库时,为了对目标库进行最小的入侵,往往会通过方法交换来实现特定的节点完成特定的操作。这样的代码假设我们有一个Utils要入侵A,只需要U依赖A即可。但是偶尔会有这种情况,我们的Utils适配了ABCDE五个库,比如我是一个流量统计库,对这五个库的网络操作进行了抓取。但是我Utils并不适合直接依赖这五个库,而是期望用户实际引用到啥,我就统计啥。

因此,需要实现的是Utils不依赖目标库,也不依赖目标类,来实现方法交换。
Jul 1
在iOS项目开发过程中,我们总是会加入一些开发者工具相关的代码,通过DEBUG/TEST宏或者其他形式防止相关代码引入到线上。但是随着我们做组件二进制化对相关类进行编译后pod沉淀,相关代码的处理就麻烦起来了。

- 首先明确,组件二进制化是iOS工程化的整体趋势,不可阻挡

那对应的,对于有开发者工具区分的二进制pod,我们如何进行管理呢?
Jun 30
上一话http://lrdcq.com/me/read.php/106.htmWidgetKit是从StaticConfiguration入手的,而避开了实际上应该更常用的IntentConfiguration。而理解在WidgetKit中出现的Intent,显然不能按照Siri中的Intent去理解了。在WidgetKit中,Intent更多的是用来呈现长按配置菜单中的选项,简单的来说,Intent是一个配置表。如下图:
Jun 28
iOS14开放给开发者的大一统的小控件WidgetKit出来了。作为“抄袭安卓”的必不可少的一步。初探下苹果如何在偏向于安卓的高自由度,高可配,和自己风格的安全,隐私,高性能之间作出平衡,最终设计出的这个WidgetKit呢。

概览

點擊在新視窗中瀏覽此圖片
Apr 12
由于国家公祭日等一些原因。我们客户端也需要将部分核心页面置灰。虽然可以通过预留的大促方案或者主题化方案进行配置。但是,1. 相关方案的配置并不彻底,一般多多少少会有遗漏的地方,那在这类场合会相当眨眼。2. ugc内容无法控制。因此,我们需要尝试一个更通用的方案进行处理。

方案对标
Mar 28
现代电商类应用很常见一种“双向联动列表”的设计,比如京东分类页类目列表的顶部tab联动锚定:
點擊在新視窗中瀏覽此圖片

并且行业内各种移动端组件库也有类似的输出:https://taro-ext.jd.com/plugin/view/5edf005bbe897edf72b35ea8。不过看起来真正用这样的组件的人并不多——就算用肯定也是自己开发的。究其原因,我们在讨论某个场景是否适合使用这个交互方式的时候,注意到几个痛点:
Feb 28
最近遇到一个内部企业应用由于业务发展需要,毕竟现在国内线下拓客逃不掉微信,因此需要这个内部应用也接入微信分享来辅助线下提效。接了一半,才注意到在年初加入规则,未上架应用一天只能分享100次。这不完犊子了嘛。但业务诉求很强烈,由于我们分享目标是用户端小程序地址,因此我们立刻意识到,分享小程序二维码的图片,即调用系统分享的图片分享,就可以解决这个问题。