1st i'm newbie
I import object/Class using lazy()
now my questions are
1) what is the lifetime of my object?
2) how this object disposes?
3) if Disposed manually can MEF later reinitialize it when i issue object.value?
Generally the lifetime of the object is the same as the lifetime of the container, and it is disposed with the container. The lifetime/disposal can happen earlier in some situations for NonShared parts. Here is an answer that goes into more detail on MEF part lifetime.
For your third question, the answer is no. Depending on what you're trying to do, ExportFactory might be what you're looking for. It will let you create and dispose multiple copies of a given export.
Related
We can expose an object of a class by two methods like:
ClassName obj=Classname(); or obj=Provider.of<ClassName>(context);
is there any difference between them , or is there anyone of them better method.
ClassName obj = Classname();
This is creating a new instance of Classname. In Dart, you can omit the new keyword (since v2.0), older versions and most other languages actually force you to spell it out:
ClassName obj = new Classname();
It will call the constructor of the class and create a new instance. Alternatives would be named constructors that could look like this:
ClassName obj = Classname.fromInt(42);
That said, what exactly is this and what is the difference:
obj = Provider.of(context);
A provider is a form of state management. State management is a complex way of saying "where do I actually call my constructors so that the instances are known to the program at the place and time I need them? Sometimes I want a new instance, sometimes I want the instance I used before."
A provider may create a new instance for you. It may also decide it already has the instance you are looking for. You decide that by configuring it.
The only way to create a new instance of a class is through one of it's constructors. Very likely (but configurable), a provider is using a class constructor to create the instance of a class that it is then providing to multiple layers of your program so you don't have to keep track of that variable yourself.
Keeping track of all your variables and their lifetimes by yourself gets complicated really fast the bigger your program gets.
My personal recommendation to everyone learning programming is: try it the way you already know (in this case: constructors). Then you will experience for yourself what the problem is and you will know why packages like provider or bloc were created. This is a much better learning experience than just believing a random person on the internet (me or someone else) who says they know it's "better". Because then you will understand the problem instead of being railroaded into some cargo cult of "use this, it's good for you".
welcome to the StackOverflow.
You can do both of them, but if you are using the Provider package, you have some benefits:
It is much easier to transfer state to another level (or even really far level) inside your app's tree.
It is really suitable for a large scale app to manage their state (but it's also suitable for the small app).
If you are passing a state or an object directly, you'll be completely in a mess when your app complexity grows (based on my experience).
I hope it will be helpful.
listening is not possible with normal object creation where as with provider it is possible.
obj=Provider.of(context, listen:true);
I am wondering if it have a sense to reuse the same ObservableTransformer instance in different compose() operation, kept as a singleton somewhere as example. I don't see any pitfall in the documentation and code (because it simply called the apply method under the hood for new compose use) but every example i find create a create a new one. So maybe I miss something.
Thx for your answer,
Would like to get some thoughts on how to best organize session vars within a scala / lift application.
I've read over a number of scala materials online and have found generally the following paradigm in all examples that introduce session vars:
declare an object that extends the SessionVar class
put that object into a file that contains a snippet (or any file)
access that object from anywhere in the codebase (lift will take care of the session var's lifecycle based on the lifetime of the user's http session)
Perhaps I'm not understanding something, but I'm concerned that this approach would lead to a whole bunch of these objects in various files all over the place. Its not such a big deal if its a small app, but when a project gets larger this could lead to chaos.
For those who have worked on larger scala projects, is there a generally accepted better approach? (even if its something simple like putting all of these objects into a common file?)
Thanks.
This is a bit subjective, but I'll give it a try. I think it depends on the scope the session var has in your project.
If you need the session var only in one snippet, you should make it a private member of that class.
If you need it in several but not all snippets, put those snippets in a package and make the object private to that package. If you have a lot of them, you could create an extra file to hold them.
If you need it globally, put it into a central location, maybe inside a package object.
If possible, avoid using SessionVars completely.
SessionVars should be used sparingly in your application. They are similar to Servlet Session Variables, except they are type safe.
How many session variables do you need? Personally, I have a session variable for the primary key of the current user and maybe one or two more. The rest of the state of the application should be stored in closures (because functions associated with GUIDs close over scope).
I'm developing an app based on a TabBarController.
I have 2 views that do some similar actions.
My question is, should I make 2 different classes or should I use only one class with some "if" statements asking if is a class is one or the other. I need maximum performance on this.
The 2 views load a MKMapView, so I need to know if it is better to load just one object that does the entire thing, or two objects that do similar things.
Thanks!
In Object Orientation it's important to bear in mind the difference between a class and instances of that class.
If you ever find yourself thinking of writing some code in a class that says "What class am I? If I'm class X, do thing A; otherwise do thing B" -- don't! It's a classic problem begging for a nice object oriented solution. There are two common solutions in this kind of situation:
1) Write a single class that at instantiation time gets passed in some vital information that it then uses later. Then another part of your code is making instances of this class configured in the correct way -- e.g. in your problem, two instances of this class get made, each with a different bit of info (map location perhaps?) passed into the init method
2) Write a superclass that has two subclasses that specialise the general bahaviour of the superclass. So most of your logic and code goes in the superclass - suppose it's called MapDisplayViewController - but then you extend this class with two subclasses called (for example) MapDisplayViewControllerA and MapDisplayViewControllerB that override one or more methods in important, different ways to differentiate them.
For your problem it sounds like approach 1) would be good.
Having code which says "What class am I?" is often a good example of a 'code smell' -- in other words, a sign that something could be designed much better.
I would say load two objects. iOS will automatically unload your currently not displayed views if it needs more resources anyway. (Assuming you implemented viewDidLoad and viewDidUnload properly, of course).
In addition, if in case your view needs to initialize/load a lot of data when tab is switched, and the common flow involves the user switching from one tab to another frequently, the app may appear to lag during frequent loading, if you use only 1 object. No one likes long and frequent loading times.
Just my opinion though, based on the information your original post provides. A lot of additional factors can still come into play.
I have an extremely hard time figurering out how classes needs to communicate with eachother. In a current project I am doing, many classes have become so deeprooted that I have begun to make Singletons and static fields to get around(from what I get this is a bad idea).
Its hard to express my problem and its like other programmers dont have this problem.
Here is a image of a part of the program:
Class diagram
ex1. When I create a Destination object it needs information from Infopanel. How to do that without making a static getter in InfoPanel?
ex2. DestinationRouting is used in everybranch. Do I really have to make it in starter and then pass it down in all the branches?
Not sure if this makes sense to anybody :)
Its a problem that is reacurring in every project.
After looking at your class diagram, I think you are applying a procedural mind set to an OO problem. Your singletons appear to contain all of the behavior which operate on the records in your domain model and the records have very little behavior.
In order to get a better understanding of your object model, I'd try and categorize the relationships (lines) in your class diagram as one of "is-a", "has-a", etc. so that you can better see what you have.
Destination needs some information from InfoPanel, but not likely all information. Is it possible to pass only the needed information to Destination instead of InfoPanel?
What state is being captured in the DestinationRouting class that forces it to be a singleton? Does that information belong elsewhere?
There's just too little information here. For example, I am not even sure if MapPanel and InfoPanel should be the way they are. I'd be tempted to give the decorator pattern a try for what it's worth. I don't know why a Listener is a child of a Panel either. We need to know what these objects are and what system this is.