Nice idea, but the sample code they show in the screenshot uses "FALSE" instead of NO (the Obj-C standard boolean literal).
I'm not sure how they did that (#define?) but stay far, far away. Imagine if you opened up a Ruby codebase and found out I had aliased NO to be the same as the language builtin false... yeesh.
Also, setting boolean instance variables to NO in init is silly since Obj-C objects are calloc'd, so all ivars are guaranteed to start with default values (nil/0/NO).
CFBase.h defines TRUE as 1 and FALSE as 0. There's no reason to think that they defined it themselves (and indeed, I believe this would error unless they explicitly checked for a previous definition).
> I'm not sure how they did that (#define?) but stay far, far away
...NO and YES in Objective-C are themselves #defines. As others have pointed out, TRUE/FALSE are also already defined in the language, although using them in Objective-C is not good style.
From all the app code generators I've seen and used, the experience is absolutely horrendous. Memory leaks, does not five you full access into the API etc... It's a lot easier to suck it up and learn Objective-C than having to deal with these tools.
Part of me wants to and most of me doesn't haha. The problem is that design patterns change pretty frequently. I mean I cringed when I saw action sheets and their table views in the video. I'm working on a "Bootstrap for iOS" right now but the project is pretty much on the back burner due to some other iOS stuff I'm working on. I've released the colors part of what I was going to include (shameless plug: https://github.com/bennyguitar/Colours-for-iOS) and I'm going to release another couple classes soon that make some UI stuff a lot easier and streamlined.
Out of curiosity have you used or seen Xamarin? I've heard a lot of hype and talked to fairly experienced people who say it doesn't add too much in size or performance cost.
I like Xamarin's products. I am currently involved in a Xamarin.Mac project and I definitely prefer coding with C# over Obj-C. It's a very nice combo of having things like LINQ, nullables, properties, etc and yet you're still truly coding against/with Cocoa. You can't use Xamarin's products without first having at least a working knowledge of Apple's tech.
My reservation is the cost. I bought MonoTouch when it was first released and wrote a game for the iPad with it[1]. If I wanted to release that game now though, I'd have to re-buy MonoTouch, which doesn't sit well with me. But if you're not a hobbyest then the cost is pretty irrelevant IMO.
The thing I find funny about their example is that alot of it is easily achived by storyboards anyway. I find that people choose these solutions thinking it will help them with complex requierments or ideas they have where in fact the application should or can only be used for applications for simple ideas and requierments.
If it does what it promises, then $299 per app is a trivial amount. If it doesn't, then it's not really worth any money at all. Either way, the $299 figure isn't very important.
It looks like from the video it just writes it all and you drop an info.plist file and a build folder (probably with classes and all images) into your project. It doesn't show it, but my guess is that you then change the initial VC in the AppDelegate file and you're on your way.
I think this is a cool idea, but I think it might make sense to aim it at the Titanium platform. As a Titanium developer myself, I think this would go over extremely well in our community. I would assume that anyone who is comfortable enough in Obj-C wouldn't really want to use an app builder like this, but titanium devs are already using a "builder" of sorts since they are using the framework. Just a thought!
26 comments
[ 16.5 ms ] story [ 243 ms ] threadI'm not sure how they did that (#define?) but stay far, far away. Imagine if you opened up a Ruby codebase and found out I had aliased NO to be the same as the language builtin false... yeesh.
Also, setting boolean instance variables to NO in init is silly since Obj-C objects are calloc'd, so all ivars are guaranteed to start with default values (nil/0/NO).
...NO and YES in Objective-C are themselves #defines. As others have pointed out, TRUE/FALSE are also already defined in the language, although using them in Objective-C is not good style.
http://www.opensource.apple.com/source/objc4/objc4-371.1/run...
My reservation is the cost. I bought MonoTouch when it was first released and wrote a game for the iPad with it[1]. If I wanted to release that game now though, I'd have to re-buy MonoTouch, which doesn't sit well with me. But if you're not a hobbyest then the cost is pretty irrelevant IMO.
[1]https://github.com/city41/optix
Well done that they have been able to build it though. How do you think they are porting the html/css code to Obj-C?
Except the product will also looks like it's designed by a caveman.. :D But pretty cool for the everyday idea man out there
If your app does anything more than just displaying content, it still seems like you'll have to jump into the code.