Can I have one itemStateChanged method to monitor changes triggered by user for many Displayable objects in a MIDlet (e.g. for a form and a list), using if clauses to decide what was changed, or do I have to create a different method for each Displayable I want to monitor?
If you are talking about instantiating several Form and one ItemStateListener and calling Form.setItemStateListener() several times with the same parameter, then yes, you can do that.
Theoretically, you should write thread-safe code in your implementation of itemStateChanged but given the way existing java-me implementations handle events and the very small number of MIDP-compliant phones using 2 physical screens, I don't think it's very important in practice.
Related
A common multi-threaded implementation is to have some class where Method_A() is running in a thread and sits blocked waiting for some signal/event member variable (e.g. WaitForSingleObject).
Interacting classes running in different thread will then call Method_B() which does some work, sets the signal/event variable, perhaps does some more work, then returns.
How do I represent this interaction on a Sequence Diagram?
Should I have two lifelines, one for each thread, even though they are operating on the same instance of the class? My modelling tool (Enterprise Architect 12) doesn't allow the same class to appear twice on a Sequence Diagram, so seems to discourage this.
Edit: Geert has noted that the Sequence Diagram should use instances, not classes, which is a fair comment. However the problem is the same: multiple lifelines would imply multiple instances, but in the question Method_A() and Method_B() are operating on the same instance, just from different threads. How can that be represented?
The approach I have decided to take is to add two lifelines for the same instance, then label one lifeline with the <<thread>> stereotype and add the thread it runs in to the name:
I realise this is probably not standard UML, but it seems to get across all the information I want to express in a clear manner, which is the most important thing, right?
Martin Fowler does mention a few times in his book that sometimes a non-normative diagram is actually clearer. So that's my excuse. :)
(Edit You can solve it by just using asynchronous messages as #sim points out. That will just do. The answer below is showing what is going on under the hood. So if you don't care about the details, go with that answer.)
You are asking more a design than an UML question. Namely, how do concurrent instances talk to each other. You said first
Method_A() is running in a thread and sits blocked waiting
which simply means that it can not accept anything since it is blocked. Now, guessing from the context of your question, I assume that you still want to communicate with that instance since
in different thread will then call Method_B()
So, in order to be able to accept a message the instance must be in an appropriate state. There are a couple of ways to achieve that. One simple is, if the according OS has support for that, to return to the scheduler and tell him that it's waiting for some message.
Now when method_b is being called you know inside Object1 that you are in some kind of idle state inside method_a and do appropriate (return-) action.
Another way would be to poll the scheduler for incoming messages and handle them.
You need to keep in mind that sending a message usually not directly deals with the instance but tells the system scheduler to interact with the appropriate instance (at least in most OSs).
I just remember from the Modula2 compiler I once wrote that it has a concept of coroutines which allows a concurrent thread to run within the compiled code. But basically that is just mapped to two independent threads running under the hood of a semi-single one and you'd depict that with two life-lines when going into detail.
N.B.: Rather than method it should be operation (since that is was is invoked by a message; while the method is what is implemented inside the operation). And as per common convention they should start with a lower case char.
And also: do NOT use classes in a SD. Unfortunately EA still allows that (why? Ask them!). Somewhere hidden in their docs there is a sentence that you must use instances. Else the model will break. A SD is always (!) a sample sequence of instances talking to each other. Classes do not talk, they are just blueprints for the instances.
You should never use classes in sequence diagrams, but instead use instances/lifelines that have your class as classifier.
If you hold the control down when dragging a class to a sequence diagram you can choose to drop is as instance instead of as class.
This way you can add as many as you want for the same class.
The notation you are looking for is an asynchronous message. You could theoretically express this using a single lifeline. But this wouldn't be readable. So a possibility would be having two instances of a threadclass in your class and show the interaction between the instances. But never show classes in a sequence diagram.
But why are you using a sequence diagram at all? For such internal behavour an activity diagram is most likely more appropriate. There you can use send and receive messages elements to express such a behavour per thread. Or if it shall be shown in one diagram, you can use fork.
I am creating this sequence diagram, and wondered exactly what methods to include. I have included all methods in every method, for example, the
handleCustomerAccountAction()
method, got a method from another class called
getListOfCustomers()
Is that right to do, or do you only have to include the method and not all the methods it uses inside it?
Also, is it okay to show the same method multiple times on other methods? For example the method
getListOfCustomers()
is shown three times (the one with a loop around it), but from different methods.
Here is the image of my sequence diagram:
It always depends on what you want to show. A SD shows a certain collaboration you want to explain in detail. A SD should focus on a certain aspect and must not show each and every message (e.g. certain call branches can simply be left out). However, if a method is called twice in a sequence you must show it if it's of importance.
I want to understand some best practices regarding using MVVM and multithreading. Let us assume I have a ViewModel and it has an observableCollection. Also, let us assume I pass this collection to another service class which does some calculation and then udpates my collection.
After a point I realize that I want to make this a multithreaded call. When I make the call to the service class using threads or tasks what results is a cross thread operation. The reason is quite obvious because the service class updates the collection whcih in turn will update the UI on the background thread.
In such scenarios what is the best practice? Should we always write our service class in such a way that it first clones the input and then updates that cloned copy? Or should the view model always assuem that the service calls might be multithreaded and send a cloned copy?
What would be the recommended way to solve this?
Thanks
Jithu
A solution that might solve the cross-thread exception is by implementing the OnPropertyChanged in the base class of all ViewModels to switch to the correct thread/synchronization context so all properties in the View that are bound to the changing property will have their handlers called on the correct thread. See: Avoid calling BeginInvoke() from ViewModel objects in multi-threaded c# MVVM application
If/when you create copies you are postponing the synchronization and, in many cases, making it harder than need be.
A web service will always return new objects, how you, or a framework, updates the model using these object is up to you. A lot would depend on the amount of checks and updates coming in. There is no recommended way, see whatever fits the applications requirements.
I have an application that I am working on, and I'm basically self-teaching GUI programming. I asked a fairly involved question over on programmers.stackexchange. This question is about the mechanics of an idea I had not tried.
I have three widgets: a TreeView, a TextField, and a DrawingArea. Each of the three widgets interacts very intimately with events on one necessarily triggering actions on the other. Those three widgets largely do not interact with the rest of the application except (so far) by reading an MVar containing the global application state.
Currently I can think of no case in which the larger application should ever interact directly with any of those three widgets. Further, that identical pattern would be replicated to review other data that has the same form. So, it seems to me that it would make sense to actually bind these three widgets together into a larger composite widget that can interact with GTK's normal event queue. So, for instance
type MyDataViewWidget = (TreeView, TextField, DrawingArea)
data DataUpdatedSignal a = DataUpdatedSignal a
data RedrawEvent a = RedrawEvent a
So, the widget would use DataUpdatedEvent to indicate to the rest of the application that something inside MyDataViewWidget changed, and RedrawEvent would tell the widget that it needs to redraw or re-read the source data.
(technically, I have not thought through semantically what the various actions in the composite widget would do... whether the widgets would just have a read-only copy of the application data and need to receive new read-only copies with the RedrawEvent or perhaps the widgets would have the MVar itself and be allowed to change the data in the MVar, etc... I'm just interested at the moment in how to actually do this)
Are there any examples of doing something like this? Basically, what instances do I need to implement to create the new widget and the two signals? I'd prefer to stick to Haskell, but I could drop to C in order to build up the new widget.
Unfortunately, there is currently no pure-Haskell way to (correctly) implement the Widget type class. You'll need to implement your widget in C, then import it via the FFI. There are numerous examples of this -- basically all of gtk+/gtk2hs is a collection of hundreds of examples of doing this.
I am developing an XNA project, where there are two DrawableGameComponents A and B, with the following constraints:
Either A is visible, or B is visible. So only one of their "Draw" methods has to be called.
Both A and B need to be enabled - always. So the "Update" method of each has to be called under all circumstances.
Currently both A and B are executed in the same thread. However, the "Update" methods of them are very CPU-Intensive. Since both GameComponents do not need to talk to each other, and both GameComponents do not need to share any data, it is easily possible to parallelize them.
What I would like to know is how to do that in XNA. The "Update" and "Draw" methods are called by the XNA Framework, so I do not know where to put the Threads. Is there a standard way of doing this?
Usually this is done through game state managment, where the Game1 class (default class) is used to call the Update() and/or Draw() of other classes (game components)
Take a look at the xnadevelopment game state managment tutorial, their they describe how to call diffrent updates and draws of different classes, and hopefully u'll see that multi-threading can be implemented in the Game1 class (default auto-created XNA class)
p.s. if you dont mind doing a lot of reading take a look at this article on XNA multi threading, its accompanied by some diagrams that explain how it works very well.
You haven't specified if you need both Update's to run simultaneously so I'm going off the assumption that one component is the only that needs to be drawn.
Using DrawableGameComponents they are automatically synced with your Game object, but, if you store a reference to each component instead of instantiating them without a stored reference, such as:
componentOne = new FirstComponenet(this);
Components.Add(componentOne);
componentTwo = new SecondComponent(this);
Components.Add(componentTwo);
// Immediately disable componetTwo
componentTwo.Enabled = false; // Prevents Update from firing
componentTwo.Visible = false; // Prevents Draw from firing (for Drawable components only)
Then you can let XNA manage the Update/Draw loops as per normal. componentOne and componentTwo being class level variables, you can manage when each are active.
Again, this is based on the assumption that you don't need one to update at the same time the other does.