肇鑫的技术博客

肇鑫 / Owen Zhao

独立开发者,主要开发 iOS、watchOS、macOS 应用。

目前在维护 SleepTapRooster Time,以及 Markdown Writer 相关工具。

最新文章

URL的path相等,但是URL却可能不相等的问题

Swift

与预期的不同,URL即使path相同,URL也可能是不同的。因此,应避免使用init(fileURLWithPath: String, isDirectory: Bool, relativeTo: URL?),使用appendingPathComponent(_:isDirectory:)作为替代。

let url = URL(fileURLWithPath: "foo/bar", isDirectory: false)
let baseURL = url.deletingLastPathComponent()
let newURL = URL(fileURLWithPath: "bar", isDirectory: false, relativeTo: baseURL)
let testURL = baseURL.appendingPathComponent("bar")

print(url == newURL) // prints false
print(url.path == newURL.path) // prints true

print(url == testURL) // prints true
print(url.path == testURL.path) // prints true

获得Finder拖动来的文件URL

macOS

新项目需要获得从Finder拖动过来的文件URL。这篇文档是一篇总结。

根据Drag and Drop Programming Topics,拖放操作有拖动源和拖动目的地。Finder是源,我的App是目的地。

拖动的目的地必须是NSWindowNSView及其子类,我选择ViewController对应的view作为源。

注册UTI文件类型

首先要注册view可以从剪贴板获得的数据类型。由于历史的原因,这部分实际上比较混乱。

// MARK: - Dragging destination
required init?(coder: NSCoder) {
	super.init(coder: coder)
	
	// Dragging destination
	self.register(forDraggedTypes: ["public.file-url", "public.folder"]) // somehow, public.folder isn't used
}

避免使用剪贴板类型

虽然苹果的指南里使用的还是NSFilenamesPboardType,但是实际上在API文档里,这种方式已经是不建议使用的了。

Version-Notes
Pboard types will be deprecated in a future release. In macOS 10.6 and later you should replace any use of pboard types with UTIs, including the constants described in Types for Standard Data (macOS 10.6 and later).
版本注释
剪贴板类型在未来的版本会被反对。在macOS 10.6之后的版本你应该使用UTI替代剪贴板类型,即使是10.6引入的新版的也同样替代。
Types for Standard Data (OS X v10.5 and earlier)

UTI文件类型浅析

那么什么是UTI呢?其实就是苹果使用的文件类型系统。具体的可以看这个表格

几种类型的区别

比如我使用的是["public.file-url", "public.folder"],你可以在上面提到的表格里查到这两个常量。你也可以使用苹果定义的常量kUTTypeFileURLkUTTypeFolder作为替代,但是这两个常量是CFString的格式,所以使用时需要转换为String才可以。

由于历史的原因,苹果为了保证兼容性,在剪贴板的类型里会显示多个类型。比如foo.txt,从Finder拖动时,剪贴板里的类型是这样的。

public.file-url
CorePasteboardFlavorType 0x6675726C
dyn.ah62d4rv4gu8y6y4grf0gn5xbrzw1gydcr7u1e3cytf2gn
NSFilenamesPboardType
dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
Apple URL pasteboard type
com.apple.finder.node

可以看到,”public.file-url“和”Apple URL pasteboard type“是同时存在的。kUTTypeFileURL的值实际上对应的就是"public.file-url"。

(lldb) print kUTTypeFileURL
(CFString) $R0 = 0x00007fffc41bc6d0 {}
(lldb) print kUTTypeFileURL as String
(String) $R1 = "public.file-url"
(lldb) print NSFilenamesPboardType
(String) $R2 = "NSFilenamesPboardType"

拖动到目标时

override func draggingEntered(_ sender: NSDraggingInfo) -> NSDragOperation {
	let sourceDragMask = sender.draggingSourceOperationMask()
	let pb = sender.draggingPasteboard()
	
	if pb.types?.contains("public.file-url") == true {
		if sourceDragMask.contains(.generic) {
			return .generic
		}
	}
	
	return [] // NSDragOperationNone
}

获得剪切板的数据

override func performDragOperation(_ sender: NSDraggingInfo) -> Bool {
    let pb = sender.draggingPasteboard()
    
    if pb.types?.contains("public.file-url") == true {
        let urls = pb.readObjects(forClasses: [NSURL.self]) as! [URL]
        
        if let controller = nextResponder as? ViewController {
            controller.urls = urls
            
            return true
        }
    }
    
    return false
}

NSURL与URL

这里必须使用NSURL而不能使用URL,因为前者实现了剪切板读取协议,而后者没有。

剪切板读取协议

NSPasteboardReading协议。

以下类实现了该协议。由于这个协议继承至NSObjectProtocol,只有NSObjectNSProxy的子类才能实现该协议。
NSAttributedString
NSColor
NSFilePromiseReceiver
NSImage
NSPasteboardItem
NSSound
NSString
NSTextStorage
NSURL

iOS app与watchOS app数据同步

iOS

保存的数据库采用realm。手表部分的app具备与iOS端相同的功能。

基础部分

数据保存在用户的Document里。升级app数据不会消失,卸载app数据会消失。

同步算法

以iOS端为核心。watchOS发起同步请求。

首次启动

WCSession的生命周期最为标准。每次WCSessionDelegatesession(_:activationDidCompleteWith:error:)的运行被认为是一次首次启动。

  • iOS:设定需要同步数据库needSyncDatabase = true。在同步数据库完成之前,不会发送新的同步信息。
// MARK: - WatchConnectivity
extension AppDelegate:WCSessionDelegate {
    func session(_ session: WCSession, activationDidCompleteWith activationState: WCSessionActivationState, error: Error?) {
        if transfer?.isTransferring == true { transfer?.cancel() }
        
        needSyncDatabase = true
        transfer = session.transferUserInfo(["needSyncDatabase":needSyncDatabase])
    }
    
    func sessionDidBecomeInactive(_ session: WCSession) {
        
    }
    
    func sessionDidDeactivate(_ session: WCSession) {
        
    }
}
  • watchOS:设定同步数据库,手表端有两种情况。
    • WCSession首次启动时主动同步。
    • 接收到iOS发来的同步请求时同步。
// MARK: -WCSessionDelegate
extension ExtensionDelegate:WCSessionDelegate {
    func shouldSyncDatabase() -> Bool {
        return needSyncDatabase && !isSyncingDatabase
    }
    
    func willSyncDatabase() {
        isSyncingDatabase = true
    }
    
    func didSyncDatabase() {
        needSyncDatabase = false
        isSyncingDatabase = false
    }
    
    func syncDatabase() {
        guard shouldSyncDatabase() else { return }
        willSyncDatabase()
        // sync database
        didSyncDatabase()
    }
    
    func session(_ session: WCSession, activationDidCompleteWith activationState: WCSessionActivationState, error: Error?) {
        syncDatabase()
    }
    
    func session(_ session: WCSession, didReceiveUserInfo userInfo: [String : Any] = [:]) {
        if let value = userInfo["needSyncDatabase"] as? Bool {
            needSyncDatabase = value
            syncDatabase()
        }
    }
}

运行中

  • iOS
    • 当数据库改变时,发送需要同步的数据。
    • 接收需要同步的数据,存入数据库。

思路

iOS -> watchOS 同步

iOS开发存储策略

iOS

程序沙盒

  • 需要相同代码签名和包名
  • Home目录:NSHomeDirectory()
  • 临时文件目录:NSTemporaryDirectory(),在home目录外,但在沙盒里
  • iOS的沙盒内,包含程序自身

程序组容器目录

  • 需要相同开发团队
  • 位置:~/Library/Group Containers/<application-group-id>
  • 调用:FileManagercontainerURL(forSecurityApplicationGroupIdentifier:)方法

使用策略

  • 需要长期保存的数据存在Home目录
  • 需要共享的数据存在程序组容器目录

思考

单独将数据保存在程序组容器目录是否安全?
**安全。**因为只有相同开发团队的人才能访问。而且可以简化开发。
**不安全。**因为一个app的数据有被其它app删除的风险。另外,是否应该限制这部分数据,使只有需要分享的数据才方到这里。
**结论。**我个人更倾向于安全。因为团队内部的人应该被认为是可信的。但是这么做的确会存在过多分享的问题。因此,我认为还是不要把主数据库放在这边,而是将其作为辅助数据库更好。至于说需要额外处理的代码问题。我相信,从长期看,这部分代码必然是必要的。

WKAudioFilePlayer的播放问题

watchOS

假设手表扩展中存在xishuai.mp3文件。

let url = Bundle.main.url(forResource: "xishuai", withExtension: "mp3")!
let playAsset = WKAudioFileAsset(url: url)
let playItem = WKAudioFilePlayerItem(asset: playAsset)
player = WKAudioFilePlayer(playerItem: playItem)

WKAudioFilePlayer目前在真机下,如果真机没有连接蓝牙耳机,则播放无声音。因此,不能保证作为通知声音的替代。

`==`与`hashValue`

Swift

Hashable是最常见的协议之一。也许是由于它太常见了。以至于好多人都没法正确的实现它。下面总结一下实现它需要的原则。

基本原则

基本原则只有两条:

  1. Hashable继承了Equatable。因此,要实现Hashable必须同时实现Equatable
  2. 当相同类型的ab相等时,它们的hashValue相等。反之不成立,即hashValue相等的两个相同类型的ab,不一定相等。
class Fruit:Hashable {
    let name:String
    
    var hashValue: Int {
        return name.hashValue
    }
    
    init(name:String) {
        self.name = name
    }
    
    static func ==(lhs: Fruit, rhs: Fruit) -> Bool {
        return lhs.name == rhs.name
    }
}

注意

var hashValue: Int只要求返回值,因此如何实现都可以,设置只返回固定的值,比如var hashValue: Int { return 10 }也是可以的。
不能使用hashValue来判断是否相等。

不同的解读

上面的代码在涉及到子类时,不同的人会有不同的理解。比如:

class Apple:Fruit {
    override var hashValue: Int {
        return super.hashValue - "apple".characters.count
    }
}

class Banana:Fruit {
    override var hashValue: Int {
        return super.hashValue - "banana".characters.count
    }
}

let a = Apple(name: "")
let b = Banana(name: "")
print(a == b) // true
print(a.hashValue) // prints 4799450059485596700
print(b.hashValue) // prints 4799450059485596699

上面的代码,print(a == b) // true,但是hashValue却不相等。这违背了上面提到的基本原则2。这段代码需要修改。但是如何修改,不同的人有不同的看法。

判断类型

我认为最好的办法就是优先判断类型。因为,类型不同的类,就不应该相等。比如一个苹果就不应该和一个香蕉相等。

class Fruit:Hashable {
    let name:String
    
    var hashValue: Int {
        return name.hashValue
    }
    
    init(name:String) {
        self.name = name
    }
    
    static func ==(lhs: Fruit, rhs: Fruit) -> Bool {
        return type(of:lhs) == type(of:rhs) && lhs.name == rhs.name
    }
}

class Apple:Fruit {
    override var hashValue: Int {
        return super.hashValue - "apple".characters.count
    }
}

class Banana:Fruit {
    override var hashValue: Int {
        return super.hashValue - "banana".characters.count
    }
}

let a = Apple(name: "")
let b = Banana(name: "")
print(a == b) // false
print(a.hashValue) // prints 4799450059485596700
print(b.hashValue) // prints 4799450059485596699

即在非final的类的==里,总是先比较类型,类型相同的,再毕竟其它。这么做之后,就永远不会发生一个苹果等于一个香蕉的笑话了。但是这里还有一个问题,我们没有编写子类的==。这里暂时没有问题,但是如果遇到有其它属性的子类,就可能出现问题。

class Orange:Fruit {
    let weight:Double
    
    override var hashValue: Int {
        return super.hashValue - "orange".characters.count + Int(weight)
    }
    
    init(name: String, weight: Double) {
        self.weight = weight
        super.init(name: name)
    }
}

let o1 = Orange(name: "", weight: 0.4)
let o2 = Orange(name: "", weight: 1.2)
print(o1 == o2) // true
print(o1.hashValue) // prints 4799450059485596699
print(o2.hashValue) // prints 4799450059485596700

由于Orange没有重新定义==,比较时,直接调用了Fruit==,导致了不符合基本原则2。补救办法就是在Orange重新定义==

class Orange:Fruit {
    let weight:Double
    
    override var hashValue: Int {
        return super.hashValue - "orange".characters.count + Int(weight)
    }
    
    static func ==(lhs: Orange, rhs: Orange) -> Bool {
        return type(of:lhs) == type(of:rhs) && lhs.name == rhs.name && lhs.weight == rhs.weight
    }
    
    init(name: String, weight: Double) {
        self.weight = weight
        super.init(name: name)
    }
}

let o1 = Orange(name: "", weight: 0.4)
let o2 = Orange(name: "", weight: 1.2)
print(o1 == o2) // false
print(o1.hashValue) // prints 4799450059485596699
print(o2.hashValue) // prints 4799450059485596700

不重写hashValue,仅重新定义==

一些特殊的情况下,也许你可以不重写hashValue,而仅重新定义==

import Foundation
import Cocoa

class Fruit:Hashable {
    let name:String
    
    var hashValue: Int {
        return name.hashValue
    }
    
    init(name:String) {
        self.name = name
    }
    
    static func ==(lhs: Fruit, rhs: Fruit) -> Bool {
        return lhs.name == rhs.name
    }
}

class Apple:Fruit {

}

class ColoredApple:Apple {
    let color:NSColor
    
    init(name:String, color:NSColor) {
        self.color = color
        super.init(name: name)
    }
    
    static func ==(lhs: ColoredApple, rhs: ColoredApple) -> Bool {
        return lhs.name == rhs.name && lhs.color == rhs.color
    }
}

let greenApple = ColoredApple(name: "green apple", color: .green)
let apple = Apple(name: "green apple")
print(greenApple == apple) // true
print(greenApple.hashValue) // -2580839601755588497
print(apple.hashValue) //-2580839601755588497

var set:Set<Apple> = [greenApple, apple]
print(set.count) // 1

var d:Dictionary<Apple, Int> = [greenApple:10]
// eat one
d.updateValue(d[greenApple]! - 1, forKey: apple)
print(d[greenApple]!) // 9

这种做法不常见,一旦选择了不重写hashValue,就必须在该基类的所有子类都保持一致。

注意

由于Set和Dictionary使用hashValue进行判断,放入其中的元素的hashValue在没有从其中移出时,不能改变,否则会出现问题。
可以看到applegreenApple因为hashValue相同,它们在Set和Dictionary里被当做是同一元素/键值。

`Self`和`type(of:)`的用法

Swift

在讲解Self之前,需要先简短介绍一下type(of:)的用法。

type(of:)

从Xcode 8 beta 6开始,dynamicType被替换为了type(of:)。(SE-0096)

type(of:)的功能是获得实例在运行时(runtime)的元类型(meta type)。这个在之前的Swift里,被称作是dynamicType,与静态的类型进行区别。

Self

Self是一个特殊的类型。它是self对应的类型。而self是动态类型。比如:

class Foo {
    func printType() {
        print(type(of:self))
    }
    
    func printSelf() {
        print(self)
    }
}

class Bar:Foo {
    
}

let foo = Foo()
foo.printType() // Foo
foo.printSelf() // Foo

let bar = Bar()
bar.printType() // Bar
bar.printSelf() // Bar

var test = Foo()
test.printType() // Foo
test.printSelf() // Foo

test = Bar()
test.printType() // Bar
test.printSelf() // Bar

可以看到,self始终对应的是实际类型,无论变量的类型是Foo还是Bar。

由于这个特性的存在,这使得Self无法从静态类型进行转换,而只能通过self来生成。即:

class Foo {
    func bar() -> Self {
        return self
    }
}

class Foo1 {
    func bar1() -> Self {
        return type(of:self).init()
    }
    
    required init() { }
}

注意

Foo1中,有一个required init(),这是type(of:self).init()必须的。

Self的使用有以下方式:

1. 在协议的返回值中使用

这是最常见的使用方式。

protocol Foo {
    func instance() -> Self
}

class Bar: Foo {
    func instance() -> Self {
        return self // Declaration: let `self`: Self
    }
    func other() {
        let i = self // Declaration: let `self`: Bar
    }
}

class otherBar:Foo {
    func instance() -> Self {
        return type(of:self).init()
    }
    
    required init() { }
}

####注意
Bar中的实现协议的函数里,self是Self类型。而非Self返回值的函数里,self是所在类的类型。
可以使用type(of:self).init(),获得一个新的Self实例。此时,类中必须要有一个required init()
Self作为函数的返回值的类型时,可以直接写在类中,而不必非要有协议。
下面2和3中的情形,使用associateType的效果,要好于Self。因此,1是Self的最常用的方式。


2. 在协议的函数的参数类型中使用

protocol Foo {
    func bar(b:Self)
}

class Bar:Foo {
    func bar(b:Bar) {
        print(b)
    }
}

####注意
Bar中的func bar(b:Bar)是Bar而不是Self。但是这满足协议。这也符合类的多态,即Bar的子类可以调用这个函数。


3. 在协议的属性里使用

protocol Foo {
    var bar:Self { get set }
}

final class Bar:Foo {
    var bar: Bar
    
    init(b:Bar) {
        self.bar = b
    }
}

####注意
在协议的属性里使用Self时,类必须时final类。


###参考文献:
以下参考文献的一些代码针对的是3.0版本之前的Swift。部分内容需要修正才能运行。但基本原理是相同的。

Types and meta types in swift
Swift中你应该知道的一些有用的tips
Generic Protocols & Their Shortcomings 这篇难度较高,慎看。
Self in Protocol and class method

Realm的坑(三)

RealmSwift

上一个坑里,Realm的坑(二),我们使用非受管对象避开必须使用写入交易的问题。但是,每次使用时都要设置属性还是挺麻烦的。我们寻求一种可以一劳永逸的方式。

最初的想法

我最初想到的是利用NSCopying协议,然后利用Object对象的properties属性给Object实例的属性赋值。如:

extension Object:NSCopying {
    public func copy(with zone: NSZone? = nil) -> Any {
        let o = Object()
        for p in objectSchema.properties {
            let value = self.value(forKey: p.name)
            switch p.type {
            case .linkingObjects:
                break
            default:
                o.setValue(value, forKey: p.name)
            }
        }
        
        return o
    }
}

由于NSCopying的返回值是Any,因此,在使用时需要转换,像这样:

let anotherBar = bar.copy() as! Foo
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

但是这里发生了一个问题。当前版本的Realm中有一个错误,不能在swift中直接创建Object(),程序会崩溃。因此我提交了一个issue

进阶

既然不能直接使用Object(),我决定使用通用类型的函数,像这样:

func unmanagedCopy<T>(of i:T) -> T where T:Object {
    let o = T()
    for p in i.objectSchema.properties {
        let value = i.value(forKey: p.name)
        switch p.type {
        case .linkingObjects:
            break
        default:
            o.setValue(value, forKey: p.name)
        }
    }
    
    return o
}

let anotherBar = unmanagedCopy(of: bar)
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

这么做,带来一个好处,就是我在具体使用的时候不用进行类型转换了。缺点就是这是一个全局函数,也许放到一个struct里会更好一些?

最终的解决方案

在上面提单的issue里,**JadenGeller**给了我两个很好的建议。下面的代码是最终的解决方案。

// MARK: - UnmanagedCopy Protocol
protocol UnmanagedCopy {
    func unmanagedCopy() -> Self
}

extension Object:UnmanagedCopy{
    func unmanagedCopy() -> Self {
        let o = type(of:self).init()
        for p in objectSchema.properties {
            let value = self.value(forKey: p.name)
            switch p.type {
            case .linkingObjects:
                break
            default:
                o.setValue(value, forKey: p.name)
            }
        }
        
        return o
    }
}

首先建立一个UnmanagedCopy的协议。虽然直接写这个函数也可以,但是建立协议可以使函数的目的更加明确。

然后在Object对象的扩展里实现了这个协议。这里用let o = type(of:self).init()避开了不能使用Object()的问题,变量o的类型是Self。函数返回值类型Self可以确保最终的类型与self的实际类型相同,这就保证了使用时不必再进行二次转换。具体使用:

let anotherBar = bar.unmanagedCopy()
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

这个函数已经基本够用了,它包含你的实例里所有持久性数据的属性,但是不包括ignore函数里包含的属性public class func ignoredProperties() -> [String]。所以,如果你有额外的需求,就应该在Object的子类里重写这个函数。如:

class Foo:Object {
    dynamic var id:Int = 0
    dynamic var name:String = ""
    dynamic var age:Int = 8
    
    var temp = "temp value"
    
    override class func ignoredProperties() -> [String] {
        return ["age", "temp"]
    }
    
    override class func primaryKey() -> String? {
        return "id"
    }
    
    override func unmanagedCopy() -> Self {
        let o = type(of:self).init()
        for p in objectSchema.properties {
            let value = self.value(forKey: p.name)
            switch p.type {
            case .linkingObjects:
                break
            default:
                o.setValue(value, forKey: p.name)
            }
        }
        
        o.age = age
        o.temp = temp
        
        return o
    }
}

有关Self的更多用法,看Self的用法

相关

Realm的坑(一)
Realm的坑(二)
Realm的坑(三)
Realm的坑(四)