Realm-cocoa: Support for NSURL

[alejandro-isaza]

RLMObject should support NSURL properties.

[matthewcheok]

Agreed. Alternatively, maybe allow devs to specify how custom properties should be encoded or decoded.

[timanglade]

We agree… We’re debating making those extra types work cross-platform (at least iOS & Android) or not… Any thoughts?

[benkraus]

I too would like at least some custom serialization and deserialization. I see some bare bodied functions that might encapsulate this behavior in the future: - (NSString *)JSONString. Is that the intent? In my use case, I am using Swift enums to model something that makes since to use an enum and not much else - I would love to be able to override a serializer and deserializer to define how that property should be... serialized and deserialized.

[timanglade]

@benkraus These are remnants of an early attempt to provide a built-in JSON serialization of any RLMObject or RLMArray. We’re working on a new implementation at the moment, in the meantime you should check out https://github.com/matthewcheok/Realm-JSON !

[benkraus]

Thanks for the link! I will check it out for sure.

[tspecht]

Is NSURL supported anytime soon? What about UIImages?

[GreatApe]

@scriptedSheep
Perhaps you are aware of this, but you can always convert UIImages to NSData, and the store that in a data property. It's quite convenient.

UIImage *myImage = ...
// To NSData
NSData *myData = UIImagePNGRepresentation(myImage);

// To UIImage
UIImage *anImage = [UIImage imageWithData:myData];

[tspecht]

I'm aware but which method should I override in order to do the conversion in my RLMObject subclass? Sorry, I just started using Realm a couple of hours ago ;)

[GreatApe]

Do you really need to make it that automatic? If you are fine with writing

UIImage *anImage = [UIImage imageWithData:myData];

when you access it, you don't need to override anything. Just create a realm model with an NSData
property, and store images in that (in NSData format).

Or is there a particular reason you want to abstract it away?

[matthewcheok]

I think there's some value in being able to hide away implementation details like this; we can do that with NSCoding. Furthermore, I suspect there might be a performance penalty if you need to keep converting NSData to UIImage repeatedly.

[alazier]

We would like to support all types which implement NSCoding, but this adds complexity when trying to make things compatible across platforms. My thoughts on the issue are that if a user wants cross platform support they should only use primitive types which work on all platforms - other people disagree though and we haven't yet made a decision. If we don't end up supporting NSCoding, we will at least add direct support for NSUrl but it's not clear when this will happen.

As far as converting between NSData and UIImage goes, you shouldn't gain too much in performance by adding NSCoding support. At most we may save a data copy, but no matter what the image data needs to be decompressed in memory. Not having to write the boilerplate conversion code would be pretty nice though.

[olafurr]

@alazier Any news on the NSURL support ?

[alazier]

We will support this by adding a metadata table and storing urls as strings under the hood.

[tspecht]

@alazier that would be really awesome! is this gonna make it to the next release already?

[matthewcheok]

Any chance we would also get support for other NSCoding/NSValue types?

[alazier]

@tspecht no concrete eta but should hopefully get started on this in the near future.

@matthewcheok I don't think we want to support all objects supporting NSCoding as it would make it difficult/impossible to do queries efficiently and would also complicate cross-platform compatibility. What other types in particular do you want support for?

[matthewcheok]

How about CGPoint, CGSize, CGRect and CGAffineTransform? They would be store in a reasonably cross platform way perhaps?

On Sat, Dec 6, 2014 at 8:22 AM, Ari Lazier [email protected]
wrote:

@tspecht no concrete eta but should hopefully get started on this in the near future.

@matthewcheok I don't think we want to support all objects supporting NSCoding as it would make it difficult/impossible to do queries efficiently and would also complicate cross-platform compatibility. What other types in particular do you want support for?

Reply to this email directly or view it on GitHub:
https://github.com/realm/realm-cocoa/issues/599#issuecomment-65875604

[matthewcheok]

And CLLocationCoordinate2D

On Sat, Dec 6, 2014 at 8:22 AM, Ari Lazier [email protected]
wrote:

@tspecht no concrete eta but should hopefully get started on this in the near future.

@matthewcheok I don't think we want to support all objects supporting NSCoding as it would make it difficult/impossible to do queries efficiently and would also complicate cross-platform compatibility. What other types in particular do you want support for?

Reply to this email directly or view it on GitHub:
https://github.com/realm/realm-cocoa/issues/599#issuecomment-65875604

[jpsim]

@matthewcheok After the initial PR with a first type to work out the exact approach, it should be easier to add new types. At that point, it will make sense to propose new types.

[Entalpi]

So, one year later. How does things look with the NSURL support? :)

[luna-kx]

What's the status on this?

[jpsim]

This isn't being actively worked on at the moment.

[luna-kx]

@jpsim: :disappointed: Okay.

[antiero]

What is the recommended way for storing NSURLs? Just write them as Strings then convert back to NSURL when retrieving the data?

[luna-kx]

@antiero: Yes. Saving the absolute string of the URL in your model is the best work around. Though I wish Realm would do that conversion for us!

[yankeguo]

Any progress on NSCoding support? I wish Realm could support any NSCoding class by backing up with NSData.

[jpsim]

No progress to report.

[yankeguo]

@jpsim

I made a quick and dirty workaround to support NSCoding by using NSData as underlaying persistence format.

You can find the diff it here.

https://github.com/YMXian/YMFoundation/commit/50b3878404fee8582f2918b7589173cef4067a6f

It's basically the original version of Realm 0.98.2, I just kept iOS static framework stuffs only.

I need your advice. Thanks.

[yankeguo]

@jpsim

For now, Read/Write, Auto-Updating works, I wonder will this modification crash other things.

[jpsim]

I'm sorry I don't have much time at this point to review external projects.

[yankeguo]

@jpsim

That will be fine, I will do tests and create a pull request once it's proofed as matured.

[jpmcglone]

+1

[mitchdrew]

bump

[alibasta]

+1

[Isuru-Nanayakkara]

+1

[jVirus]

+1

[ppamorim]

Two years feature... Very tasty.

[jonchui]

+1 - any news on this? thanks!

[thbaja]

+1

[onmyway133]

A workaround is to to use a computed property

class Product: Object, Mappable {
  dynamic var id: Int = 0
  dynamic var image: String = ""

  override static func primaryKey() -> String? {
    return "id"
  }

  required convenience init(_ map: [String : Any]) {
    self.init()

    self.id <- map.property("id")
    self.image <- map.property("image")
  }

  var imageUrl: URL? {
    return URL(string: image)
  }
}

[markcdb]

+1

[d-srd]

+5

[Zeta611]

+1

[d13nunes]

+1