Good job, and I regret to hear that it seems you were given some bad advice from authority.
There's a lesson I learned at around 12 or so, good to learn sooner than later. Don't trust the experts, for the sake of being experts.
I probably have a few good burn out stories to share, but since this is a public forum and you're anonymous, let's just say that it's part of the experience. Learn, live, move on, towards something better.
Start with smaller projects, something simple based on either what you already know, or an existing lesson/blog/book. Then adjust it a little bit, work iteratively, towards the new stuff.
It's really easy to get lost in the big picture of what you want to do versus what you can do. Try not to do that. Just work on smaller bits involving the new stuff, falling back to what you already know at times, and keep at it. If there's a way you can do ColdFusion with Ruby/Python/whatever, go for it.
If you haven't seen it yet, Zed Shaw's Learn Code The Hard Way[1] series does a good job of getting you to use the right tools for the environment. Which is something I see frequently ignored by these sort of online lesson plans... it's not the languages themselves that are difficult to learn, but getting accustomed to the tools to use them, and the best practices.
I use -drawRect any time I need a UIView's CGContext. For everything else, I use -layoutSubviews.
When you do anything in Core Animation in -drawRect, that throws all drawing on CPU, instead of dividing the work between the CPU and GPU. Which, in one project where I was doing Core Animation alongside OpenGL, that had some very bad consequences.
Core Animation is pretty interesting. Internally, it does some drawing with Core Graphics, but that's only if you use certain features (i.e., use of CAShapeLayers, anything involving shadows)... and even then, CG is pretty darned fast.
I've found CAShapeLayers can be a bit of a resource hog, but since those resources tend to be thrown behind 60 fps animation, that might not be such a problem.
The CAShapeLayer issues only came up when I tried scrolling within a scroll view that contained a CAShapeLayer with a CGPath that had 20 points defining lines. Setting the CAShapeLayer to -shouldRasterize:YES after the animation completed "fixed" the issue, as long as you didn't need to scroll while the CAShapeLayer was animating.
(Don't even bother animating a CAShapeLayer while -shouldRasterize: is set to YES. That just causes even more fun problems with dropped frames.)
Keep calm. Reach out to people, old and new. Plan, and work towards a better tomorrow. Do not give in to fear.
Be sure to call your parents at least once a day. It makes a difference. And remember, the best way you can help others — especially family — is to help yourself.
I know that all may sound a bit trite, but it's how I tend to manage every personal crisis. I'm going through a significant rough patch, right now. Can't be paralyzed.
Which is what I meant by "within the bundle of your app." That may have been a bit too iOS developer-centric, I apologize.
In Foundation, [NSBundle mainBundle] returns a reference to an object representing your application's root directory, and the code and resources found within. Roughly the same bits that you'd find within an unpacked IAP file.
As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself.
You don't necessarily need BridgeSupport to call out to Objective-C.
Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame.
That's fair. This does save one ugly, extra step that I didn't mention, which would be to call into the Objective-C runtime's C API [1] to dispatch messages and introspect Objective-C classes.
Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate.
Functionally, this appears to be identical to JavaScriptCore's longstanding C bridge [1]. If Objective-C isn't your preference, there's nothing stopping you from calling into the C bridge from C++ or just plain C.
On iOS, developers have had to compile their own version of JavaScriptCore to use this API. That's the basis for HTML5 game engines like Impact [2], and some HTML5-to-Objective-C middleware platforms.
Unfortunately, until Apple says otherwise, this version of JSC is still subject to Apple's App Store review guidelines [3]. Thanks to guideline 2.8, you can't have your app, running JSC, execute any JavaScript that doesn't ship within the bundle of your app.
I'd like to see that rule change, someday. Exposing this Objective-C API in a future iOS release isn't going to change the status quo.
Just one nitpick for an excellent comment. GNUstep/Clang would be the only way to get support for array, dictionary and number literals, as well as ARC.
GNUstep/GCC is possible, but you lose support for all of the above, blocks, and several other recent additions to the Objective-C language.
That's a good observation, some inefficiencies are quite intentional. I didn't even know that about Linux until just the other night, when I was looking for non-GNU GPL projects that didn't require this process.
LWN.net has covered both sides of this subject quite well, in recent months, with the tedious process of relicensing VLC [1] and the GnuTLS copyright assignment controversy [2].
The politics of OSS make for some excellent reading.
Interesting. Do you have details on which jurisdictions do not allow this, and why?
I admit that I'm not familiar with international copyright law. I do know that several GNU projects, and other high profile open source projects, have a policy in place wherein contributors have to agree to a copyright assignment agreement before they can contribute their modifications.
If that's not possible in some regions, they clearly still have some means of continuing to uphold their own IP. I suspect it's not as harsh as completely avoiding contributions from some regions of the world. Unless I'm mistaken.
Ideally, a well-organized project would have a copyright assignment process to resolve those sorts of issues.
However, as far as I know you're right. If there's no clear authority as to who retains ownership and licensing rights to the code, and the contributions made to it, it's going to get messy.
It's possible, though it depends on the wishes of the original authors.
Stockfish Chess [1] is the one GPL v3 licensed app that I know of which has been available for... quite some time, now. I've seen several other Chess apps build on that engine, which go as far back as when I was just starting iOS development.
Now, VLC was the one case where one volunteer for the project invoked the GPL to get Apple to take an iOS port of the app off the store [2]. Based on that situation, it seems that if the original authors of a GPL licensed codebase want to pursue a claim against an app that uses that code, they can, and Apple will take it seriously.
I don't believe that situation has changed.
EDIT: For your own sake, it's probably best if you approach the original author to see if they can make an exemption, in writing, for the DRM situation. IANAL, but that seems like it would be the cleanest way to go about handling GPL licensed code without issue.
WindowMaker split off from the GNUstep project quite some time ago, IIRC. They don't even use Objective-C, they use their own framework for widgets built on WM called "WINGs."
There's still activity on the GNUstep front. Just a few things I can think of,
- Their runtime, libobjc2, has done a great job keeping pace with Clang and modern Objective-C. It now has a Cmake based build system and doesn't require any bootstrapping with GNUstep-make.
- GNUstep-base (the Foundation alternative) is solid, though some parts go back as far as OS X 10.6 and others OS X 10.4. You'll have to check the headers to see what's up to date. They do have an extremely capable implementation of distributed objects, last I heard they were planning to make it integrate with Apple's distributed objects implementation, but that project still seems to be pending.
- GNUstep-gui (AppKit alternative) just added support for 10.6's NSCollectionView very recently. Most activity there has been in the form of refinements. As I recall, drag and drop is still on their todo list... they really could use some manpower there.
- GNUstep-back (the backend renderer) still uses an API that's largely based on Display Postscript. They are planning to pitch a GSoC project to replace the Display Postscript API with one based on GNUstep-Opal (a Core Graphics alternative), and they already have a largely proof of concept Core Animation alternative running on it (GNUstep-QuartzCore.)
The project's current vision is to focus on making it easier to port Objective-C to other platforms, rather than to be a desktop environment. But like most small, mature open source projects, there's a lack of manpower keeping them from easily achieving those goals. Would be nice to see more activity there, in the future.
As for the current website, I think Scott Stevenson designed it a decade ago long before he joined Apple. I like the design, personally, but I do understand that it's a bit difficult to navigate... and several of the docs haven't been updated in some time.
> They need a vastly bigger space, or multiple conferences throughout the year, or a higher price, or something to manage the insane demand, if they actually want to improve this stuff.
Regarding multiple conferences, Apple decided not to do the Tech Talks for 2012. I hope they'll reconsider for 2013. That really was a great resource to have, and the 1:1 with the evangelists and DTS was excellent.
For higher prices, I keep on hearing this rumor and it never happens. There was a bump in the prices around 2010, and it never went further up from there. Maybe they're afraid of pricing out the indie developers? I have no idea.
And if you want to be a little less selfish, make it something that frees more than just you.
(bye for now)