I have an n-tier application. The front-end is an MVC site (if that makes a difference). The MVC site, the business logic and the DAL all have access to a specific shared DLL in which is defined a Singleton class.
This all works, as if I assigned a value of "foo" to the Singleton's property Bar in the DAL, the front-end will see "foo" when it accesses Bar.
The question is, what else can see the Singleton? If another users logs in to my MVC application and a page that page sets the Bar property to "Fred". What will my first user see when he accesses Bar.
Is a Singleton truly the only instance of that class? Or is it the only instance of that class for a given user?
What about if the first user opens another window in the browser in the same app? If he causes Bar to be changed in one window, is it changed in the other?
The question is, what else can see the Singleton? If another users
logs in to my MVC application and a page that page sets the Bar
property to "Fred". What will my first user see when he accesses Bar.
All the users see the last value. ("Fred" in your example)
Is a Singleton truly the only instance of that class? Or is it the
only instance of that class for a given user?
It's the only instance of the class across a thread. If your web application runs in multiple worker threads, you will have multiple instances.
What about if the first user opens another window in the browser in
the same app? If he causes Bar to be changed in one window, is it
changed in the other?
when you're talking about "web application", the term "window" is not so good. each window is created by a request. and each request can change your singleton object value.
Related
I'm creating a service that works independent of the app and sends notifications according to some business rules.
The problem is: if the app is open, depending on which activity is open, I can not do anything, but the default action is to open a specific activity.
I can not find any similar example or problem to study...
Any idea?
I'm sorry for the poor english.
Try to create your handlers methods as static in your "App" class and manage the behavior of your app since that point. Think about to use some events to handle specifics changes (as notify with a "new" badge on view, if you want).
I don't have a independent service, but I'm working in an app that once a user is logged in, it starts a background service to monitore battery, updates, user properties changes... and this solution works well.
I'm using Unity for Dependency injection under Prism and have a situation where one of my modules is to display a screen saver of sorts when the user is running a test and no input has been received. (The region holding the view for this module displays in front of all other regions.) The idea being if the user goes to the other side of the room while the test is running, they can see a summary of relevant test information. When they interact with the application again, the screen saver will exit and return them to the main display.
Since the Shell is what captures user input, I need to alert the screen saver module to hide the view when the user interacts with the computer.
The screen saver module itself implements a shared service interface in the ViewModel that consists of an Enable() method and a Disable() method. The screen saver is only enabled when a test is running. The modules that run these tests will call Enable/Disable as needed. The ViewModel contains an internal timer that when the Screen Saver is enabled, will trigger the display of the View upon expiration. If the user interacts, the timer will reset (and the View is hidden).
I'd like to keep my application from having a large amount of PubSubEvents when its not necessary to have one. In this case, when the user interacts, I'd like to be able to add a method to the Screen Saver service that the Shell can use to signal the user interaction. However, I don't see how that is possible without a PubSubEvent, since the shell is created before the Screen Saver module, unless I want to use a ServiceLocator or by adding a reference to the Screen Saver project in my Shell, both of which I think are worse options than using the PubSubEvent. Even if I separate the services into their own separate module, and reference that from the Shell/Boostrapper (registering via ConfigureContainer()), that module will still need to somehow be able to communicate to the ViewModel to reset the timer/hide the view.
Am I just overthinking this? Is there some other way I can do this? Or is my initial idea of PubSubEvent the best way. I'm rather new to Prism, so I'm still getting a handle on best practices.
I cannot see anything wrong with using the EventAggregator, but you can, of course, use a specialized service that does basically the same thing, just only for enabling/disabling the screen saver. Just register that service as a singleton and have it injected wherever needed.
To make things a bit nicer, seperate the active (e.g. EnableScreenSaver() and DisableScreenSaver()) and passive (e.g. IsScreenSaverEnabled property and ScreenSaverStateChanged event) members into two different interfaces, implemented by the same service. This way you get a little bit of advantage over the EventAggregator - events cannot be publish-only or subscribe-only, whoever knows the event can always publish and subscribe. But you can make the active interface known only to the parts of your app that want to control the screen saver, whereas the passive interface can be only known the parts that have a screen saver that needs to be controlled...
Background
I'm creating a windows forms application that implements the MVP-VM pattern. This post explains the overall approach I'm taking:
http://aviadezra.blogspot.ca/2009/08/mvp-mvvm-winforms-data-binding.html
My application has a main window that opens on application start-up. The main contents of the application are hidden until the user logs in, after which the user controls which expose application functionality are revealed.
The main window has multiple presenters, each one representing a different set of logically grouped functionality. When the application starts, only the presenter that creates the login dialog is populated. Then, once the user logs in, the remaining presenters are created. I feel this is a good way to prevent users from somehow accessing functionality until they are logged in.
Question
When a user logs out, I'm having trouble deciding what needs to be done. I don't want to re-create the main window, but the state of the main window at login is I think what I'm trying to achieve (only the one presenter initialized). When someone logs out, should I dispose all presenters except for the one that creates the login screen? How do I do that? I don't imagine just setting the presenters in the main form to null would work, eh?
I have a taskBarIcon element extending Application Context from which my entire UI is designed. This is because the original functionality of the application was to run a background process and simply provide the icon as a confirmation that the app was running.
However, I am now adding additional functionality in the form of a menu that may be accessed by right clicking the icon, and since the core functionality is running on one thread, and the icon on the main thread, I am having issues accessing the icon in the simple case of needing to display a notification bubble. There are no other points at which the two threads may be accessing the same memory, so synchronization is not really an issue.
I am used to Java, in which this process is far simpler. I've read the articles I can find regarding the Invoke-Delegate dance that C# requires, but none are specific to an object extending Application Context. My current implementation is far too unpredictable to be production safe.
My question is this: How do I send the message to the other process to display the notification bubble, without disturbing the accessibility of the menu? Specifically, a simple example with a UI class extending Application Context and a class on a separate thread calling the invoke method would be very helpful.
I really appreciate any help!
badPanda
You could just as well use a SynchronizationContext object that you assign to SynchronizationContext.Current on the same thread that you create the notification bubble. You would then pass your SynchronizationContext object into whatever component the menu is on and it would use context.Send(....) to send a message. Or, if you have access to the notification bubble component or the form it's on, you could do form.Invoke((MethodInvoker)delegate {....});
I found there are lots of posts showing how to detect if the application instance already running. But I cant find any one that shows how to access or use the same running application.
I have created shell menu items and linked them an application. For ex. If you right click on any folder it shows "OS Monitor". If i clicked on that an application is started. If I again right clicked on the folder and selected "OS Monitor" another instance of same application is started. I have to prevent this. Further more when user closes the "OS Monitor" form I just made it hidden. So that if the user again selects the same menu option then the same running form need to show.
I have created the application using C#2005. Does anybody have the idea how I could access the same running instance of the application.
Thanks in advance.
As address spaces of applications are separated, you have to use some global mechanism/object. An example is named mutexes: you create a named mutex, if it already exists, then the application was already running. Using Mutexes for ensuring that only one instance is running is presented on this blog
The second step is to communicate with the running instance. Therefore you have to use some IPC mechanism. Easiest is to use Windows messages if you are running Windows (like in the example from Blog). Note that this would not be portable to MONO as you have to make native calls. If that matters you could use a network connection among other possibilities. See answers to this question: IPC Mechanisms in C# - Usage and Best Practices.
After having transmitted the parameters to the running instance, you have to exit of course, otherwise you'll end up with two applications running. For a short time (the time of parameter transfer) you have indeed two instances running but only one effectively is doing the job.
This response was made under the assumption that you can/wish to make modifications to "OS Monitor".