Just trying to create a simple Mac app to learn Oxygene with, and having some trouble understanding how it all meshes. I create a new application in VS and it builds all the files, but how do I edit the forms ?
The Xcode sync doesn’t transmit the .xib files over to the mac, and there doesn’t seem to be any forms editor on the VS side, so how is this supposed to work ? When I open the xcodeproj on the max it shows the mainmenu and maniwindowcontroller .xib filenames in red, which I presume means they are missing. I copied the files over manually and changed their properties to absolute path which allowed the xib editor to open. Is there some way to do this automatically ? How do you preserve whatever the editor does with respect to the linkages between the buttons etc and their handlers ?
I’ve been reading the Apple tutorial on mac apps but it doesn’t help a lot since it’s just on Xcode. I guess the real question is where do I develop the application, in Xcode or VS. Right now it looks like I need to do everything in Xcode and then copy it all back to VS which seems like a lot of duplicated effort.
I don’t know if this will be much help, but have you tried the new Fire on the Mac ?
Seems like it’s the goto editor for developing Mac + iOS projects.
It has both Oxygene (my preferred language) and C# languages baked in.
Well too late, I read it. At least the faq and Cocoa page cleared up something for me: Oxygene is not a cross-platform development tool, it’s just a cross compiler. So for the mac/ios, I need to write my app in Xcode and then cut/paste the oxygene bits and pieces into the Xcode project, although I guess the Sync thing does the cut & pasting for me, sort of.
Thanks, but if I have to use Xcode to create and modify the app, I might as well just use Xcode for the whole thing.
@Jeff_Williams I think you’ve misread it as that’s not the case at all. The reason @mh said not to read the Cocoa# page is that it’s no longer applicable. Oxygene/RO C# apps do not need to use Cocoa#.
Pretty much the only time you need to go to Xcode is to edit the UI definition files (called xibs). The code part of the app can be written entirely in VS or Fire using Oxygene and/or RO C#. Now it’s fair to say that Oxygene/RO C# are not write once build anywhere solutions. You can however share a lot of code between platforms by designing your app appropriately and by using a cross platform library called sugar. Primarily it will be the UI layer that is platform specific.
There is an advantage to this. If Apple decides to change what a button (or an entire OS) looks like then your app written in Oxygene and using the native UI controls will automatically pick that up. Those solutions offering 100% cross-platform code tend to use non-native controls and your app will stick out and look wrong.
@Jeff_Williams
Just to add my 2cents worth.
I’ve tried many systems that are “Write once, run anywhere” and they tend to look ugly against their native counterparts. Also IMHO they tend to be much slower and the users don’t like the looks.
Going the Oxygene / XCode XIB way is complex I will admit (especially those double methods) but in the long run I believe it’s best. You get a true native feel on the device you are deploying to and nothing to cover it over.
Stick with Oxygene…It’s a superb language.
I came from Delphi and just wish I had made the jump a lot earlier.
Mike and his team are brilliant + they really listen and care.
–Now if only they would write a system around Javascript / HTML
That would be a lot of the time, especially in the beginning. The virtual lack of documentation about this is a big hindrance. The underlying assumption seems to be that you already know how to create iOS/Cocoa apps, which isn’t true in my case. The obsolete Cocoa page was the first time where I saw it mentioned that you have to copy the Oxygene project files over to Xcode so that you can use the interface designer. I thought that was what the Sync to Xib function did. The learning curve here isn’t quite Eve Online, but it’s steep enough that it’s hard to see that the reward justifies it.
I guess what I should do is go learn Xcode & Obj-C first. After that, if I’m still interested I can try Oxygene again.
You don’t need to copy over the Oxygene files over. They’d be useless there anyway. The IDE will generate objective-C dummy classes that allow you to connect up the UI elements to outlets and actions on your class in Xcode.
You do need to learn a bit about the API’s but not necessarily a huge amount about objective-C. A reasonable knowledge will help to understand the Apple documentation though.
No, you do have to copy over some of the project files: at a minimum the .xib or .nib, whatever. I don’t know what other files have to be copied over because none of it is documented. The old Cocoa page assumes that all the project files are present in Xcode. It’s also not documented what files you need to copy back to your VS dev machine, so by default I should copy the whole project directory back and forth to make sure nothing is missing. The problem as a new Mac developer is that I don’t already know which are the necessary files that I need to use under Xcode and the Elements Wiki doesn’t tell you what you need to do. It just says open the .xib with Interface Builder. There is no Interface Builder in VS. What it should have said (and doesn’t) is “copy your project directory over to your Mac and launch the Interface Builder in Xcode”. That lack of information is what makes this process so frustrating.
The idea really is that you use a shared folder, and can just open the .xcodeproj in place, without worrying what files are affected. Barring that, you’ll need to basically copy the entire project folder back and forth, to be sure you get all the relevant files (and keep all the relative paths in place). But i’d recommend against that.
SO using the shared folder, you’d just invoke Sync, switch tot he Mac, and double-click the .xcodeproj file. Done.
I agree that we probably need to document this better.
I also completely new to Mac development, though I’ve been using Mac for quite a while. Though it does have a learning curve, but it’s not as hard as I thought before. All you need is a complete clear mind set and understand how the Mac system works. Especially if you came from Delphi and Windows. It’s different, but not hard. Once you understand the way it works (I don’t understand them all yet), I believe you’ll start to like them, and wonder why Windows/Delphi don’t act like Mac/XCode. It’s even possible that you’re gonna love them. Because I do for some parts.
And, Fire helps a lot too. But, don’t forget XCode. It’s de facto and legal development system for Apple platform. Especially the brand new Swift language. If you think Objective-C is hard, Swift is far from that. I’m starting to like Swift too. And XCode Playground is a wonderful tool to learn about Swift.
