I just started building a windows phone application and i am very much conscious about the application's memory constraints. So my doubt is, is there any advantage for dynamic view models over static view models. I think if i create static view models, while the time of application launching the memory will be allocated for all my view models and it may eventually increase my application's memory usage. How i can tackle this situation. I found in V 4.0. A SimpleIOC container is added along with the libraries, how i can make use of that. provide some samples or documentations that make me learn the technology easier.
Unless you have a highly complex model, the memory consumed by your view models will be trivial compared to the memory required to store your UI assets such as images, UI controls, views etc ...
Just create the view models in the most natural way. People do not use MVVMLight or IoC containers in order to reduce memory usage, they use them to help structure their code.
I would advise you to start simple, without any frameworks, and structure your code sensibly. I wrote a blog post a while back that shows how to use MVVM for WP7.
Related
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.
I am about to start building an app that will be used across all platforms. I will using monotouch and monodriod so I can keep things in .net
I'm a little lazy so I want to be able to reuse as much code as possible.
Lets say I want to create an application that stores contact information. e.g. Name & Phone number
My application needs to be able to retrieve data from a web service and also store data locally.
The MVVM pattern looks like the way to go but im not sure my approach below is 100% correct
Is this correct?
A project that contains my models
A project that contains my views,local storage methods and also view models which I bind my views to. In this case there would be 3 different projects based on the 3 os's
A data access layer project that is used for binding to services and local data storage
Any suggestions would be great.
Thanks for your time
Not specifically answering your question, but here are some lazy pointers...
you can definitely reuse a lot of code across all 3 platforms (plus MonoWebOS?!)
reusing the code is pretty easy, but you'll need to maintain separate project files for every library on each platform (this can be a chore)
MVVM certainly works for WP7. It's not quite as well catered for in MonoTouch and MonoDroid
some of the main areas you'll need to code separately for each device are:
UI abstractions - each platform has their own idea of "tabs", "lists", "toasts", etc
network operations - the System.Net capabilities are slightly different on each
file IO
multitasking capabilities
device interaction (e.g. location, making calls etc)
interface abstraction and IoC (Ninject?) could help with all of these
The same unit tests should be able to run all 3 platforms?
Update - I can't believe I just stumbled across my own answer... :) In addition to this answer, you might want to look at MonoCross and MvvmCross - and no doubt plenty of other hybrid platforms on the way:
https://github.com/slodge/MvvmCross
http://monocross.net (MVC Rather then Mvvm)
Jonas Follesoe's cross platform development talk: Has to be the most comprehensive resource out there at the moment. He talks about how best to share code and resources, abstract out much of the UI and UX differences, shows viable reusable usage of MVVM across platforms and nice techniques for putting together an almost automated build. (yes, that includes a way for you to compile you monotouch stuff on Visual Studio)
Best of all he has a available source code for the finished product and for a number of the major component individually placed in its own workshop project and a 50 + page pdf detailing the steps to do so.FlightsNorway on github
IMO the only thing missing is how best to handle local data storage across all platforms. In which case I would direct you to Vici Cool Storage an ORM that can work with WP7, MonoTouch and (while not officially supported) MonoDroid.
*Disclaimer* The site documentation isn't the most updated but the source code is available. (Because documentation is Kriptonite to many a programmer)
I think the easiest way to write the code once and have it work on all three platforms will probably be a web-based application. Check out Untappd for example.
You can start by looking at Robert Kozak's MonoTouch MVVM framework. It's just a start though.
MonoTouch MVVM
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.