Blog Archives

CoreData on macOS Mojave (10.14.0) shenanigans

9/26/2018

UPDATE (10/16/2018): Apple has closed my bug report about this as resolved. So hopefully the fix will be out on Mojave 10.14.1

tldr: overwriting a binary blob greater than 100kb will unnecessarily create extra files on each save with CoreData on macOS Mojave (10.14.0)

Hookay, I was pretty excited to try out macOS Mojave and their dark mode. Instead I found a bug in CoreData

If you'd like to follow along the code, the code is available at my github:
https://github.com/gietal/AppleSandbox/tree/master/CoreData/CoreDataPlayground

Quick overview of CoreData, it stores your data in a sqlite database which live in your App's "Application Support" folder under ~/Library/<Your app bundle identifier> or ~/Library/Containers/<Your app bundle identifier>/Data/Library for sandboxed apps. You can store different types of data with CoreData such as string, int, float, bool, and even binary blob. When storing binary blob, you have an option to store it on an external storage:

This is useful for bigger binary blob, as it’s less efficient to store and fetch a big binary blob form the sqlite database. If you try to store a big binary blob (bigger than 100kb), and you have that option enabled, CoreData will automatically decide to store your blob into a hidden folder called <Your DB name>_Support/_EXTERNAL_DATA

The blob will be stored as a file named with a random UUID, and that UUID is what’s then stored in the sqlite database. You can examine your sqlite database content with DB Browser for SQLite (free from https://sqlitebrowser.org). You can see that the value for my binary blob attribute is the UUID of the file under _EXTERNAL_DATA. This is how CoreData manages your big binary blob.

The value of the binary attribute in the sqlite DB is actually the UUID name of the file on the _EXTERNAL_DATA folder

When you update your binary blob from your code, then the blob file under _EXTERNAL_DATA is also overwritten with the new blob. However, this is not the case in macOS Mojave 10.14.0, which is demonstrated by my sample project

The sample project is quite simple, I have have an Entity with 2 simple attributes: an id (string) and an image (binary blob) with “Allows External Storage” selected. The id is so that I can fetch the same instance of the entity. When you run the app, you will see a window with a save button.

Each time you hit the save button, it will try to save the displayed image as a binary blob to the entity’s instance in the sqlite database. Since the binary blob is greater than 100kb, it will store it under:
~/Library/Containers/com.gietal.sandbox.CoreDataPlayground/Data/Library/Application Support/CoreDataPlayground/.CoreDataPlayground_SUPPORT/_EXTERNAL_DATA

If you hit the save button multiple times, it will try to overwrite the binary blob with the same image every time. Now here’s where the problem lies. On macOS High Sierra (10.13.6) there is no issue with this, the binary blob is overwritten correctly. On macOS Mojave (10.14.0) however, this is not the case.

When you try running the same app on macOS Mojave, and start hitting the save button multiple times, you will observe that a new file keeps getting added under the _EXTERNAL_DATA folder. This is a serious problem as overtime the amount of useless files keep getting piled up inside this hidden folder. Normal non-savvy users would never know how their mac ran out of space so quickly due to this issue.

I submitted this issue to Apple’s Bug Reporter, and they acknowledged that it was a bug and are working on a fix. Hopefully macOS Mojave 10.14.1 come out soon with a fix for this.

A workaround you can do at the moment is to save the entity’s instance with a nil value for the binary attribute, and save it so that CoreData delete the external file. Then, you can save the instance again with the proper binary blob.

// magic functions to get the CoreData context and entity's instance
let context = getContext()
let entity = getEntity()

// nil out the binary blob, so CoreData erases the file in _EXTERNAL_DATA
entity.setValue(nil, forKey: "image")
context.save()

// then actually save your new blob
entity.setValue(blob, forKey: "image")
context.save()

0 Comments

custom NSOutlineView disclosure button

9/1/2018

0 Comments

NSOutlineView is a very nice template to create a Finder-like table view of your collection. However, as any other things Cocoa, it is very easy to create UI that looks "standard", but it's not that straight forward to customize it.

For instance, right out of the box, NSOutlineView already looks like the Finder app, complete with the collapse button (disclosure button is what they call it).

This is great to start with, but now what if I don't like the default triangle disclosure button? What if I want to use my own image for the button? One would think that there must be an image/alternate attribute for the disclosure button or something, but no... there isn't.

So we have to devise a roundabout way to customize the button..

Here's how you can customize the disclosure button

First, we have to add a new button to the expandable column of your outline view, usually the first (left-most) column. In my case, it's the "Hostname" column.

Change the button type to "Toggle"

Put your desired images on these fields:

Image: The image when the disclosure button is expanded (down arrow)
Alternate: The image when the disclosure button is closed (right arrow)

I'm using what the framework provides here, but you can put whatever image you want from your asset catalog

Now, add an identifier to this button so that we can create this button with the identifier. Let's name it as "MyDisclosureButton".

Now, NSOutlineView create its views by calling makeView(), providing the appropriate identifier for each elements on the table. In order to create our own button, we have to subclass NSOutlineView and override this function. When NSOutlineView is about to make the disclosure button, we can intercept this call by checking the identifier that it sent.

class GNLOutlineView: NSOutlineView {
  override func makeView(withIdentifier identifier: NSUserInterfaceItemIdentifier, owner: Any?) -> NSView? {

    // intercept disclosure button creation
    if identifier == NSOutlineView.disclosureButtonIdentifier {
      // then create our custom button
      let myView = super.makeView(withIdentifier: NSUserInterfaceItemIdentifier(rawValue: "MyDisclosureButton"), owner: owner) as! NSButton
      
      // we need to change the identifier so that the outline view knows to use this view as the disclosure button
      myView.identifier = identifier      
      return myView
    }

    // for everything else, use the default function
    return super.makeView(withIdentifier: identifier, owner: owner)
  }
}

Change the outline view to use GNLOutlineView as the custom class from the interface builder. When we build and run we should get this:

Great! We can now display custom disclosure button for our outline view!

But wait a second... when we click on our disclosure button, nothing happen! The group doesn't collapse, and the button doesn't change its image. It would seem like we didn't set the target+action properties on our button, so the button doesn't do anything when it's clicked.

Where should we point the target+action of our button to? Let's cheat and take a look at where the original disclosure button's target+action pointed to. After all, they were already working without us explicitly modifying anything, so it must be pointing to the correct target+action!

We can create the original disclosure button by calling the super's implementation of the makeView function

// get the original disclosure button
let originalButton = super.makeView(withIdentifier: identifier, owner: owner) as! NSButton

If we stop the debugger after the creation of the original disclosure button, we can inspect the values of the button's target+action (if you drill down enough)

It would appear that the target is just our outline view, but the action is more interesting. The action points to a function called _outlineControlClicked. Since we don't see this function on NSOutlineView AND it starts with an underscore, it is highly likely that it is a private function (an Apple engineer I met at WWDC 2018 told me about the underscore prefixes on private functions and properties).

A simple solution to this is to assign our button's target+action to the target+action of the original button.

myView.target = originalButton.target
myView.action = originalButton.action

Now, after we hook our button's target+action, we can see that our disclosure button now works perfectly!

0 Comments

CoreData on macOS Mojave (10.14.0) shenanigans

custom NSOutlineView disclosure button

Archives

Categories