I still a beginner in iOS Development and while building my first app I had the following doubt:
which is considered a better development criteria, having too many views in the app or having less views with more complicated class codes so that these view can be dynamically used?
I really would love to get your feed back as in my first app i can either use 17 view (simple and strait forward) or reduce them to 6 (complicating the codes and using much less classes eventually).
It depends on the project requirement that how many views will have. It may be a topic of debate. You should have necessary views and classes but not more and unnecessary view is good. Also, to reduces the view you should not complex your classes.
You should follow the OOP (Object oriented Programming). That means,your need to write your methods/classes ,so that it can be reused.
Related
This is a somewhat open ended question about the UIViewController class, and their proper role in an iOS app.
I recently read this article, and I partially agree with the author. It's obviously important that every bit of logic related to your views and models doesn't end up getting dumped into the UIViewController, but it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.
I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)? As the author of the post pointed out, Apple doesn't seem to strongly advocate against putting logic in the UIViewController.
Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?
A view controller is not evil by nature, although it's common for them to grow into monolithic messes because they are so convenient to extend.
…it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.
Think of it as breaking up your program into smaller units, whatever that may be. Subclassing UIViews in every case isn't the best solution (as one example).
Each developer's tolerance is a bit different and it varies by program/case, but it's pretty easy to recognize and eliminate duplicate code, and to break your programs down into smaller units.
I think most classes:
should not exceed a few ivars (e.g. 2)
should not require more than 100 lines
should favor composition over inheritance. in many cases where you think you need inheritance, protocols may be used.
Of course, there will be exceptions.
I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)?
It matters more that you will gain a lot by writing more reusable programs. Invest more time and effort into these reusable designs, reduce duplicate code, and focus on quality. Write performance and memory into your designs where it is a concern. Generally, this will result in a big win when compared to the dreaded freshly written, poorly tested, monolithic VCs.
Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?
Oversimplification: No, you don't have to go that far if you eliminate redundant code, focus on reusability where applicable, and ensure your units/classes maintain low complexity. Absolutely, fix those problems before they grow into monolithic classes, regardless of whether they are VCs or another type.
I've also read this article a year ago, when I was looking for better iOS coding practices than what you see everywhere (dumping all kinds of crap in view controllers...). I agree with its points, although unfortunately it doesn't provide any kind of solution to the problem.
After a year of working on a fairly large iOS application, with complicated data model, remote services and highly nonlinear navigation, my experiences come down to these points:
Use view controllers for a single unit of user interaction, like prompting for login credentials etc. Basic validation (e.g. checking for empty fields, number formats etc.) takes place in the view controller, but if validation is part of your business logic, it should be put in your model.
I usually have a so-called controller object which orchestrates the UI flow, and connects it with the domain model. The controller receives user input from the view controllers via delegate mechanisms, so they're loosely coupled.
A single monolithic controller should be avoided; so I usually try to split my controller functionality between simpler, modular parts. For example, I have a controller which manages a registration process with a mostly linear UI flow, and its embedded in the main controller of the application so its
My colleague told me to separate my controllers in a separate project to make the unit testing as easy as possible, and he also told me to create a solution for the controllers project and test project to avoid loading the whole application when conducting unit testing. Is it a good approach to separate the controllers in a new project?
I am not sure if there is a simple yes or no answer to this question. I would think that your project would have to be very, very large as to have impact on your unit testing. My personal opinion is to leave the controllers in the web project along with the views and view models. However, I am a fan of moving the models to a separate project. My reasons for doing so have less to do with easier unit testing but rather reusing the data access (models) in other applications.
In my opinion you should always at least separate the controllers from your view project (usually a web project for me), because the idea is that the controllers should be able to be used with any view (maybe later you decide to use them for a Windows Forms project, for example). It keeps the namespaces a bit cleaner as well.
From my point of view, making you move out the controllers to a separate project has two things to consider, if you do so, then it enforces you to think how to solve problems with low coupling and precisely low coupled classes can be tested more easily than tight coupled classes.
On the other hand, having the controllers in the same project than the views is kind of logical because the controllers normally know about the views.
If you think of reusability there may be something arguable here because often controllers are "glue" components this means, there is a lot of wiring in them.
This seems like a good idea at first. Creating a prensentation layer in the middle and keeping your MVC project containing only views, making it truly a UI project. On the other hand, you will probably lose the tooling support for the views. Since you have to ignore all the warnings, you have to make sure all views are there, strongly typed to your object.
I don't understand the concern for referencing your MVC project in your test suite since you will probably bring in the MVC namespace anyway.
In learning about Core Data, I've noticed how (in Xcode's templates) Apple directly used the query classes inside the view controller. This seems like it is bad MVC (having database access logic directly inside the view controller). Would it make sense to abstract out these kinds of actions to a separate suite of classes that obtain the data from the database and pass it back to the view controller calling it?
EDIT–
So, just to be clear, when I say "kinds of actions", I specifically mean CRUD Operations. Though if you have ideas about other things that a so-called "Model-Controller" would do, I'd be interested in hearing about them.
It's a matter of opinion, and often yes the templates are the most simple form of working example. It's hard to have a template spin out multiple files, for example.
Yes, personally, I generally spin out a separate NSManagedObject subclass. I like to have a _MySubclass object that has all the auto-generated stuff, then have the model actually reference MySubclass which has model-based business logic (you can use mogenerator or other methods to do this too if so inclined). Perhaps thinking of it as "Model-Controllers" and "View-Controllers" is another way of putting it.
This is a very good question and the answer likely depends on your situation. Perhaps architecture purists would insist on separate Model controllers and there are a lot of benefits to this approach. However, sometimes I find myself using Key Values when I'm doing a simple view. When things are more complex, for example, when coding the same Model for the Mac and iOS, having separate Model Controllers will allow you to reuse a lot of code. When you must diverge, Obj C Categories are a very clean way to extend functionality without adding a lot of overhead. I personally favor categories over extensive subclassing.
Since NSFetchedResultsController was released, my model classes are leaner. There are a lot of nuances to this and experience will help you come up with the best solution for your App. I've also found that writing unit tests up front will help you force through issues and validate your design, or send you back to the drawing board :)
I've been developing iPhone apps for a while now and something that's always peeved me is that I haven't found a comprehensive way to organize my application files.
I know that an iPhone project is technically MVC, but it seems like most everything I do is in a ViewController. I notice that as a project goes on, my ViewControllers continue to get more and more bloated and I can't help but think that there has to be a better way than this. I also do some ruby on rails and I like the fact that on that platform there is such a clear separation of concerns and an established way to organize an application.
Has anyone discovered a way that they especially fond of for organizing the application?
Also how do cut back on the view controller bloat?
I agree, just about everything seems to land in view controller classes, and they get unwieldy in a hurry. There are several things you could try:
Create separate classes for delegates, if they don't actually need to be part of the view controller;
Put delegate method implementations into a category, as described here;
Factor out any methods that don't actually interact with the rest of the view controller, and put them in separate classes
Use blocks for asynchronous callbacks when they make sense, because they are often less verbose than explicit callback methods;
Or even just organize your methods carefully and use #pragma mark so Xcode can help you navigate through the file.
This isn't an exhaustive list, of course, and others may have better suggestions.
I want to support just 2 languages. There will be no requirement for any additional language. What will be the best approach after considering both ease of use and maintenability:
(a) Each view has a separate page for each language and they will share controllers and model dlls
(b) Both languages pump resources into the same view template
Please don't bother about the url structure right now. I will appreciate real experiences over the theoretical discourses of pros and cons. Thanks for your help.
Mutliple views are more flexiable clearly and if you only have 2 then that is a possibility but its still a pain.
However having just 2 instead of N to worry about means you can probably take both into consideration when creating the views in the first place. Hence instead creating multiple views create a single view that uses resources and works in both languages.
Depends on how different you expect the localized versions to get. If you are pretty confident they will always be almost identical, simply different words in each placeholder, then a single view model would probably be the way to go.
However, what I have found to work when there is a blend between the two (i.e. some views are the same, just translated; others end up being somewhat different) is to build a provider model into each view and sub-view, so when the view engine goes to load a view, there is isolated logic in the provider factory to determine, for that particular view, whether to use the same for both languages or switch.