I have added two Leaflet.Draw plugins to my application where one of them is used for pure drawing and the other one im just using to get the drawn polygon to use for some spatial querying.
I need to have both of them but when draw:created is fired, both of the tools will capture the event.
I wonder if my approach to "override" a private function is bad practice and if there is any better way to accomplish it.
My approach is to extend L.Draw.Feature and change the function _fireCreateEvent to send a custom event:
_fireCreatedEvent: function (layer) {
//send custom event
},
Related
Is there any way i can implement two stepts like this(see below) in a single function:
When I click on the "Button_name" button
When I click on the "Link_name" name
Is there any syntax so the cucumber won't care what will come after the string and on these two steps i will not need to make two different functions?
Usually i will implement them separately with something like this:
#When("^I look at the \"([^\"]*)\" button$")
public void smt (String smt){ }
Yes, you could implement one step with one method, and pass what was clicked as an argument to that method.
However, this will make your test code more complicated. So please consider whether you should. Having complicated logic in your test code, will make your tests harder to understand and maintain, thus defeating their purpose imho.
If you want to reuse common functionality, the recommendation is to write helper methods that you can call from your step definition.
For example:
#When ("I click on the {string} button")
public void clickButton(String button) {
clickButton(button);
}
#When ("I click on the "Link_name" name")
public void clickLink(String link) {
clickLink(link);
}
and implement clickButton() and clickLink() to click a button or link respectively. (I've used different clickButton() and clickLink() methods in this example, because iirc these would use different types of elements.)
If needed (or you really want to use a switch) you could use a switch statement to get use the right selector based on the button or link name.
Alternatively, you could implement page objects, add all the relevant selectors for the page object there and call the method on the relevant page object that click that particular link/button, delegating the logic to interact with the UI to the page objects and calling this logic from your step definitions.
If are different context one click button and other click link, the best practices is to have two different steps.
One of the bad practices of using BDD is to think about reusing code within steps.
When you have a lot of logic inside a step, any modification can affect many tests.
Should be concerned about code reuse in page objects.
I am creating a winRt app. In which I am having a Home.xaml page which having a another page called Market.xaml. So for snapped mode the same code is repeated.
Now my itemListView (used for snapped) and itemGridView (for full view) both have this page (Market)
<views:Market x:Name="viewMarket"/>
And the constructor of this page is called twice which I not want.
So do I use some flag kind of thing or some better approach is there.
Thanks
So, let's talk about this:
XAML is basically a varying syntax to C#. So, when XAML references a control like your views:Market with <Views:Market />, you are actually putting in something like new Views.Market() in both places. Basically, invoking the class twice. Should the constructor not fire twice, the time-space continuum would split in half. Dogs and cats living together, the whole 9 yards.
But, more fundamental here, what is the purpose of the constructor in C#, or in a XAML class? Is to do expensive things that you would not want to repeat? No. The reason for this is because the completion of the constructor is necessary before the UI thread is released and allowed to render the control. The resulting effect is a UI hang.
Moreover, the C# constructor is a synchronous method. It cannot properly invoke or hold asynchronous operations. This means long-running or expensive tasks that should be invoked immediately, should not be invoked in the constructor because it would also require them to be synchronous and UI-blocking. It is because of these last two points I suspect your constructor is being misused.
The solution is in the XAML framework. The XAML Page pipeline includes the constructor (since it is a C# class and they all have it) but it also includes a Loaded event. In many cases, the hard work necessary to fill page controls is in the Loaded handler. This allows the page to render properly, then starts the long-running action that will ultimately and asynchronously update control content.
In WinRT, the Page pipeline also includes an OnNavigatedTo() virtual method in the base that you can override to the same effect. In the override you can include the hard work of talking to a service, deserializing from a file, or whatever you need to make your UI work. Both the Loaded event and the override can be asynchronous, and neither prevent rendering by freezing the constructor.
But, there's another thing to consider since we're in C# and that the rather common pattern called singleton that allows for us to reference a type in two different contexts but without creating a brand new class. This is accomplished by making the class constructor private, but exposing a public property usually called Instance that returns a single, shared instances in some static place.
That might solve your problem already. Then again, none of that is probably what you need. Assuming you already know all that, the quick answer is you can't prevent a constructor because a constructor is necessary to create a new instantiation of any class, including a XAML view. Instead, whatever you are trying to prevent being double might need to be a combination of the discussions above. An offloaded method, and a static reference to prevent duplicate efforts.
Something like this:
public class Market : UserControl
{
public Market()
{
Loaded += Market_Loaded;
}
static bool AlreadyLoaded = false;
void Market_Loaded(object sender, RoutedEventArgs e)
{
if (AlreadyLoaded)
return;
AlreadyLoaded = true;
// TODO: your work
}
}
But that might not do it for you because the static variable is scoped too large. Instead, you can control if it does the big operation with a dependency property you add to your control. With a boolean dependency property set to false, the second control knows not to do something. With it set to true, the first knows to go ahead. And, so on. This prevents all future use of the view or user control in your app from thinking it should not run because of the static property in the above solution. Then again, that might be perfect.
Best of luck!
We try to build an application with a few tabs. As reference-project we use that example: http://slodge.blogspot.co.uk/2013/06/n25-tabs-n1-days-of-mvvmcross.html
To get the ViewModel-instances we need to create the tabs, we used the "HomeViewModel"-pattern as mentioned in that post: Create View Model using MVVMCross built in factory?
What I don't like at this approach is the initialisation of ViewModel's with "new". As far as I understand, it skips the whole ViewModel-Lifecycle (https://github.com/slodge/MvvmCross/wiki/View-Model-Lifecycle) which we really like. In our current project, we'd like to use the "start()" lifecycle-method, but it's never called due to initialisation with "new".
What worked for us was to go that way:
var loaderService = Mvx.Resolve<IMvxViewModelLoader>();
var vm = (UserListViewModel)loaderService.LoadViewModel(new MvxViewModelRequest(typeof(UserListViewModel), null, null, null), null);
So my question: Is that the way to do the job or is it just a dirty workaround and there is a much better solution?
Update: We came to that solution:
CreateTabFor<SettingsViewModel>("Settings", "settings");
//This method loads the ViewModel
private UIViewController CreateTabFor<TTargetViewModel>(string title, string imageName)
where TTargetViewModel : class, IMvxViewModel
{
var controller = new UINavigationController();
controller.NavigationBar.TintColor = UIColor.Black;
var viewModelRequest = new MvxViewModelRequest(typeof(TTargetViewModel), null, null, null);
var screen = this.CreateViewControllerFor<TTargetViewModel>(viewModelRequest) as UIViewController;
SetTitleAndTabBarItem(screen, title, imageName);
controller.PushViewController(screen, false);
return controller;
}
The 'viewmodel lifecycle' is an area of conflicting interests in MvvmCross. The root cause is the conflict between:
viewmodel's which are just the models for any view
viewmodel's which are specifically used within the 'ShowViewModel' navigation process
For simple 'whole page' User Experiences, the C-I-R-S viewmodel lifecycle is easy to support and to ensure it gets consistently used.
However, as soon as the user experience starts to merge in tabs, flyouts, hamburger menus, dialogs, split views, etc then:
the developers sometimes want to control viewmodel lifecycles themselves
it's not as easy for the framework to ensure that view models are always created, activated and tombstoned/rehydrated consistently
Personally, I like your approach - of trying to ensure all viewmodels are independent and all constructed the same way - but MvvmCross doesn't force this approach on all developers.
Specifically for tabs, most of the existing examples do use the 'owned sub-viewmodel' pattern that you've identified.
However, it should be relatively easy to implement other mechanisms if you want to - just as you already have.
In particular, you can:
use the loaderService directly - getting hold of it via Mvx.Resolve<IMvxViewModelLoader>();
use ShowViewModel with a custom presenter to create both views and viewmodels - the beginnings of this is illustrated in that N=25 video but you could take it much further and actually add the tabs in response to ShowViewModel calls.
use alternative calls to create the child tabs and their viewmodels inside the Views - e.g. where the Touch sample currently calls
var screen = this.CreateViewControllerFor(viewModel) as UIViewController;
this could easily be replace with something like:
var screen = this.CreateViewControllerFor<ChildViewModel>() as UIViewController;;
(or one of the other overloads from MvxCanCreateIosViewExtensionMethods.cs)
One repo where I know some users have taken some of these ideas and played with them is the Sliding menu repo - I think they have chosen to use this.CreateViewControllerFor<TViewModel> to create their view models. This may or may not be the way you choose to go - but it might be of interest for you to experiment with.
I am new to web programming and of course to YUI.
I tried using the overlay, chart and node-menunav.
Wanted to know if there is any option of creating these widgets using dynamic data coming in JSON format and updating the widgets as the new data comes in?
For us all the properties will come in JSON data from server and then using that data we need to render menubars, charts, property browser. Now i am not finding how to proceed with this requirement.
Thanks.
There is no default way of syncing widgets via Ajax. The only widget that comes by default with ways of updating its data is the DataTable widget. For the rest, and even for DataTable's attributes, you need to do it yourself.
However, if the data and widgets are complicated enough, you should consider using the YUI App Framework. The combination of Models and Views will help you a lot for creating complex layouts with widgets. Model will give you a way to link attributes to a JSON backend easily, specially if you're using a RESTful API endpoint. And View will give you tools for setting up the markup and reacting to events.
The Model's load and change events will let you know when the data updates. So in your view you'll be able to react to these events and set the corresponding attributes in your widgets:
var MyView = Y.Base.create('myView', Y.View, [], {
initializer: function () {
this.get('model').on('change', this._updateWidgets, this);
},
_updateWidgets: function () {
var model = this.get('model');
this.someWidget.set('someAttr', mode.get('someAttr'));
}
});
But as I said there is no right way of doing this. You can use whatever technique you like. The App framework is just a set of basic components that you can use to structure you application. It's designed for flexibility so it can accommodate many ways of using it. Other ways could use IO directly or use DataSources combined with Widget Plugins. This is a question with many correct answers.
I'm creating an IPad application using C#, Mono develop and Monotouch.
I've been using Monotouch.Dialog to create functionality similar to the wifi-settings on an iPhone. I'm using StyledStringElement with an accessory and am now trying to differentiate between tapping the row and tapping the DetailDisclosureButton.
I've been found out that I should override the UITableViewDelegate.AccessoryButtonTapped on the UITableView. I've tried to created a derived class from UITableViewDelegate and hook this into the Monotouch.Dialog. But this is where I got stuck. I didn't manage to replace the existing UITableViewDelegate with my extended version.
So my questions are:
Is this the preferred way of handling this event (to be able to differentiate between a tap on the element and a tap on the DetailDisclosureButton) ?
If not, any pointer on how to accomplish this ?
I have been searching the web for a (similar) example but have not found any yet. Any examples that you know of that could get me started ?
Thanks,
boris
event EventHandler accessoryPushed;
public override void AccessoryButtonTapped (UITableView tableView, NSIndexPath indexPath)
{
if(!accessoryPushed)
{
accessoryPushed(this,EventArgs.Empty);
}
}
You will need to add this to the DailogViewController code that you are using (this will override the tapping action). Instead of a simple function, you may want an event to be triggered, so just handle the event in your main code. That is probably your best bet.
Once you change this line, you will have to implement new functions like AccessorySelected (just mimic the path the code follows when a row is selected except with accessory).
On the other hand, you could try a different navigation method, often disclosure buttons are annoying and you don't want to click on them except to get simple information about the button (like a help feature).
I haven't found any other examples, sorry!