I'm developing an app in Visual studio using Xamarin and MVVM light. My app will have a settings page (view) with several main categories and when the user clicks one of them I want a new view to appear with detailed settings for that specific category.
My question is rather simple, but after spending 2 hours on google I've finally given up. Is it possible to combine these detailed settings in one file/view, instead of having one view for each and everyone, since this will give 6+ views just for settings.
I've read something about using listboxes, contentviews and observablecollection but I haven't really understood how everything works.
For example:
The settings screen will show a list of categories such as: Alert options, device options, configure status etc... Each of these categories have their own options such as: turn on/off sound, vibration, screen dimming. Different kinds of alerts and so on.. I'm wondering if I can achieve this without a view for each category.
Of course you can achieve it all in one view, it's all about how you want to design the user interface of your application.
It's all up for you to decide. Do you want to show all the detailed options at once, or have them show up once a category is clicked. Do you want it to work like an "accordion" type group where once you click one group, the others collapse, etc.
On mobile phones often the best practice is exactly what you described, clicking on a group of options loads a new screen with just those options. Users can use the back button to go back to the previous screen, they can see the detailed options without additional clutter, it's pretty common and nice and clean.
I am not sure why you think having 6+ views just for settings is somehow bad. You should structure your project into appropriate folders for easier organization.
Even if you wanted all the options to be on a single screen, I would still advise that you split them up into different files for easier maintenance and readability, then put them together inside one parent view as layout components of some type.
More files is usually a lot cleaner, better and more maintainable than one giant file with everything in it.
Of course, there is such a thing as too many files, so just use some common sense.
In your example, I see nothing wrong with having a folder inside your Views folder titled "Settings" then having separate appropriately named files for each of the sections.
If you have an idea of how else you would like to present this information, please elaborate on it so we can offer suggestions.
Related
I want to create a kiosk mode application using WPF. I want to use a single window because the user should not be able to exit this fullscreen application.
The application should guide the user trough a process. When the user proceeds trough the process, the screen should constantly change and show him the next step.
Usually I just create a single window and use a "state machine" to switch UserControls containing the information for the current step. Is there a better way to achieve this functionality? Maybe I would get a better result using multiple windows or Pages (never used them).
The reason why I am asking is that in future I want to have a simple, clean way of switching the content inside a single window. i.e. I am planning to implement some sort of animation when switching content (like sliding to the next / previous step). I don't want to put more effort into my current approach if it isn't the most flexible and clean one.
Any ideas?
PS: This is about desktop applications. Today I come from the Winforms environment and am experimenting with WPF.
There's a few ways you can achieve this.
First would be to use a Page based application, this will allow you to use a single window. Here is a pretty interesting tutorial
A bonus of using this approach is that navigation between pages is built in.
Your requirements are that you need to use animation for transitioning between pages, as far as I'm aware, using a Page based application cannot achieve this (I may be wrong). So your other option would be to use a UserControl MVVM approach.
This probably won't make a lot of sense now, but here goes:
You can use a single master view model which will hold multiple child view models, each of these could have a visibility property which dictates the visibility of the associated view. The master view model would simply be responsible for displaying the appropriate view model depending on where the user currently is in the application.
Using some clever XAML, you can create storyboards (animations) when the view becomes visible, which will allow you to achieve the crazy awesome animations that you require.
Anyway, that probably didn't make any sense, so here's a tutorial to get you started with MVVM.
I am putting together a winforms project and I was thinking of using user controls with one form. For example, having a user control for customer lists, customer detail, product list, product detail, etc.
If this is a good idea, if the user is moving from one screen to another do you just make the user control visible = false or do you null it out?
It seems like you are grouping like functionality so I do not think you have to many. Some of the projects that I have done have had pages with a large amount of resources I converted those to usercontrols and I create each time I show them, otherwise if they are relativly lightweight changing their visibility will work fine. It all boils down to what you are trying to accomplish.
Im currently trying to create an application that will require 10+ different "pages" with different content and controls, and i need to switch back and forth between them on particular events.
What ive been doing, is just creating all the different sections in grids, and setting their visibility to collapsed, and then when i need to show them, just switch out the visible grid to the new one.
This has several drawbacks, im assuming its very poor from a coding standpoint, and this pretty much dis-allows me from using the designer at all. (i have no idea what performance implications it has, either)
on top of that, every time i switch to the new page, i need to reset all the components (textbox's etc) to their default states, as they dont get reset by becoming invisible :P
on to my question: i need a way to map out all the different pages, provide visually attractive transitions between them, and be able to use a designer to create them (and i dont mean designing it somewhere and then just copying the xaml)
I had looked around, and ran into SketchFlow and it seemed like the perfect solution, i could fade between pages and map everything on a flow chart easily, and then i realized it was only for app prototypes and i couldnt actually compile it as a normal application... and i needed to inherit from a custom Window class aswell.
is there something out there that allows me to do this? or how can i code this to work properly?
note: this ABSOLUTELY needs to stay within one window. i cant venture out into having 10+ different windows that pop up every time i need to change to something. as this happens very frequently
Split the separate sections in individual user controls. This would allow you to design each of them easily. Then on your form use code to create and load a new instance of particular user control that represents the section you need to show, and when transitioning, load the new section and unload the current. this would allow your form to stay relatively lightweight.
An alternative is to create a navigation application and split your sections into separate XAML view and use the standard navigation service to switch between them.
WPF Navigation Overview
Creating Navigation Applications video tutorial
You might wanna convert your "Pages" to usercontrols and use some transitions like mentioned in the below link to switch between controls
http://www.tanguay.info/web/index.php?pg=codeExamples&id=280
for more on using transitions look here
http://www.japf.fr/2009/04/adding-transitions-to-a-mvvm-based-dialog/
or
http://www.japf.fr/2008/07/8/comment-page-1/
For example the twitter application you can open one profile and see his tweets then open another profile and go and repeat the same action over and over again, then you can tap on the back button as many times you opened tweets and profiles etc, returning from the same path.
a code example would help me a lot :)
You are looking for examples of a UINavigationController. This allows you to push new UIViewControllers into the navigation hierarchy and helps manage popping the view controllers off when you hit the back button (you can do this programatically also).
There are a bunch of articles on MonoTouch.Info about UINavigationControllers. I think that would be the best starting point for you.
I am looking at doing a program as a hobby and to help a friend with a printing problem they have. The application is pretty simple, just taking in data and sending that data to a print job so my friend doesn't have to manage each thing individually.
My question is this: I want to use a tabbed main interface (Like how Meego OS is) The problem I have is this doesn't seem like it would be structured very well. That is, Instead of having a separate file for event handlers for each tab, they would all be in one file, the file with the tab control.
I thought about doing something like how some websites are made, [home.html, contact.html] [[the home icon in home.html is differentiated between contact.html when at home, contact icon is differentiated between home when on contact.html]] but I need to handle background tasks.
I know those tasks will be in a separate thread (well, at least that's what makes sense to me) but I am still not sure which is the standard method to do this.
Sorry for a wall of text, let me know what needs added or changed. Thanks :)
You can create a UserControl for each page and add them to the TabControl. The code for each page will be in each UserControl and thus a separate file.