By "screen activation" I mean a concept from Caliburn Micro, when you want either display something in the region that was not occupied or switch one view with another. In Caliburn Micro, all this is done from ViewModel's method by instantiating and activating another ViewModel. It seems to me that in MVVM Light, considering its "View First" approach, to achieve the same you need to use a code behind and just switch the content of a view host with some other view.
I was wondering if this can be done without code-behind and if there is a dominating pattern for this task.
In this post I outline the approaches usually taken to display dialogs from a MVVM Light view model.
MVVM Light does not have the concept of regions, neither does it force you to use one specific paradigm to solve a problem. This leaves you a lot of freedom, however, on the opposite this also means that you have to do more yourself.
If you need regions and plug-ins maybe using a larger framwork - like Prism, Caliburn, or Ocean (partially) - may be a better choice. If you are bound to MVVM Light and need this functionality you will have to create it yourself - hence the "light" part in the Name :-)
Edit
Your (Sergey's) comment got me thinking, so I went out and looked around and found something that migt fit your need.
Mike Hamilton implemented a conductor/screen logic based on MVVM Light. The samples do not use a ViewModelLocator but I can see no reason why this couldn't changed (haven't tried it though - time permitting). However, the approach looks promising. Note: It may be applicable to WPF only - samples are WPF only and there is no navigation in it.
Bedides in source code the package is also available as a NuGet package.
Even if you want to roll your own implementation, the samples, source code and blog post give you a good starting point.
If you are targeting WP7 both Laurent Buginion and Jesse Liberty showed how to implement a NavigationService - which also fits into this category.
As Silverlight and WP7 share quite a lot of commonality the NavigationService approach can be transformed to work with Silverlight as well - actually I done this in a SL application I wrote.
Jay Kimble provides a template that implements yet another approach for Silverlight.
As to what is the "dominating" pattern I'd say for Siverlight/WP 7 it is the NavigationService pattern, for WPF - ther really is no "dominating" pattern, however, some contenders (one shown).
Related
I was asked by a client to make a "skinnable" app and I don't really know what that means.
I googled like crazy and I didn't found a clear answer or an example.
If anyone has a clue about this, any tip would be appreciated.
Thanks.
Generally this means the app will allow the user to choose different looks for the UI, each of which will have a different color scheme, feel, etc.
What I actually did with my project. I decided to use multiple storyboards to give me greater control over the entire UI and UX of each theme. I programmatically link them all together via a master storyboard that links them all together. That's what I did, and it works very very well. Performance is great, while still maintaining high level of fine grain control over each theme. You can even keep your Header and Implementation files the same for individual view controllers, just so as you keep the names the same on the storyboard.
So for instance, one of my apps that I'm working on called Jam-mout (A music player) has multiple high quality themes. (Image attached). Each theme has it's own storyboard.
For iPhone apps, where the majority of the GUI design is provided by the operating system, you could do it by setting custom Navigation bar background images, custom button graphics, and different fonts/sizes/weights and whitespace. Make sure you're working with a designer who's familiar with the iPhone GUI (if you're not working closely with a designer this is going to be a nightmare).
I recently put together an app for a client who wanted a heavily customised GUI: http://itunes.apple.com/us/app/gogoparis/id428497937?mt=8. A 'skinnable' app would have several sets like this, so the user could choose between several different overall styles. (I hope your client has an enormous design budget!)
my post here should help you get started:
What is the recommended method of styling an iOS app?
if you need live theme changes, each theme in this example could post notifications when the user selects another theme (or skin) - then you can update either the theme instance itself.
alternatively, you can create identifiers for themes which are mapped (NSCFDictionary) to a central theme factory. an example identifier for a specific view for use with the theme factory could be a string MONImageSelectorTableCellThemeIdentifier.
an example manager/factory which handles all theme loading and vends references to themes:
#interface MONThemeManager : NSObject
//...
- (MONTheme *)themeForCurrentlySelectedSkinForViewWithIdentifier:(NSString *)identifier;
//...
#end
beyond that, it's hard to answer your question in more detail without knowing your requirements. the implementation of skinning an app can range from very simple to very very complex. good luck.
Already some good answer here, but I'd add that if you use a ui toolkit such as Three20
you can skin everything using CSS as you might for web pages.
I do realise this is an old post, but I thought I'd share my penny on the matter:)
To make any Cocoa app skinnable you need you think of 3 aspects of the app:
1) Uniformity: By this I mean that on all windows, views (including buttons, text inputs etc...) you want to have a 'standard' that will apply throughout the app. This is the first thing you need to look at. Although iOS and OS X alike already have 'themes' as to put it i.e. Apples default way of shading and laying things out, you can override these (refer to the individual view / window etc... documentation.
2) Performance: With skinning etc... performance is always an issue when it comes to writing your own drawRect etc... methods. The code apple have in place for the 'default' is already optimised, so you need to keep a close eye on the performance of the app whilst you are doing this. Good examples are: Do I use an image with a gradient, or do I use NSGradient? Both of which have performance issues when it comes to rendering them, but it's a question of which is the better of the two
3) userDefaults: This is generally the area where you'd be getting your 'skin settings' pulled from. userDefaults is basically where you store all of the information which you generally set in a preference pane.
If I were you I'd look into the class reference of it:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/
Furthermore, here's a nifty example of using userDefaults:
http://mobile.tutsplus.com/tutorials/iphone/nsuserdefaults_iphone-sdk/
Hope this helps!
When I started with IPhone development I preferred using Interface builder for creating views in my application. With time I considered the option of creating the application via code which I really feel comfortable working with.
Now, when I know both ways to create my user interface, I have doubts which way to follow. I keep thinking where to use IB and where to use code. How can I figure out before starting with my application, which way should I create my UI?
There are a number of factors that can influence your choice. It can come down to personal taste, but there are some advantages to using Interface Builder.
The first thing to recognize is that UI design is inherently a visual task. Interface Builder can allow you to create and modify a UI much faster than you can in code. Rather than endlessly tweaking CGRect values in code, then recompiling, testing, and repeating this process, you can instead get direct visual feedback about your changes. This means you can refine and polish the UI much more efficiently, and even test out radically different layouts without too much time or effort.
Another important point is that if you can create and layout a control in Interface Builder, that means there is less code in your view controller. Less code is always a good thing (less bugs, easier to maintain, ...).
So I believe you should try to define as much of the layout and properties in Interface Builder as you can. This can be hard for people who prefer "full control" over things. Many years ago, visual GUI editors were renowned for doing the wrong thing, and developers often shunned their use over doing everything by hand. But Interface Builder is pretty good at what it does, and you can easily dive into code when you need to.
The situations where you would create controls purely in code are when you need to dynamically create a number of objects, for example thumbnail buttons for a photo gallery, or if you have custom layout requirements.
For example, if you have a label whose height is dynamic at runtime, and you want to layout a bunch of controls underneath it (taking its height into consideration), that can only be done in code (UPDATE: iOS 6's Auto-layout can do this now). You can either create and layout everything in code, or you can still create the controls using Interface Builder and just give them arbitrary positions in the XIB which are modified when you lay them out in code. It's not uncommon to see this in some of my XIBs:
The buttons along the top can be created and layed out fully in IB, but the image views below need their images and positions to be calculated at runtime. So we just give them arbitrary positions in the XIB. Some might find this ugly, but it saves time and effort on writing code to create the image views and set up their properties. Again, less code is a good thing.
Other times you may want to use code is setting certain explicit properties. Let's say you have an image view which needs to receive touch events because it has some gesture recognizers added to it. You need to set the "User Interaction Enabled" property to TRUE. It can be better to do this in code because the requirement is more visible and you can leave appropriate comments as to why you are setting the property. It's also harder to 'lose' the setting like you can in interface builder if you need to delete and recreate a bunch of views.
I think for many applications that use the stock UI, Interface Builder is a great tool to rapidly get things up and linked with the underlying code. Also, it really stresses the paradigm of the View being separated from the Controller as you really can't push code into places where it shouldn't be.
That being said, I use it less and less the more I learn about how to rapidly code interfaces due to the fact that they may need to be more flexible or need a variable number of UI elements based on the Model behind it.
Use interface builder as per your requirement. It's depend on you that how you manage things. See creating a custom cell using interface builder is much easier to update at a later stage while using code you have to do a lot of changes if layout changes. Also you can visualize the view before running the actual app but in code you cannot you just have to assume.There are both prons and cons of both things.
Recently I've been reading up on the MVC pattern and wish to apply it to my iPhone development. However, there seem to be so many variations of the pattern that I'm not sure exactly how it should be applied.
As far as I gather, the view will notify the controller of any actions which have been performed and the controller will in turn update the data model (if required). The data model will notify the view whenever a change to the data occurs and the view then updates it's display of the data appropriately.
In this basic model, the controller only has knowledge of the data model. However, I can't seem to figure out how to employ this design within my iPhone app.
The following page suggests an alternative version of the pattern where the controller has an awareness of both the data model and the view and all communication between the model and view is performed via the controller. It also seems to suggest that the model and view have access to the controller. Would I be right in suggesting that the data model interacts with the controller via some form of notification (notifications or KVO) and that the view interacts with the controller via actions?
Is this second model correct?
http://www.bogotobogo.com/DesignPatterns/mvc_model_view_controller_pattern.html
Many thanks,
Danny
I found Paul Hegartys explanation on MVC in iOS very helpful. see his Stanford iTunes U video. MVC starts at minute 22.
edit
The link of the video doesn't bring you there as expected. it is 1. Introduction to Cocoa Touch, Objective-C, Tools, and MVC (September 21, 2010)
MVC has been around for a long time so there are many variations (or misquotes) to the pattern. Although, the concepts are much the same for most MVC implementations I have seen.
I would focus on how Apple defines MVC. Which can be found in the Cocoa Design Patterns guide and from sample code downloaded from the SDK site (MVCNetworking example).
With iOS you will often will have Models and ViewControllers(which are a merged role of both the controller and the view).
Also, Martin Fowler has some great MVC stuff in his GUI Architectures.
iOS development is very much orientated towards the MVC pattern.
It is usually done with viewControllers and a model. The view is build in Interface Builder, assigned to the controller and the model part is retrieved from elsewhere.
I would say that for Cocoa-Touch the second "version" of the pattern is the one that best describes what usually goes on.
The idea behind MVC is that the model and the view is reusable, but the controller is often fitted to the problem at hand.
This is also true for iOS development, especially if you use interface builder.
The view is hooked up to the viewController via actions/delegates and the model either broadcast its changes through KVO notification or by the controller pulling new data.
There is tons of code available from Apples developer portal and you should start out by looking at some of that code. Having your eyes and mind tuned to looking for the MVC pattern you will see they use it constantly, with the delegate pattern on top to provide event better abstraction
In my opinion, second one is better. Model and view should be separated completely. If view receives notification from model, the view will depends on design of model. By placing controller here, tightly coupled circular-dependency created.
Finally, each part cannot be developed independently, divide-and-conquer strategy is just impossible to use.
My advise for general cases:
Make view and model passive and independent as much as possible. Major mutation must be done with only external manipulation. It should not be changed actively.
Make controller actively controls both of them and other controllers.
In iOS, a UIView is a view which is fully passive. In most cases, all major mutation always done externally by UViewController. And model part should be implemented yourself completely as you want. (Or you can integrate models into controller if it's small enough, however, I don't recommend it)
In some big featured UIView, a sub-scale MVC patterns are used. Fractal!
Does a library exist to work with trees for iPhone ?
Or if you don't want to deal with CoreFoundation objects, SO user Quinn Taylor puts a ton of time into the CHDataStructures framework, which has trees, queues, stacks, etc and that works on Mac and iPhone: http://cocoaheads.byu.edu/code/CHDataStructures
It's a really solid framework and I highly recommend it.
The default way to simulate tree browsing would be with a UINavigationView where the views contain UITableViews containing all the leaf elements of that branch. You may want to look there first in the Apple Documentation. It is quite simple to implement.
If you are intending for something like a Windows Tree View control then I am not aware of any. General concensus suggests that a TV control does not really fit with the iPhone UI paradigm. If you find yourself needing this then maybe you need to rethink your UI design.
I did half an attempt at a tree view, implementing a tableview and using the rowHeightForCellAtIndexPath to return a very small number (0 or 1) for collapsed rows. I had to maintain the tree state in an offline structure (NSDictionary) and render from that. Each cell had to be custom rendered completely. In the end, it was much better to implement it as a Navigation View as this fitted with the iPhone UI and the way you expect iPhone applications to behave much better.
If you are talking about a tree data structure, as opposed to a user interface control, you can use CFTree. A quick summary of how CFTree works is on CocoaDev.com.
I'm brand new to iphone dev, but am familiar with the MVC pattern. Can anyone please explain why the GLPaint sample class PaintingView.m (the View) actually gets the data required from disk to write the "Shake Me!" text? The Data is the Model and should be read from the disk by the controller and passed to the View to render IMO. Correct?
Also, the Controller is adding UI controls to the view (color palette segmented control) - shouldn't the view be drawing this stuff?
Is this a bad example Apple have provided?
Thanks.
It's a good example of how to use OpenGL, but it's a poor example of MVC. I imagine that since MVC wasn't the focus of this example, it wasn't really written with it in mind.
At the end of the day, if the example works and shows you how to use the thing it's being an example of, then it's done its job.
I'm sure there are other examples of MVC out there from Apple that are done properly.
Thanks, I think it's a bit of a hack, but:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW8
Combining Roles
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.