I just noticed that a port of the (originally) AS3 PureMVC fraemwork has been done for Objective-C:
http://puremvc.org/content/view/121/1/
Now, I’m not trying to knock PureMVC. I’ve never used it. I’ve heard good things and bad things about it. But I really don’t get the point of an Objective-C port. Objective-C with UIKit/AppKit is built from the ground up with MVC in mind. In fact, UIKit/AppKit essesntially IS an MVC framework. Objective-C itself is an extension of C created with the express goal of bringing C closer to SmallTalk, the language where MVC was born. Adding another MVC framework on top of this just doesn’t make sense to me. UIKit has views and view controllers. IBOutlets give your controller access to UI elements and IBActions translate user gestures on the view to actions in the controller. You just need to set up a model and give your view controllers access to it. This document lays it out quite clearly:
You might need to log in to see that.
The one use case I could see for a port of PureMVC is if you have an existing PureMVC app that you wnat to quickly port over to the iPhone. I can see that having the framework there would make it easier to do that than re-thinking the whole architecture. And even going forward maintaining two versions of the same app, I can see it would be easier to have them based on the same framework.
But if you are thinking, “Hey, I know PureMVC, this will help me learn Objective-C!” I think I have to warn against that. Yes, I imagine if you were really well versed in PureMVC, it would make the transition easier. But you really won’t be learning it “right”. Now, I usually stay away from concepts of “right” and “wrong” when it comes to software development. People get way to religious about it, and I like to think more pragmatically. But I think if you are learning a language, you should learn that language first, and know the ways that everyone does things. Then, they’ll be able to read your code, you’ll be able to read theirs. Once you know the “right” way, feel free to branch off and create your own way if you think it’s better. Then again, who knows? Maybe PureMVC will catch on in the Cocoa world and become a new alternate standard. But I still recommend learning the current standard along with the new kid on the block if you are serious about doing anything.
Well you know how programmers are… So it only make sense that some one would make yet another MVC framework, for a language that probably doesn’t need it. The whole idea I suppose around all these frameworks popping up like every other day is that they try and do whats already been done, but better! Either way give it time and I am sure you will see like 30 or so more MVC frameworks for Objective-C… Personally I find it a bit annoying and overwhelming when all these frameworks pop up. Having two or three frameworks is fine, but really… It just gets out of hand sometimes, especially when the language you are using was already built to do what you need o.o, funky.
Hi Keith,
As someone who’s been using PureMVC and has also use the iPhone/Mac SDK’s there’s a couple of points I could hopefully add to mix. First of all, Apple’s guidelines on both UI design, and the article you link to on MVC architecture in your applications is *top quality*. It’s well worth getting a log in to read those.
I was also very glad when I first tried out the Apple SDKs to find these documents saying it was OK to mix views and controllers, indeed a very popular class in the iPhone SDK is the UIViewController. Until that point I had always beat myself up about tending to opt for mixing view and controller in favour of producing easier to follow code and struggled to see why these were so extremely separated in most of the classic books and articles on the subject of MVC until I realised it was because of the platforms these had been written for where the view really is a mile away from the controller code (unlike desktop/mobile apps).
Anyway to the point… with regards to PureMVC for Objective-C apps, the way I see it is that PureMVC is a higher level MVC architecture that can be built on top of/use the underlying Core Data (model), Cocoa (view/controller) and other layers provided by the SDK.
It’s more a case that the PureMVC classes/docs provide the high-level conventions for organising a simple or modular/scalable MVC structure with a set of predefined and named roles that neatly form the various “containers” (for want of a better term) your code goes in to, rarely needing to go beyond these standard containers even in the largest of applications (presuming an iPhone application is unlikely to get that large, say 250K lines+).
I wouldn’t call myself an advocate however because I honestly do think that a good MVC architecture in an application is something that doesn’t require prescribing to a particular “framework”, and you could just as easily use the standard Flash/Flex classes to produce the same well designed product given the underlying constructs are there to support it, but without experience someone is more likely to fall into a sphaghetti untestable mess, in particular with Flex the sheer number of places you can misuse code (inline functions inside MXML event attributes etc) which can quickly lead to this.
In the case of the iPhone SDK it’s a relatively simple and therefore harder to misuse the code to this extent. The SDK is pleasantly strict, occasionally confused (due to legacy reasons), but overall well put together piece of kit that promotes good MVC architecture right from the off with an OO language in ObjC, through the various tiers of application construction, data, control, UI. However, the procedural grandfather (in C) is still there ready to overflow your buffers and achieve even more catastrophic code than you might do with statics and singletons in ActionScript.
I must admit I haven’t tried PureMVC with Objective-C, and I can understand the relatively strict nature of the iPhone SDK could leave little space or requirement for a higher level MVC construct on top, so I hope someone comments on here that has indeed used it and can provide a real-world example of how it fits.
I don’t think the intent of PureMVC is to help you learn Objective-C. In fact, using PureMVC for the iPhone before learning the UIKit would be a huge mistake. I think it’s important to learn a new API as close to the floor as possible.
Using the same thinking, I like Zdiarski’s new iPhone book more than the sliced grapefruit book because he basically skips Interface Builder, which is a step removed from the API. That’s not to say IB is bad. I think IB is great. But when learning, I need to focus on the core.
Likewise, PureMVC is probably a worth looking into after UIKit is second nature. I haven’t used it yet, but I saw Cliff’s talk at the conference and I know where he’s coming from. If you’re writing complex applications that are cross-platform, PureMVC should help abstract away the platform differences. It might help you share a mental uml diagram between the different versions of your app. It might help you share a mental uml diagram between all your apps.
It still might not be worth using, but it’s worth serious consideration.
About the pureMVC framework itself i really don’t get why the view is a singleton while the goal of a real MVC is to have many views for one controller and 1 model…
imho although puremvc provides a very portable abstract acrchitecture it limits itself in doing so… as puremvc gets ported to more and more languages it should surely become more of an issue if you ever wanted to update the framework across the board which could in fact cause more headache in the long term.
i’m not very happy with a framework thats designed with so much portability in mind, would it not be better to take advantage of core features of each platform.
as an example i think the mate framework demonstrates this well with its event model (not to make this thread about which framework blah blah blah…). I would definately use puremvc but i’d think twice about using it for other languages….
actually i have been reading and noticed that there is a sub project on puremvc.org named the ‘Manifold Project’ (http://trac.puremvc.org/PureMVC).
from the horses mouth:
“The Manifold Project is about integration of the community contributions into the codebase with a focus on creating reusable, ‘off-the-rack’ utilities that extend the framework’s capabilities.”
so is it the Manifold Project that could make use of platform specific features? I hope thats the direction it takes…
“The one use case I could see for a port of PureMVC is if you have an existing PureMVC app that you wnat to quickly port over to the iPhone. I can see that having the framework there would make it easier to do that than re-thinking the whole architecture. And even going forward maintaining two versions of the same app, I can see it would be easier to have them based on the same framework.”
It sounds like you DO get it.
ryan, you said:
imho although puremvc provides a very portable abstract acrchitecture it limits itself in doing so… as puremvc gets ported to more and more languages it should surely become more of an issue if you ever wanted to update the framework across the board which could in fact cause more headache in the long term.
Cliff Hall, PureMVC’s creator has promised that the features of PureMVC have been locked down. This is a pretty big deal and should answer your concern about future headaches.
Ryan, that’s a double edged sword though. More portability means that you often lose the ability to take advantage of certain features that would otherwise be available in a given language. Taking advantage of all features in all languages means loss of portability. Anyway, best of luck to those of you who do use it. I’d like to hear how it goes.
It’s really quite simple. If I know PureMVC in one language, I can get going on another language far quicker by seeing a demo done with the same methodology.
Porting PureMVC to Objective-C isn’t like planting a flag on the moon and declaring it owned. It’s more like building a nice bridge to the moon so people can easily go there.
Jens Krause, a PureMVC contributor from way back recently hopped into the iPhone development world by doing a PureMVC-based RSS Reader.
http://www.websector.de/blog/2009/02/08/simple-rss-reader-for-iphone-using-puremvc-standard-for-objective-c/#more-210
His conclusion was:
“Do I need a MVC framework such as PureMVC for developing an iPhone app? You don’t! Because Objective-C based already on a MVC paradigma.
However, if you are new to Objective-C and you may have a strong ActionScript background using PureMVC, it might be a good choice to dive into iPhone development. And you will see, that the code architecture is like your home :)”
When I went to Germany I was very glad they also spoke English, even though they have a language that seems to work perfectly well for them.
-=Cliff>
Yeah, I understand the reasoning, and if that works for some people, I guess that’s cool. To follow the paradigm though, having German people who speak English is good if you are going over for vacation, but if you are going to live there, I’d recommend learning German. 🙂
And of course, your response will be something along the lines of having a translator available for the first few months so you can get along while you are studying the language. 🙂
Hi all,
Just wanted to give everybody a little background on why I decided to create a port of PureMVC for the iphone. I started doing iphone development for my company about 9 months ago and went through all the typical learning curves. At one point I realized that iphone sdk/UIKit really doesn’t provide the kind of MVC framework we were looking for. In fact UIKit reminds me of Java Swing more than anything else, where the View and the Controller are coupled into one component. And UIKit does nothing for you with regards to the Model side of MVC.
Having worked a lot with Flex in the past I immediately thought of PureMVC and after seeing all the ports being done I thought why not for the iphone. After refactoring our iphone app to use PureMVC a lot of benefits emerged. Our code is better structured and easier to navigate, making new features quicker to add and less buggy. Basically all the benefits you expect to find when using a solid MVC framework like PureMVC. Also we have created a bunch of PureMVC extensions that are specific to ObjectiveC that we hope to release very soon.
In general though I agree completely with the advice of the above posts, learn as much about UIKit at it’s core, staying away from Interface Builder (our team still doesn’t use it), and then think about how you want architect your app. For our app UIKit was not enough, and PureMVC gave us what we needed and more.
Best,
Brian
All I can say about PureMVC is, don’t knock it until you’ve tried it. We’re using it for the cross-platform compatibility between flash and flex right now, but beginning to delve into IPhone Development as well. We shuffle our developers across projects quite a bit, and using one methodology/framework across both flash and flex makes development and maintenance much quicker. And for the most part, using many of the features in each language is still very possible. I’m hoping that our IPhone devs will be able to make use of PureMVC as well. That way, any of our developers have a good shot of at least debugging something in a pinch.
I’ve written a number of PureMVC applications. I’ve found it to be particularly useful for wiring up large applications with large numbers of views and controllers. It lets the native MVC do what it does best — handle small, localized interactions — and allows you to wire up those small native MVC bundles into big, complex applications.
Flash is a very simple technology which we, flash devs, often complicate and over-glorify to
so we can feel as important as people who write REAL code 😉 The one that operates medical equipement, secures monetary transactions and steers fighter jets… rather than bouncing balls of an angle that is. PureMVC is (in my view) the above statement into code. I think it should be banned from a slightly more interesting platform which is the iOS. The fact that some people are used to the former does not mean that the Cocoa-Touch runtime should start with a frame event counter for gods sakes!