Problem : The page loading is slow. it takes about 10 sec for 300 customers records and databind to a ListView.
I want to increase the loading speed. So I create a global variable in App.Xaml. This allows the page that needs the data can reference it without doing a loading.
Example:
P1 -> P2 -> P3
at P2, there is less work.
I do the loading in P2. and I databind it in P3.
I dont know what I need to use. Static or non-static Global variable.
Thanks.
1) public ObservableCollection AppCustomers {get;set;}
2) public static ObservableCollection AppCustomers {get;set;}
I think there's only a single App instance, so it shouldn't matter with which you go. Static will probably make it easier to access. Having these properties be in App.xaml is a different problem. You should probably put these in another class. Maybe in AppCustomers itself or some other data access class.
Related
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!
I am trying to set up a generic class that deals with menus within Unity3D.
The following code I intend to attach to an empty game object
import System.Collections.Generic;
#pragma strict
public enum MenuType { loadSceneOnMouseDown, enableGameObject, changeValue };
public class MenuClass extends System.Object
{
public var menuObject : GameObject;
public var menuType : MenuType;
}
public var menuItems = List.<MenuClass>();
This results in the following within the editor:
I want each menu type to have its own parameter, so in this example I want the "loadSceneOnMouseDown" to have another public variable as a string defining the name of the scene to be loaded, once loadSceneOnMouseDown is selected from the enum. Whereas I want the "enableGameObject" Type to have a gameobject as a public var. However I dont want both to appear in both fields. For example I could make it like this:
public class MenuClass extends System.Object
{
public var menuObject : GameObject;
public var menuType : MenuType;
public var sceneName : String
public var targetObject : GameObject
}
But that would make it come under each element of the list. I considered doing a further subclass to resolve this, but then with the line "public var menuItems = List.();" that wouldnt work. (or would it? :D)
Apologies if I have been unclear, trying my best here but Im finding it difficult. Theres probably a very simple solution, or im going about thins entirely the wrong way. Any help with this problem would be very much appreciated!
Thanks!
Unity's serialization doesn't really support polymorphism. A list of type MenuClass can technically contain subclassed objects at runtime, but as far as serializing the list Unity is going to assume they are all objects of the base type.
It's a bit inconvenient, sometimes.
There are a few popular workarounds:
Leave all of the possible fields serialized MenuClass, then write a custom inspector which exposes only the relevant fields while you're working. In simple cases like yours, this is often the quickest solution.
Serialize some basic data fields, then use that data to reconstruct your more elaborate objects at runtime. For example, Unity can't serialize a Dictionary, but it can serialize two lists which you stitch back together. Handy, still simple, has some limits.
Build in some custom serialization library, and go nuts with it. Popular choices include JsonFx, MiniJson, Protobufs, and C#'s built-in XML serialization. Lots of work, but very powerful.
Like I said, in your case I'd recommend starting with the custom inspector, if you think that'll cover your needs.
Aside from code that's in most common tutorials, you could switch based on that control value, then call functions like EditorGUILayout.FloatField(), EditorGUILayout.ObjectField() and their cousins to get data.
Custom editor scripting is often overlooked, but it's one of the most powerful features available to Unity developers.
If I declare something like
#FXML
private final static double PREF_SPACING = 10d;
or
#FXML
private Insets insets = new Insets(10d);
in the controller class,
is there a way to use their values in Scene Builder?
When I want to change the value, I want to change
it only once, in the controller class.
PRELIMINARY ANSWER
I haven't yet tried all of the techniques below, but it seems to be the way you would do it from reading the documentation. If I get some time, I'll try it out later and update this answer with results (or somebody else can do this and post a new answer or edit this one to create a definitive answer). I just wanted to publish something now to point you in what I believe to be the right direction.
If the below is not what you are looking for, add a few more specifics to your questions to fully describe what you want.
Don't using the #FXML annotation here. #FXML is for injecting values from the markup into the controller, not the other way around.
For your first example which is a constant, let's say your controller class is:
class MyControllerType {
public final static double PREF_SPACING = 10d;
}
Then in your fxml, reference the constant:
<?import MyControllerType?>
...
<VBox>
<spacing><MyControllerType fx:constant="PREF_SPACING"/></spacing>
</VBox>
For your second sample which is not a constant or a part of the SceneGraph, you can use an fx:define element to instantiate an instance of the class. Note that you can't directly instantiate an Insets class from FXML as it has no builder class nor zero length constructor. So what you might be able to do is create another placeholder class for the information and instantiate a reference to that in your FXML (or you can create a Builder that FXML can use to instantiate the Insets).
class InsetsHolder {
private Insets insets = new Insets(10d);
public Insets getInsets();
}
<?import InsetsHolder?>
<fx:define>
<InsetsHolder fx:id="i"/>
</fx:define>
<VBox>
<Button text="Click Me!" VBox.margin="$i.insets"/>
</VBox>
SceneBuilder should be able to read fxml files which use the fx:define and fx:constant notation, as well as (possibly) make use of the reference expression $i.insets. SceneBuilder might not have any UI to allow you to edit the values from within the SceneBuilder application, so you will probably need to hand edit the fxml file portions related to the fx:define and fx:constant elements if you wish to make use of these structures.
There is an executable example of using an fx:define element in this mailing list post on designing resolution independent units in FXML.
In general, I think I'd be a bit cautious of maintaining these kind of dependencies between fxml and java code. It may be more prudent to do more of this kind of stuff in plain Java code within the context of the controller initialize method as scottb suggests.
The #FXML annotation enables the JavaFX objects whose names you defined (fx:id) to have their references reflectively injected into nonpublic fields in the controller object as the scene graph is loaded from the fxml markup.
To the best of my knowledge, this is a one way operation. There is no provision for having named static class variables in the controller object injected into the scene graph during loading.
You can accomplish something very similar to what you are requesting by defining the values that you want set as class variables in your controller object's class, and then setting the appropriate object properties programmatically (rather than in markup) in the initialize() method of your controller object.
The initialize() method is called (if it is present) after the loading of the scene graph is complete (so all the GUI objects will have been instantiated) but before control has returned to your application's invoking code.
Hi I have a question about best practices vs safe programming in building a JSF Web Applicaiton.
I have employee.xhtml page having backing Bean - EmployeeBean. All the variables that I declare in the backing bean are non static and have getter and setter methods. For example:
ArrayList <Employee> alEmployees = new ArrayList<Employee>();
int userId;
The constructor of the BackingBean loads the employees. I acheive this by calling a static method in delegate.
userId = //some value.
alEmployees = EmployeeDelegate.loadEmployees(userId);
The Delegate method calls a static method in DAO Class.
Will the static methods cause any data concurrency issues when n users are using the application at same time? I mean userId 56 seeing userId 75 list when both are using the application same time?
Is it really advisable to have static methods in Delegate and DAO layer?
Please let me know if I was not clear.
Thanks
If the EmployeeDelegate does not hold any class variables which is sensitive to changes caused by method calls and/or has influence on how methods behave, then it's safe to do so.
You however have another major problem with this approach. The delegate should be an interface so that you can easily substitute it with a different implementation. This approach suggests that the delegate is not an interface at all (since it can impossibly have static methods).
I've been busy working on a program that can solve Minesweeper puzzles (for no other reason than I think it's fun). When it comes down to the UI, though, I greatly dislike the idea of instantiating over a hundred of the same control, one per cell. Should I create a custom control that handles all of its drawing and input itself? What approach do you guys suggest?
I'm using WPF, and I'm pretty new. Any pointers would be awesome.
Yes a custom control would be a good idea. Also, M-V-VM is a must in a situation like this; it will reduce the complexity of your app greatly.
I'd take a UniformGrid and use Buttons as the squares. You'd have to create a tri-state custom button if you want to add in the "?" intermediate state.
The model for the button would look like
public class MineSquare : INotifyPropertyChanged
{
// exploded, number, or nothing
pubic ImageSource ButtonImage {get;private set;}
// true, then goes to false when clicked
public bool CanClick {get; private set;}
// bound to the Command of the button
public ICommand Click {get; private set;}
}
You deal with the model in code rather than the controls. Drop in nine MineSquares into an ObservableCollection on your ViewModel bound to your UniformGrid and you have a 3x3 minesweeper game. Each button handles its own logic. You can hook into the models via the view model to iterate over all squares and determine if everybody has been clicked.
I think you should create a single, owner-drawn control. WPF is cool, but a WPF app still has the same limitations regarding the total number of controls on a form, so having a separate control for each cell in Minesweeper would still be problematic.
Minesweeper is pretty played out, though, as much as I love it myself. Maybe you could have more fun with it by making the cells hexagonal instead of rectangular, and arranging the mines so that they spell out dirty words or something.