I have three questions related to iPhone and iPad development. I am writing an application for iPhone that should also be available for the iPad in the future. By using the MVC pattern, I know I will keep my models, however it isn't clear for me if I will need to discard the controllers and/or the views. So, my questions are:
1) For those developing the same app for both platforms, what are the best practices? What parts are normally reusable and what parts are normally discarded in order to develop both apps with minimal effort and correct design?
2) Furthermore, I also need to have state/global information in the app. How do you handle (design-wise) "state" information in an iPhone/iPad app? I currently have user information (username and password) that I need to use throughout the application in order to make several server requests (encoded in the http header). In order to achieve that, I have the user model stored in the AppDelegate class. Is this ok in terms of design, or should it be done in a different way?
3) Finally, I have my models separated in abstract classes (or classes handling the generic stuff) and subclasses specializing in different tasks. The idea is writing as less code as possible in order to avoid code repetition (example: sending requests is generic and parsing responses depends on the task at hands). Performance wise, is it a problem to separate the code in several classes and have model inheritance?
Thanks in advance!
1) Well-designed models, views, and controllers should be mostly reusable across iOS devices. The degree of difference in UI design between platforms will largely dictate the reusability of view controllers. For example, when running on iPad, view controllers might be presented in a split view or popover, instead of full-screen, and action sheets presented from bar button items likely won't have cancel buttons.
2) Don't store state in the application delegate. Instead, store it in a model class. Username and passwords in particular should stored in the keychain.
3) Overly-complex class hierarchies can reduce flexibility and make it harder to understand how things work, but don't worry about performance with respect to class hierarchy complexity. Instead, measure performance and spend time optimizing where you'll get the biggest payoff with the least effort. That's unlikely to be superclass method implementation lookup.
Related
I'm having troubles understanding if I'm properly implementing the MVC pattern in an iPhone app. In my app I have views, view controllers and models. The view controllers manage the interfaces, navigate to other view controllers, set variables to other view controllers and models, and communicate with the models. But this way, am I correctly following the MVC pattern? Don't I miss a model controller?
Another question: I have a User Model that I need to have access to in almost every models and some controllers. Would it be correct to define it as a variable in the appDelegate? I'm all the time reading that this is a bad practice, but I don't see why in this case.
Global objects
All non trivial code has bugs, and they are harder to track if you use dumb global objects. By "dumb" I mean generic objects from the API that lack a single point of access in case you need to log, validate, key-value observe, and notify, changes. You can wrap the global object in a class to route everything through your own accessors.
Some say using globals at all gets you into a bad habit. Others say it depends on the size of your code because it is a trade between development speed and complexity.
The appdelegate is a Singleton, so this discussion is related: What is so bad about singletons? and Singletons: good design or a crutch?.
MVC
Apple talks about it in Cocoa Core Competencies and Cocoa Fundamentals Guide.
One can merge the MVC roles played by
an object, making an object, for
example, fulfill both the controller
and view roles—in which case, it would
be called a view controller. In the
same way, you can also have
model-controller objects. For some
applications, combining roles like
this is an acceptable design.
Is your design complex enough to need a model controller? Whatever your decission is, suffering the consequences will teach you a lot. :)
A design pattern in which the model (any data in your program), the view (what the user sees), and the controller (a layer that handles all interaction between the view and model) are separated in such a manner that modifying either the view or model component of your program has no effect on one another.
The purpose:
The purpose is that later on you may need to change your programs view, and by programming things in this matter you will not have to modify your programs model. Say for instance Apple comes out with an iPad for which the view is programmed somewhat differently than on the iPhone, but you would like to
Now I received some messages after making the video above, some thanking me for making the concept of MVC sound so simple, and others telling me that I had confused them, and wondering how I could understand any of this stuff.
Well, don’t fret.. I’ve seen arguments all over the place as to what components should be classified in the model, the view, or the controller, and I’ve even seen accomplished "guru authors" mess things up when explaining what goes where, just keep in mind that the key idea here is that you can modify one of these key areas without completely wrecking another key area of your program, and leave the rants to the wannabe coders who like to argue about what exactly what fits what acronym, and MVC is often their target.
Are there any major advantages/disadvantages I should take into consideration when developing an app which and deciding whether to creates parts (styled menus, pages with content with complex layout etc.) in HTML/UIWebview or doing it all native?
I would like to hear people's experiences with this.
Personally, I find that I tend to dislike web apps that are (usually) disguised as iOS apps. I tend to notice a lot of inconsistencies between the UI of a web app and a 'native' app, and most of the time, it bothers me (my biggest pet peeve is tapping a button and seeing it highlight with a little translucent black box around it like a link). Now, I don't represent the major user demographic, which probably won't care, but that's my personal opinion.
In terms of programming, I've never written a web app before, but I assume that it's going to be slightly less structured than a native app just because writing HTML, Javascript, and CSS doesn't force you to assume a certain project structure, unlike iPhone apps that have distinct views, controllers, and the like. Depending on what you want to write, this might be liberating, but can also get tangled very quickly.
As middaparka said, you can also use a mixture of the two systems if you'd like. I mean, I'm assuming you're just as good a web developer as you are an iOS developer. If you are stronger in one suit than the other, then I say that you should lean towards heading in that direction. I'd much rather see an excellently written web app than a badly written native app, and vice versa.
I suspect the major advantages/disadvantages relate to the user experience - a "native" UIKit based user interface will feel a lot more natural than manipulating items within a web view. (It'll also mean you can use more "standard" components like navigation controllers, tab bars, etc.)
That said, there's no reason not to use a mix of the two, with the main UI being implemented via the various UIKit objects and the content being provided via a web view.
I would also add that the biggest issue I've found with hybrid frameworks is that you add another dependency to your app.
For example, take a big iOS update. If your chosen framework breaks, your app breaks and you won't be able to fix it until the framework is fixed.
Also, right now there are many frameworks and you have to pray that the one you chose isn't flushed down the toilet or drops support for one of your target platforms.
Another issue is that in a web based app/component you are missing out on platform specific technologies and frameworks like core data, GCD (or any other threading model - which in web you might have do with e.g. Ajax),uitableview with caching etc.
Should you hit a wall when it comes to performance or storage,then you have many more options in the native framework.
I've been playing around with iOS development and I'm getting to the stage where I want to create something beyond a simple app. However, I'm not confident that I understand how to partition an application correctly.
For the purposes of simplicity, imagine a (very) simple audio player application. Let's say there are two view controllers, accessible via a UITabBarController which is instantiated the main AppDelegate class.
Each of these view controllers has the following responsibility:
PlayerViewController - A sound player which plays the “current” audio sample when the user presses a button.
SelectorViewController - A sample selector, that uses a UIPickerView to display the available audio samples so that the user can select which sample they want to play.
So far, so good. However, what I don't quite understand is where I should store the data on the available samples, so that both of the views can find out information on the available samples, trigger a sample to play, etc.
As both view controllers need to access this “model level” information, would creating an “audio manager” singleton class be a sensible approach, or is there (much, much more likely I'm guessing) a better means of solving this problem that I'm overlooking.
Any pointers would be much appreciated.
I've used this pattern (Singleton data manager) several times in serious apps. It's quite straightforward, easy to understand, easy to use, although this pattern is despised by OOP purists.
If nobody tells you it's wrong to use a singleton, go ahead, just be sure to check Apple's documentation on the recommended implementation (there is a bunch of methods to overload).
Oh and BTW, Apple uses it a lot in the iOS SDK, so it's a common practice (see class methods beginning with 'shared').
UPDATE:
Another possibility is reusing an already existing singleton, the Application delegate for instance. It might feel cleaner, or not, it's more a matter of taste. It has the advantage of giving a clear "entry point" where you allocate/create/init your data manager.
If the source of your data is in a remote server and it comes to your app as an XML file, you can also get it whenever you want with a kind of source downloader class.
That way you don't have to care about keeping things in memory when they are not necessary. Just get it from the remote source, parse it and then release it.
Another way of achieving this more careful use of memory is to get your data from a sqlite database using Core Data. But some people thinks it is too much complicated for a simple app and prefer running queries by hand.
My question is a design issue and it has been driving crazy over the last couple of days. I am new to cocoa touch development.
I have an application that has a UINavigarion controller and a 3 views. I need to keep communicate with a WCF service and store the data on the app side.
How do I create my Model (MVC) in a way that makes the data available to all controllers?
What I started doing is a singleton that handles all the storage and web calls but I read thru the threads that it is a bad idea. I also considered putting the code in the appDelegate but people say that is a bad idea too.
Conceptually how would u design your model and communicate with the controllers?
Any help is much appreciated.
You will get different advice because opinions differ on the best method to use. As you noted, for handling a data model, there are two major design patterns: Dependency Injection and Singleton.
Dependency Injection relies on passing the data model object from view controller to view controller as needed. Marcus Zarra (author of Core Data: Apple's API for Persisting Data on Mac OS X which I recommend) wrote a good article explaining Dependency Injection. Most of the Apple documentation recommends that you use the Dependency Injection design.
I like the Singleton pattern but it is very, very, very dangerous for a novice to use. The Singleton pattern is so easy to do wrong that most graybeards have given up on it and simply advise novices to never use it.
The Singleton pattern has the advantage of increasing modularity and flexibility of the app. However, it requires that you have a firm idea of what the data model will do before you start coding both the Data Model and the UI. It requires more work up front to get correct and it is not as forgiving as Dependency Injection. You have to use singletons with greater discipline.
For a simple app with three hierarchal views, Dependency Injection is the simplest and cleanest design to implement. You won't need the flexibility of a singleton and a singleton will just add unneeded complexity. The Navigation-based template with Core Data provided by Xcode will give you 50% of the app to start. Just add the second and third tier views and you're done.
I am developing an app, which is a huge project. I need to create an architecture for the app, so that I can reuse the code for another client (app will be template I will change UI only).
Thinking to apply singleton pattern, but there are some very good design pattern available like MVC, Factory, etc. How can I find out which is the best design patten I should implement in iPhone app? Or is there any code/tutorial available which explain with examples.
The iPhone is completely geared toward MVC, so that one's a no-brainer. Don't try to use another pattern to organize your app - it'll just become a hacked up mess. As far as other patterns go, Singleton is always a good one. If you make singleton objects that manage common behaviors (networking, for example), you can reuse them in other projects pretty easily.
Custom views are also easy to re-use. If you create a custom UIView subclass for part of your UI and define Objective-C protocols for it's data source and delegate interactions (the points where it is tied into your controller and model), you should be able to take them with you to future projects.
Also consider using Core Data to store the "Model" part of your MVC app. Core Data is an ORM that is built into the iPhone platform. It allows you to store everything in an SQLLite database while working with Objective-C objects in your code. It's really handy if you're creating lots of apps with the same data or with the same UI but different data. (aka all those "fans of XYZ" apps!)
That's such a vague question that the only possible answer is "a good one."
You already have a choice of templates when you start a new iPhone app in Xcode. Those suggest architectures...
Also, if you want a good overview of the design patterns underlying Cocoa, I would suggest picking up the book Cocoa Design Patterns by Erik Buck and Donald Yacktman.