CoreData relationships sample

[jj]

I've just uploaded a sample demonstrating how to create CoreData relationships programmatically in rubymotion.

https://github.com/caramdache/games

Enjoy,

[Jim Nanney]

Thank you for sharing this.  I'm still trying to figure out Core Data, and even tougher is doing it without Xcode, and the data modeler.  Even Hillegass' and Marcus Zarra's books depend on them.

[JJ]

It turns out to be simpler without Xcode -or, said otherwise, having had to expand Laurent's example to support relationships, I had to understand core data from the inside, i.e. from the meta programming point of view - turns out to be quite useful. This is an area of the Apple doc I had never to dig through before and I now understand core data better. 

The Games sample uses two methods to retrieve objects. The simplest one fires an NSRequest and returns the results as array (.objects).

The more complex one returns an NSFetchedResultsController (.controller). Think of it as an impedance adapter than provides an UITableviewController like interface and splits objects by section for you (this would a hash in ruby).

Read the doc for these two classes. 

What I like about creating core data models in ruby is that I do not have to open Xcode again. It suddenly feels a lot lighter. YMMV

[Mac Fanatic]

I'm using Nitron (after fighting with motion-record) and just plain CoreData & have to say its awesome.

There is a tutorial on the main Nitron project, which supports the Xcode data modeler. Relationships are supported, and I have several pull requests for useful features. Using this in an iPad app under dev currently.

[Mac Fanatic]

Link - https://github.com/macfanatic/nitron

[Jim Nanney]

Nitron is neat, but if I can help it,  I never want to open Xcode again.

On Wednesday, June 20, 2012 9:44:15 PM UTC-5, Mac Fanatic wrote:

Link - https://github.com/macfanatic/nitron

[Matt Green]

I feel the same way. 

We're working toward text-based workflows while providing something that works in the interim. I'm keen on supporting iCloud and CoreData, and that requires lightweight migrations.

[Steve Ross]

I can understand some loathing for Xcode or a sense of dirtiness messing around with magic glue, but is there a technical aspect to the Nitron approach that will handicap migrations or otherwise inject noise/overhead into the app?

Thanks

--

[Matt Green]

No.

I've begun work on an XCode-less version of CoreData support that generates .xcdatamodeld files via rake tasks. This creates a nice workflow that is very similar to that of Rails:

1. Write models, put them in app/models

2. rake dm:migrate # scans models, generates xcdatamodeld, and compares to existing one. If new, saves new version and activates it

3. rake

Check it out at https://github.com/mattgreen/nitron/tree/0.3

Is this what you're looking for?

[Jim Nanney]

Fantastic! Other than not wanting to deal with Xcode, there is no good reason I can come up with.  But it feels great to use textmate, ruby motion and the simulator only. 

[Steve Ross]

I'm trying to use relationships in nitron and you mentioned that you had pull requests in that support them. Were they incorporated? In any case, I may switch to your branch and merge my own changes. Can you give me an example of the syntax for relationships? I.e., does it work like:

class Owner
  has_many :tasks
end


class  Task
  belongs_to :owner
end


...


Owner.first.tasks << Task.create(:task => 'Walk the dog')

Mind you, I'm just making this stuff up. What I'm really looking for is some guidance to get me past the single-table stuff that seems so simple using Nitron.

Thanks,

Steve

[Steve Ross]

I should mention, this was intended as a follow-up to Matt Green and Mac Fanatic's posts and only relates to Nitron and it's use of the XCode data modeler (which I agree is not optimal in the dev workflow, but right now works...).

Steve

--
 
 
 

[Bodacious]

I know this is an old post but have any of you guys tried MotionData? Looks great but I can't get it to load without crashing :/

[Steve Ross]

I am working on some of the issues in MotionData and would love it if you would raise issues on GitHub. Right now, I'm not building gems each time I do a push. Too much churn. So if you clone the project and put:

require "/path/to/motion_model/lib/motion_model.rb"

in your Rakefile instead of requiring the gem or listing it in your gemfile, you can stay right on the bleeding edge. Also, if you watch the project, you can see when commits happen so you can decide whether to pull fixes.

Steve

--
 
 
 

[Eloy Durán]

Can you tell me more about the crash you are experiencing?

--
 
 
 

[Eloy Durán]

Steve, did you really mean MotionData? Because you code sample is regarding MotionModel. If it is about MotionData, I’d love to hear about it :)

--
 
 
 

[Steve Ross]

My mistake. Note to self: read first, write second :)

Sent from my iPhone

--