CODEWITHSUNDEEP
iphoneobjective-cipadmodel-view-controllerdesign-patterns
carvil
carvil

Reputation: 199

iPhone and iPad Development - Good design architecture for maximum reusability

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!

Upvotes: 4

Views: 587

Answers (1)

lemnar
lemnar

Reputation: 4053

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.

Upvotes: 1

Related Questions