Is there a common navigation convention in an MVVM Light Windows Phone application? - windows-phone-7

As my app gets bigger I am finding that the same type of entity is appearing more and more throughout, typically in a listbox.
When someone taps on the entity, I want to navigate to the detailed view of this entity.
An example of this would be a product: it appears in a product list by category, it appears in search results, or it might appear as a saved favourite. In my instance, all of these would come from a table in local SQLCE storage.
Every time I surface the entity in some way that someone could tap on it, I basically cut the same code: subscribe to the SelectionChange event on the listbox, extract the entity, use MVVM Light messaging to signal that the selected entity has changed, then call NavigationService to do its business.
Has anyone worked on something similar and, if so, what have you came up with? Or more importantly, if there's some MVVM Light toolkit convention that I'm overlooking, could you please point me in the right direction?

Are you calling the NavigationService from code-behind or the View Model now? If the former, you could check the WP7 Navigation arcticle by LBugnion for triggering it from the VM. If you combine that with the EventToCommand behavior (like in here) you should be able to create a nice and clean "MyEntitySelected" command in the VM which takes the entity as a parameter.

I think the question here is, how do I deal with this without cut/paste the same code each time? If this is the case, maybe trying to package the entity/listbox thing in a XAML usercontrol! Take a look at this: http://www.windowsphonegeek.com/articles/Creating-a-WP7-Custom-Control-in-7-Steps
Then if the representation needs to be different, you could have a look at this: http://www.windowsphonegeek.com/articles/Implementing-Windows-Phone-7-DataTemplateSelector-and-CustomDataTemplateSelector ( this example does different styling in one listbox, but you can change this to only apply different style on each different page with a listbox on it )

Related

Asynchronously loading drop down menu - Flutter

I am trying to build a form with a phone input that includes country codes. Essentially, I am trying to make something a lot like this:
I already found and cleaned a list of flags, countries, and their codes, and built the method that creates a DropdownMenuItem for an arbitrary index. I then construct a list of them and pass it to the DropdownButton widget. It's all very simple, so I don't think the code is necessary. However, because I have so many countries, and therefore menu items, the menu lags significantly when opening. So, I was wondering if drop down menus are capable of loading large numbers of widgets in a smarter fashion than it seems they do.
Can a drop down menu could load the first 10 or so widgets around the selected index and display them, as that is all that will be in view initially, and then load the rest of the widgets asynchronously? I suspect that this will require a custom drop down menu, but I am not very well versed in the implementation of Flutter's drop down menu, so I am unsure of how to proceed with this.
Any help is appreciated.
I don't think that "loading" is the actual problem here, more likely it's the rendering/building of the widgets. You can improve the situation by using something like a ListView.builder that builds items on demand.
It seems like the default dropdown system is not based on a ListView.
You can create your own version of the dropdown (like a complete customized copy of the classes), which will require quite quite a lot of work and research.
Or alternatively, use something like a SimpleDialog with an embedded ListView to display the list. Like this one for Android.

Are there some samples about moving and removing of a row of listbox

I try to migrate my iphone app to wp7.
On ios, UITableview is well designed, and very easy to code.
I have the some book about wp7, but there are no detail concerned about moving and removing of a row of listbox.
Welcome any comment
I'd like to think that Windows Phone is also well designed. :)
To simply remove an item from a ListBox in your codebehind, you need to get a reference to the ListItem that you want to remove. For example, to remove the currently selected item:
var myListItem = myListBox.SelectedItem;
Then you can remove it with:
myListBox.Items.Remove(myListItem);
In order to address your question about moving items, we'd need to know more about how you're populating the ListBox. Are you using databinding, or adding items with myListBox.Items.Add(myListItem)?
If I needed to move items between two lists, I would create a public List<MyItem> property for each list and databind each list to its own ListBox. Then I might do something like this (working from memory here):
var itemToMove = myList1.Remove(myListBox1.SelectedItem);
myList2.Add(itemToMove);
myListBox1.DataBind();
myListBox2.DataBind();
There's a much better way to do this, using INotifiyPropertyChanged, but I suspect you need to play around with the basics for a while to get comfortable in C#.
Bonus tip: Windows Phone is very similar to Silverlight, and you can usually find more information if you search for Silverlight examples.
In WP7, usually we set the ItemSource of listbox, when our source changes its changes automatically propagate to the UI due to data binding ( it is known as one way binding ; source to UI ).
so what ever you do ( add, update or delete) in itemsource, it reflects to UI.
databinding in wp7

pivot with in Panorma ....swipe both together

when i use pivot with in the panorama .pivot are used as a gallery view. i want to move pivot when i swipe it .but the problem is this because of both panorama and pivot are the same gesture event so both are they move .
i want swipe only my pivot view .
I would like some sample code or any other suggestion to do this.
so please give me a solution for doing this and
also give me a link where i easily understand this. Thanx in advance
You shouldn't have a Pivot in a Panorama control. End of discussion.
I believe it is achievable, because I've already solved similar issues with having WebBrowser control inside a custom horizontal-scrollable overview container like Pivot/Panorama, but believe me, it is NOT worth it. I've had to dig very deep into the visualstructure of the controls and attach my own manipulation-handlers to their viscera, manually choose which horiz/verti events to pass and which to cancel, and so on. This is not so easy, takes a lot of time, and doesn't guarantee that on the end you will have something behaving in a way you wanted to achieve in the first place. If you are not bound by some contract to preserve the shape of the UI, please, drop the idea and redesign your UI, just to save on your sanity and nerves.
But, if you are already insane or really want to dig where noone should, start on analysing your UI as a two rectangles: large pano and small pivo, and think which part should behave how on different possible touches/h-v swipes/h-v pans/pinches/so on. Write it down just to for reference, or soon you will probably start making small mistakes that will interfere with your understaning of the flow of the events.
I've checked the version I have, and "my" Panorama uses internally the UIElement.ManipulationXXXX events. In that case:
Display visualtrees of your UI and try attaching manipulation-events to every control. In those events, write/log which control's which handler was invoked. Then make some swipe/scroll on your APP and observe events. Analyze how they were bubbling and try cancelling (e.Handled=true) the manipulation-completed and/or manipulation-delta events somewhere between pivot and panorama. Your goal is to have the panorama see that e.Handled=true, while your pivot must see e.Handled=false. Your Pivot will probably see the event sooner than the Pano, so that point should be relatively easy.
If it fails to work, then you should check your version of the Pano, and check how it detects movements. If, for example, it uses the GestureListener - try the same trick with it. Etc.
And remember, you can always make your own horizontal-overwiew-container that will look like Pano, behave like Pano, and that will work with Pivo better - because it will be your code and you will tell it what and when to move. if you want to go this way, start on google and check all the preliminary Panorama previews that random people have published before that control was published by MS.

Create multiple page form in Cocoa

I want to create a form with iOS like transitions (in a Cocoa desktop application) between the form input. For instance, the user would input information to the form and click next to continue to input the remainder of the information. On the last form, the user would click submit. Upon clicking next, the form would have an animated transition, like on the iPhone before displaying the next set of forms. Sort of like how Turbo Tax ask a ton of questions before allowing you to submit that grouped information.
What would be the best approach to achieve this goal?
This is commonly referred to as a wizard.
You basically have two options:
Use a tabless tab view, following Apple's sample code in AnimatingTabView from http://developer.apple.com/library/mac/#samplecode/Reducer/Introduction/Intro.html
Manually swap the views in and out yourself.
There are pros and cons to both approaches. Which you choose will probably depend on your requirements. One issue with Core Animation on the desktop is lack of subpixel rendering for layer-backed views. This is mostly an issue with text display but some people find it not to be an issue.
I've needed this functionality a few times. I used this tutorial to get started.

Talking Among GWT Panels using UIBinder Layout

New to GWT here...
I'm using the UIBinder approach to layout an app, somewhat in the style of the GWT Mail sample. The app starts with a DockLayoutPanel added to RootLayoutPanel within the onModuleLoad() method. The DockLayoutPanel has a static North and a static South, using a custom center widget defined like:
public class BigLayoutWidget extends ResizeComposite {
...
}
This custom widget is laid out using BigLayoutWidget.ui.xml, which in turn consists of a TabLayoutPanel (3 tabs), the first of which contains a SplitLayoutPanel divided into WEST (Shortcuts.ui.xml) and CENTER (Workpanel.ui.xml). Shortcuts, in turn, consists of a StackLayoutPanel with 3 stacks, each defined in its own ui.xml file.
I want click events within one of Shortcuts' individual stacks to change the contents of Workpanel, but so far I've only been able to manipulate widgets within the same class. Using the simplest case, I can't get a button click w/in Shortcuts to clear the contents of Workpanel or make WorkPanel non-visible.
A few questions...
Is ResizeComposite the right type of class to extend for this? I'm following the approach from the Mail example for TopPanel, MailList, etc, so maybe not?
How can I make these clicks manipulate the contents of panels in which they do NOT reside?
Are listeners no longer recommended for handling events? I thought I saw somewhere during compilation that ClickHandlers are used these days, and the click listener "subscription" approach is being deprecated (I'm mostly using #UiHandler annotations)
Is there an easy way to get a handle to specific elements in my app/page? (Applying the "ID" field in the UI.XML file generates a deprecation warning). I'm looking for something like a document.getElementById() that get me a handle to specific elements. If that exists, how do I set the handle/ID on the element, and how can I then call that element by name/id?
Note that I have the layout itself pretty well nailed; it's the interaction from one ui.xml modularized panel to the next that I can't quite get.
Thanks in advance.
If you don't have a use for resizing events than just use Composite
What you want is what the GWT devs called message bus (implemented as HandlerManager). You can get a nice explanation in the widely discussed (for example, on the GWT Google Group, just search for 'mvp') presentation by Ray Ryan from Google I/O 2009 which can be found here. Basically, you "broadcast" an event on that message bus and then a Widget listening for that event gets the message and does its stuff.
Yep, *Handlers are the current way of handling events - the usage is basically the same so migration shouldn't be a problem (docs). They changed it so that they could introduce custom fields in the future, without breaking existing code.
If you've set an id for any DOM element (for Widgets I use someWidget.getElement().setId(id), usually in combination with DOM.createUniqueId()) you can get it via GWT.get(String id). You'll get then a RootPanel which you'll have to cast to the right Widget class - as you can see it can get a little 'hackish' (what if you change the type of the Widget by that id? Exceptions, or worse), so I'd recommend sticking with MVP (see the first point) and communicating via the message bus. Remember however, that sometimes it's also good to aggregate - not everything has to be handled via the message bus :)
Bottom line is I'd recommend embracing MVP (and History) as soon as possible - it makes GWT development much easier and less messy :) (I know from experience, that with time the code starts to look like a nightmare, if you don't divide it into presentation, view, etc.)

Resources