Re: Modeller/Mac
Re: Modeller/Mac
- Subject: Re: Modeller/Mac
- From: OC <email@hidden>
- Date: Mon, 28 Mar 2016 19:52:26 +0200
Flavio,
On 28. 3. 2016, at 16:08, Flavio Donadio <email@hidden> wrote:
>> […] I am building my apps in Xcode […]
>
> Could you elaborate on this? Are you telling us you use XCode to do Java development? How well does it work?
Short answer: I do (essentially, see below re Java), and it works much better than Eclipse for me.
Nevertheless, there are _very_ serious drawbacks; if Eclipse works reasonably well for you, you probably won't want to switch to Xcode. I develop lots of things for Mac OS X and for iOS, too; this is why I stick with Xcode, for I prefer having the same source system and editor for all my projects. If you don't, you would do better with another IDE, better suited to customizations (AppCode is said to be pretty good, though I haven't tested it myself).
First thing, I still use Xcode 5.1; I did not get to test newer ones yet, it might work well, it might not. Note that I parted with pure Java long ago; myself, I consider it a terrible language. Therefore, I use Groovy, which allows me e.g., instead of this contraption
=== this is what Java forces us to write, business logic lost in heaps of boilerplate ===
NSArray validOfferItems() {
NSMutableArray ma=null;
if (auction!=null) {
NSArray all=auction.orderedPriceOffers();
if (all!=null) {
ma=new NSMutableArray();
for (Enumeration en=all.objectEnumerator();en.hasMoreElements();) {
DBPriceOffer po=(DBPriceOffer)en.nextElement();
if (po.validOffer()) ma.addObject(po);
}
}
}
return ma;
}
===
to write this code
=== this is what Groovy allows, all business logic, no boilerplate ===
NSArray validOfferItems {
auction.orderedPriceOffers.findAll { it.validOffer }
}
===
Besides, Groovy adds dynamic services which remind one of ObjC (e.g., I do not need the ugly mess of _EOWhatever superclasses; my enterprise objects install accessors based on the model automatically at runtime, just like it was intended to work from the very beginning -- similar way it works today with Core Data).
Nevertheless, it is not easy to teach Xcode to work with Groovy sources properly. There is essentially no syntax-based auto-completion (in Eclipse there is one, but it never worked for me; whenever I tried, it simply shown the rainbow disc for a couple of minutes and then auto-completed nothing anyway). Xcode, at least, can reliably auto-complete strings used before in the same source. I have added my own xctemplate for .wos, too; they can easily be edited in Xcode's assistant editor, but -- unlike Eclipse -- they will not open this way automatically, alas.
For building, I use an “external build system” target with my own build script. Again, if you use Eclipse/Java, you might get better; Eclipse/Groovy was a disaster though: the incremental build 50 % of time simply did not work, running some old classes along with some new ones, ick. My scripts work 95 % of time, and I know precisely what causes the 5 % of problems (outdated .class files not removed) and can dodge it. One of worst current problems for me is no typechecking; this can be cured and I know how to make a typechecking system essentialy same as ObjC's for Groovy (its native one is seriously lacking), but so far, I did not found the time to do that.
Similarly for testing I use my own run script. There's only one drawback, but it's pretty serious one: no debugger (I've played with jdb, but did not suceed to integrate it into Xcode). Again, if Eclipse debugger works all right for you, you are _much_ better with it; for me (with Groovy) it never worked reliably, so I lose nothing, am down to log-based-testing anyway.
I don't mind sharing those scripts and tools (http://www.ocs.cz/CD/ocswobuildxcode.zip), but be VERY wary with them! They are hand-tuned to my own specific needs (e.g, they hard-code building a shared code from a separate OCShared project; there's a half-baked not-working support for the Groovy typechecking, and worse), and very definitely they CANNOT be used as-are -- at best, you might start with them and prepare your own build system based on the ideas.
Whilst I do intend to make those scripts generic enough, alas, so far I had no time for that :(
All the best,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden