I have method getStudents on managed BackBean, I am calling getstudents which inturn makes a call to database and fetches the data. The UI shows properly, but its causing performance issue as it takes too much time to load the page . Please suggest me how to handle this performance issue.
You should no do business logic in getter methods. You should init your list in #PostConstruct method or do lazy loading in getter:
private List myList;
#PostConstruct
public void init() {
// init my List
}
// getter and setter
#PostConstruct method will be called after managed bean instantiation. I suggest you to init in this method, not in constructor. As you are changing your list during the backing bean life, you should update it when it is changed. You can add data which was created by user, or you can chose to call database again after inserting values. You have to worry about this, there is no automation.
Related
I need a model object to initialize (and keep synchronized) some data structures for optimization purposes.
Model{
var shareInstance
var objA : ClassA
var init(){
objA.objB.configureNonRealmProperty() //1
}
}
ClassA:Object{
dynamic var objB : ClassB
}
ClassB : Object{
var non-realm-property
convenience init(...){ //2
configureNonRealmProperty()
}
configureNonRealmProperty(){}
}
Not letting the swift implementation of Realm neither subclass Object multiple times, nor override the init method (this is ridiculous, if only had known before...) i need to find a way to execute a method of class whenever objB is called.
Problem: whenever i access objB this is reallocated from the DB by realm independently if i keep a reference to it (a dynamic reference) or not, as a conseguence it does not matter if i:
(1) call the method configureNonRealmProperty() directly on the object on creation
(2) create a custom initializer and do it there
the objB is ALWAYS deallocated and reallocated at each interaction (through one of the private and not overridable Object initializers), i would have to call the damn configureNonRealmProperty() each time, which does not make any sense.
Question: how can i avoid a Realm Object reference by a dynamic var in another realm object to be deallocated/reallcoated each time it is accessed?
The only solution i can come up with is to have a two-layered model and kick the persistence away in the second one, but at this point i would not see any utility anymore for Realm loosing all of the (at this point already few) advantages.
An alternative would be to have at least constructors/destructors callbacks from realm, but still defeating my optimizations purpose.
Personal consideration: Realm is definitely not flexible and complete enough to be such a pervasive framework (forcing to subclass it's own object instead of a protocol, not letting create object hierarchies, dynamic on all vars, no init override, ecc)
In Xamarin documentation for Foundation.NSObject, in Lifecycle section, it says:
C# NSObjects are also created on demand when you invoke a method or a property that returns an NSObject. At this point, the runtime will look into an object cache and determine whether a given Objective-C NSObject has already been surfaced to the managed world or not. If the object has been surfaced, the existing object will be returned, otherwise a constructor that takes an IntPtr as a parameter is invoked to construct the object.
Is there a way to do the above from my code? In other words, given an IntPtr handle, can I get a C# NSObject if it already exists or let Xamarin create a new one if it doesn't?
The reason I want to do the above is that I want to keep the IntPtr handle of a C# NSObject and then Dispose() it. Later in the code, I want to get the NSObject back from that IntPtr.
The reason I want to do the above is that I've read enough documentation, blogs and SO questions about the interaction between the C# garbage collector and the native refcounted objects in Xamarin.iOS that I decided to Dispose() everything as soon as possible. So in all methods, I use using whenever I get an NSObject argument. For example:
[Foundation.Action("buttonPressed:")]
public void RatingButtonTapped(UIButton button) {
using (button) {
Console.WriteLine("Hello world");
}
}
So if I had kept a reference to the UIButton earlier during initialization, it will be disposed when this action is run. So instead, I plan to keep the IntPtr handle instead and re-get the UIButton when I need it later.
You can use this method to get the managed object for a handle:
ObjCRuntime.Runtime.GetNSObject (handle);
But have in mind that if the native object has been freed, you will crash.
If you don't want to crash, you need to retain the native handle, and then release it when you don't need it anymore.
If you add logic to retain+release the native handle, then you can just as well keep the managed object around, and only call Dispose when you determine you don't need the object anymore.
Curiously you link to the XY problem, and you're falling into that exact trap: your actual problem is that you have memory leaks (I assume, but you didn't explain), and you're asking about your attempted solution (dispose everything).
But that's the wrong solution to the problem. You will run into a world of pain with this solution (you've already found one, and if you go ahead with keeping handles around you'll end up in a much worse place: how to solve crashes instead of how to solve memory leaks).
The correct solution is:
Diagnose (and profile) to understand what's really happening (with the memory leaks).
Only dispose objects that you know are no longer needed (and that the GC couldn't already determine isn't needed). You want to dispose as little as possible (it makes your code easier to maintain), and you need to do step 1 first in order to know those objects.
I've made a small class to test when object declaration occurs.
class MyObject
{
static let instance = MyObject();
required init()
{
println("init")
}
}
And when I run this, "init" is only printed when I reference MyObject.instance, meaning that static variables are declared lazily.
The reason I need this to be eager is because
I want to keep a lookup table of object instances for myself (with weak references, don't worry). Instances to be inserted during their init and expose a lookup function, so the functionality is encapsulated.
I'd prefer if I didn't need a separate function at App start to make references to static variables to achieve this.
I am not aware of an eager keyword, but is there an accepted solution to this? Will it be added in Xcode 7?
Say you have a ScreenManager which inherits DrawableGameComponent, and a GamePlayScreen which inherits GameScreen. And GamePlayScreen is drawn through ScreenManagers ContentManager, and functions just like Game1.cs would. And its LoadContent looks like:
public override void LoadContent()
if (content == null)
content = new ContentManager(ScreenManager.Game.Services, "Content")
foreach (Objects object in objects)
object.LoadContent();
And object class calls same LoadContent method, but of course says object = content.Load<Texture2D>(" - ");... I'm getting the error:
"content = new ContentManager(ScreenManager.Game.Services, "Content") - Object reference not set to an instance of an object." In my objects class LoadContent method.
Is there a way to call GamePlayScreen's content or ContentManager, from the object class?
+++++++++++++++++++++++
Ok, I've realized what exactly the problem is. I'm using the Logic of the GameStateManagement Sample, "created by the head tech of Xbox Indie Games", which is in its own right is brilliant code... If all you're doing is making a main menu... lol...
BUT, ScreenManager is the DrawableGameComponent, its list of GameScreen's makes it and said screen the only functioning things in the Game. Or possibly only the screens are, and when they transition off ScreenManager is called, wakes up, adds new screen and goes to sleep again.
Thus NOT allowing you to call any classes, object list's, or anything contained in another class...
Now one may think, just create a new ScreenManager2 : DrawableGameComponent , or maybe even an ObjectManager : DrawableGameComponent .... Ahh ahhh, already beat you to it friend.....
Creating a new ObjectManager allows your objects to be drawn over everything your original ScreenManager deals with... True;... including your PauseScreen, and PauseMenu.... Garbage!
And before you mention a ScreenManager2, that to handle PauseScreen and PauseMenu, tried that as well. I successfully manipulated all code to do so, up until Play was selected for ScreenManager to tell LoadingScreen to function, then call GamePlayScreen...
Which leads to Asik being right, my content is Null, because I cannot figure out a way for my object class/classes to be called and Initialized with the way this code works.
Which leads to me asking the question correctly...
How do you call a class to Initialize, just long enough to allow LoadContent in the GamePlayScreen to gather said classes/objects information, to be put in its object list?
Lehman's terms: "GamePlayScreen on your LoadContent function, wake up Object1.cs, add object information in your ObjectList, tell Object1.cs to sleep, GamePlayScreen go on with your bad self..." ???
You are making use of GameComponent and DrawableGameComponent. Your subclasses that inherit from these have access to the Game instance via their GameComponent.Game property (that is, if you've passed it into their constructors rather than specifying null.
This is good. Just use GameComponent.Game.Content to access the ContentManager in each.
"Object reference not set to an instance of an object" is a NullReferenceException: it means you're trying to access something from a variable that is currently null. On the line you have posted, I see two possibilities: either ScreenManager.Game is null, or ScreenManager.Game.Services is null. Why? Because you're not initializing them by the time this line gets called.
That said, why not just pass the ContentManager that whatever class needs it rather than instantiate new ones?
With the complexity of ScreenManager, I found no way to load the content directly from the Object1 class, I was however able to call an older form of object handling:
In Object1 class...
Texture2D image;
public Object1(Texture2D texture)
{
this.image = texture;
//other information...
}
Even though SpriteBatch was never declared in the objects class, I was able to call:
public override void Draw(SpriteBatch spriteBatch)
{
spriteBatch.Draw(image, Rectangle, Color.White);
}
And in GamePlayScreen's LoadContent:
Texture2D tempImage = content.Load...
objectList.Add(new Object1(tempImage));
And then in GamePlayScreen's Draw function which calls for GameTime, I called:
foreach (Objects object in objectList)
object.Draw(spriteBatch);
After 2 weeks later, this is finally resolved... And I quote myself:
"It all looks so easy, until you're the one who needs to figure it out..."
I'm using GCD to add thread-safety to a class.
Some public methods of my class are called by other public methods in the class. However, this leads to the re-entrant locking problem: if I protect the appropriate publicly visible methods with synchronous GCD blocks (in some cases), the re-use means sometimes I'll be trying to run anther synchronous block on the current queue, which leads to deadlock.
What's the most elegant solution? An obvious approach is to have internal versions of the appropriate methods, without any GCD blocks, and external public versions of the method that have the GCD blocks wrapping calls to the interal methods. This doesn't quite feel right to me.
Here are a few thoughts:
See if you can't use immutable objects. This means that whenever a method would modify the object it actually returns a new object with the modified state. The blocks would then go on and use this new object. This is simple, requires no special care but is not always possible.
See if your public methods can't use private methods that carry around state. Since each block would carry around its own internal state then you are also thread safe.
If you had some example use case it might lead to a more ideas...
I've used a pattern like this very successfully in our C++ classes that use dispatch queues for synchronization:
class Foo
{
public:
void doSomething() {
dispatch_sync(fQueue, ^{ doSomething_sync(); });
}
private:
void doSomething_sync() { ... }
private:
dispatch_queue_t fQueue;
};
The general convention here is that for any given _sync method in a class, you only call other _sync methods and not their non _sync public counterpart.