V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  beimenjun  ›  全部回复第 14 页 / 共 132 页
回复总数  2639
1 ... 10  11  12  13  14  15  16  17  18  19 ... 132  
@jy03179163 其实如果你睡眠闹钟时间是在 14 点前,感觉跳过下一个睡眠闹钟,应该还是可以的,我这边睡眠闹钟 7:00 ,执行完“跳过下一个睡眠闹钟”,闹钟页面显示的是“已跳过(仅明天)”。

@6364v2 谢谢,我争取搞一个 iOS 16 设备来弄一下……
@qq2511296 我觉得我这个如果要增加减少某一些天简单一些些。
@jiandandkl iOS 系统层面不支持

@6364v2 你看看能不能在底下不是有个“搜索 App 和操作”那个输入框,看看输入“休息日”有没有啥结果。
@dengshen 因为 App Intents 最低 16 开始的,不过好像 16 的支持也有点奇怪,推荐 17 使用。

@6364v2 你看看快捷指令里面能找到休息日及其指令吗?
@vruzo 不需要,你可以打开快捷指令页面,选择某个特定的闹钟,然后点开 “>” ,把“运行时显示”关掉。你只有不设置或者对应值变成“每次均询问”,才会每次都要选择,否则无感的。

@6364v2 我感觉得整个 iOS 16 设备测试下……
休息日的判断逻辑是这样的:“用户标注” 大于 “公共假期模板信息” 大于 “这一天是不是周末”
@klo424 单休因为香港很多人是单休的,所以后面会加上一个单休双休的选项,但是这个要看需求多不多了。

大小周可以自己在第二个 Tab 日历进行把隔周的周六或者周日(具体决定权在用户手上)标记成工作日,实现大小周。

毕竟有些大小周是三周一个双休,总之又复杂又苦逼,我觉得做出来代码也很复杂很苦逼。
@ysxb1145 其实是 Android 的厂家有动力在自己的系统里定制这种定制化的服务。毕竟其他家都做了,而且人家是靠广告和设备赚钱的,这些免费的功能你已经为其付费了。

另外我不觉得这些国内定制版这件事情上做得特别好,很多家 Android 厂家应该根本没考虑自治区也有自己的节假日安排。

而我,既然决定修修补补,那就要收我觉得合理的价钱。

--------------------

而回到这个“节假日闹钟”,我觉得 Google 和 Apple 不做是很非常好理解的,节假日安排这种东西其实是很复杂的:

比如马来西亚,各个洲有不同的法定节日,你也许可以大概判断用户是马来西亚的,但是怎么判断用户属于哪一个洲,如果他就住在两洲的交界处呢。

甚至用户的身份、从事的行业直接决定了他们的法律假期是哪一些。

这种事情做了成本太高,最终效果未必好。
@chengYT @hheng101 @dilidilid @zhigang1992 @AceRacer @1145148964

请到 https://github.com/zizicici/Duplicator 里自取代码,跑一下测试一下。看看你们说的是不是正确的。

-------------------

所谓 iOS 10.3 blabla APFS blabla 的,其实对于这个场景是不奏效的。

你们说的场景可能在一个沙盒内部的某些情况会奏效,但是对于通过系统控件 Sharing 到另外一个 App 是没有用的。

大概的流程是 iOS 系统把分享的文件先投递到 Receiver 的 Documents/Inbox 处,这时候文件已经进入 Receiver 的沙盒里了,然后 Receiver 在 `scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>)` 处进行处理。

甚至 Receiver 这一步处理中,你选择将 URL 里的 data 直接读取再转存,会再增加数据的体积。

---------------------

另外因为每个 Documents/Inbox 是有可能因为空间不够,被系统删除。所以正常靠谱点的 App ,如果有需要会将 Inbox 里的文件挪到自己沙盒里设计好的位置。

---------------------

附录:

测试内容:

我这边用了一个 1.53 G 的文件测试。

在分享前:

Sender 占用体积 1.54G ,Receiver 占用体积 300K 。
iOS 可用空间比之前少了 1.5G 左右,符合两个应用加起来的体积。

在分享后:

Sender 占用体积 1.54G ,Receiver 占用体积 1.53G 。
iOS 可用空间比之前少了 3.1G 左右,符合两个应用加起来的体积。
@AceRacer 自己看代码去调试吧……

https://github.com/zizicici/Duplicator
@zhigang1992 @dilidilid 作为 iOS App 开发,稍微解释一下我的看法吧。

当文件通过分享过来的时候,使用 AppDelegate/SceneDelegate 来管理周期的 iOS 应用,使用的是类似 application(_:open:options:) 方法来响应,这一步系统会传来一个 url ,然后接收方可以通过这个 URL 来读取文件的 Data 。

但是在 OP 举的这个例子里,市面上正常点的 PDF 阅读器,都会把 Data 保存为 PDF 格式到自己的沙盒里。除非有谁写了接收 PDF 分享过来,但是不做持久化保存,只存在内存里。

所以一般情况下会增加。

---------------

这个问题还可以延展出来,比如开发者也许可以保存系统提供 URL 到数据库里,以供下次使用?我个人是不建议。因为这个 URL 可能系统重启了就没了。
@1145148964 系统不会管你沙盒里两份文件是不是一样的。不存在什么去重。
234 天前
回复了 0312birdzhang 创建的主题 奇思妙想 关于打包箱子引发的思考
作为一个 App 开发者和一个搬家喜欢装箱子的来说一下。

你这个想法感觉是个很典型的算法题目啊。

但不管是商业上还是日常生活里,一般涉及到:在更大的箱子里装小箱子。感觉最佳实践都是优先使用统一的固定尺寸的小箱子,而且对这些箱子的置放方向与堆叠载荷都是有明确要求的。这种时候都不太需要用到 App 。

唯一能想到用途的就是快递企业了。
一般情况下会增加,因为这相当于文件从一个 App 的沙盒,传到了另外一个 App 的沙盒里。
你这样子倒像是真的拷贝过敏感数据。
237 天前
回复了 pursuit 创建的主题 北京 有跟我一样没赶上高铁的嘛
我和你说,节假日赶不上车时人生经验之一……

虽然这次体验到了下次也还会体验就是了……
1 ... 10  11  12  13  14  15  16  17  18  19 ... 132  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1402 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 17:15 · PVG 01:15 · LAX 09:15 · JFK 12:15
Developed with CodeLauncher
♥ Do have faith in what you're doing.