Post

Replies

Boosts

Views

Activity

converting PKDrawing to NSImage fails
Hi. My goal is to convert PKDrawing to NSImage on Mac Server. For this, I use Vapor framework and receive POST request with PKDraiwng's base64 string(from PKDrawing.dataRepresentaion()). However, this task succeeds on local device, but fails on Remote Mac server. (with exact same logic & data) In failing cases, input base64 string was successfully converted to PKDrawing, but PKDrawing to NSImage converting was failed. (NSImage object is located at 0x000000 memory address) Is there any hardware dependencies to convert PKDrawing to NSImage? Please give me some help. let base64String = "d3Jk8AEACAASEAAAAAAAAAAAAAAAAAAAAAASECTanLurR0TesQ6DbJmhcB4aBggAEAAYABoGCAEQARgBIi4KFA39/Hw/FcXERD4dhYSEPiXNzEw/EhRjb20uYXBwbGUuaW5rLm1hcmtlchgDKuMHChDT0UH2JnhFKJXSKOjPQ4MBEgYIABABGAEaBggAEAEYACAAKp8HChD+PS4PhSlOD4NNWagXDeasEXgNipZotcNBGCwg4wMoHDIIAABcQegDAAA68AZww4BBYPKVQgAAAADNABSQwlXQOFhkkEEAiZhCaJFtPSkB0o7CVQhBMDaaQcBDlkLn+6k9OAHOjsJVX0IQuaRBUDOSQs3MzD04Ac6OwlVfQvA7r0HQS41CQmDlPTABzo7CVV9CsPq2QYC7iEKPwvU9JgHOjsJVqUGArrtBYPaFQgAAAD4mAc6OwlXCQOCNv0GQCINCkxgEPiYBzo7CVcJAQG3DQSDkf0InMQg+JwHOjsJV2kAIcMdBwAh5QrpJDD4qAc6OwlUoQWCeykEA3HFCTmIQPi4Bzo7CVX1BGD/NQeBdakLhehQ+MwHOjsJV80HYkNBBQJphQpqZGT45Ac6OwlV5QoDP0UEgHFpCLbIdPj0Bzo7CVdBCkDHTQQCeUkLByiE+QAHOjsJVGEM4cNRB4MJKQlTjJT5BAc6OwlU/Q0jS1UHARENC5/spPkMBzo7CVVtD6F/WQUB1O0J7FC4+QwHOjsJVW0MAc9hBQAMyQjMzMz5DAc6OwlVbQ6ix2UEghSpCx0s3PkMBzo7CVVtDuBPbQQAHI0JaZDs+QwHOjsJVW0NoA91BQNobQu58Pz5DAc6OwlVbQyCk30GAChVCgZVDPkMBzo7CVVtDeNLiQYCADkIUrkc+QwHOjsJVW0M4JOZBYAIHQs3MTD5DAc6OwlVbQ1hV7UFA2/lB9P1UPkMBzo7CVVtDgDf1QUD35kEbL10+QwHmjsJVW0PYGwFCwM7OQfp+aj5DAamPWVVbQ8y1BkKA0r9BtMh2PkMBJJD/VFtDkJYMQgC+tEFKDII+QwGIkMZUW0OwxxNCgDOwQXE9ij4/AeCQtFRbQ6jwG0IAebFBqvGSPjgB/ZC0VAdDyCEjQkDqvUGamZk+OAH9kLRUW0JsqypCACzOQXe+nz44Af2QtFRbQtzsL0JA49lBCtejPjgB/ZC0VFtCHHU1QoCa5UGwcqg+OAH9kLRUbUKMtjpCQAzwQUSLrD4+Af2QtFTqQnifP0KAfvhB16OwPkYB/ZC0VJ1DaBdHQoDJAULHS7c+UQH9kLRUoUQ0qU1CIL0EQqRwvT5XAf2QtFQtRXziU0JADgZCkxjEPlkB/ZC0VFdFgEtfQkCxBUJg5dA+WQH9kLRUV0XQNWZC4BoCQj0K1z7zAP2QtFRXRWRdbELAIPtB46XbPkwA/ZC0VD4tMhQNAACgQBUAAGBBHQAAhEIlAACMQkDAn9OfkwU6BggAEAAYAEIQxjieV95cTuaAtuVXCPxhZA==" let drawingData: PKDrawing = try! .init(data: Data(base64Encoded: base64String)!) let image = drawingData.image(from: drawingData.bounds, scale: 2) // -> fails
0
0
490
Dec ’21
NSPersistentCloudkitContainer makes Cloudkit Metadata Migrator
Hello. Now I'm trying to add Cloudkit + iCloud synchronization feature with NSPersistentCloudkitContainer. It's super easy and cool. However, When I tried some test with large data, there is expensive cost task on every app launch time. Actually, this task also executed on small dataset, but its cost increased by increasing local core data storage. This task seems like migration for cloudkit. I guess that this task save additional data on local storage. (I checked this on Settings > General > iPad Storage) This task takes 20 minutes (with 5GB test data, core data storage) on background thread , using full of one core cpu. Importantly, if there is new data to sync, the synchronization starts after this heavy migration task ends. So if user create new data and terminate application before migration ends, that new data never synchronized. Also, if I delete my cloud data on Settings > Account > iCloud > Manage Storgae, my local app storage remain some of data. My all local data to used on application is deleted, but some data remains. I guess this data is related to migration task. The evidence is that application still execute migration task after deleting all cloud data, and local storage increases while this task executing. I submit the core data stack I used and capture of time profiling. Please give some advice. Thank you. ps. Additionally I update all rows to force sync for existing data(before NSPersistentHistoryTrackingKey added), is it right method? My CoreData Stack - https://developer.apple.com/forums/content/attachment/d90ea212-1d99-4475-bcd4-17663bf5208d Time Profiling result: - https://developer.apple.com/forums/content/attachment/aec4e32a-bc17-454d-93c9-4b1a1a692f35
0
0
695
Jul ’20