I have two different and independent JFrame windows:
DataFrame
GraphFrame
The first one is for the user to manipulate, with the input of different values and patterns to display on a graph presented in 2). The 1) sends specific values to 2) (array with doubles) so that "GraphFrame" can create the graph.
I invoke the "main " method from GraphFrame in the "main" method of DataFrame so that they both run at the same time and are both visible during the whole process.
I want these frames to be completely independent, which means that the mission for 1) is to send values and the mission for 2) is to check when values are recieved and then create the graph.
I also prefer to keep most of the methods private, so that they can't be accessed from external sources.
My problem, is that I don't know which is the best way to implement this data exchange. What is the best way for Frame 2) keep "listening" for the values it needs to recieve?
Should I create getters/setters on 2) and with the help of an Observer https://sourcemaking.com/design_patterns/observer ?
Or should I use threads?
Or even the creation of a traditional loop that keeps waiting for values, like:
while(array.isEmpty()) {
//stuck here
}
//create the graph from the values in array
At the moment I am receiving the values in 2) from setter methods, but I am uncapable, so far, of performing the code I desire only after I get the values.
What do you think is the best way to implement this?
P.S.: Should I consider not invoking GraphFrame main from DataFrame and run these 2 separately?
From what I understood, you're trying to run both JFrames in the same application. Conceptually this is rather one UI split into two windows than running two Frames as you put it.
Swing requires all UI elements to be updated by one thread - the AWT-Thread. Also interaction with the UI will run in the AWT-Thread. You need to take this into account.
Also it is best practice to separate data model and view. To solve your problem you could create a model for the GraphFrame that is manipulated by changes on the DataFrame. These changes could e.g. be picked up by a listener on the model that uses SwingUtils.invokeLater() to update the GraphFrame.
Of course there is a number of Issues you might need to care for additionally and depending on your requirements you might need to further decouple the two parts.
You could try having the GraphFrame initialize and then stop, but have a (static/nonstatic) method in GraphFrame that DataFrame can call to update the graph. Afterwards, repaint GraphFrame.
Is this what you're looking for?
Related
I'm working with python scripts in Inductive Automation's Ignition HMI (java backend) software. I'm trying to write a script that locates other scripts that are tied to certain objects. Currently I have
result = window.getRootContainer().getComponent("Group 1").getComponent("TheObject").mouseClicked
which gets the window displaying my object, enters the root container of that object, then the group that the object is in and then finally the script tied to the mouseClicked event on TheObject. When I run this and print the result, I don't get an error, but:
<CompoundCallable with 0 callables>
Has anyone seen this before? Does anyone know what I may need to change in my first line of code to access the actual data stored in the mouseClicked script?
Looks like there is no code associated with the mouseClicked event of that object.
CompoundCallable is a "composition of callables", something callable that calls multiple callables - kind of a callable container. It is used to allow registering multiple functions to be called in a single event handler.
However your CompoundCallable contains zero callables. That means nothing will be called if you call it.
If I understand what you're asking, I don't believe you'll be able to access the data that is in that script (variables, etc.). You could have the mouseClicked script write data to something else in order to access data. There are multiple possibilities for that: Custom Window Property, Custom Component Property, or a tag.
I'm using Java Swing (Eclipse) to create a GUI and want to be able to display a continuously changing list in a panel. In my code this is a LinkedList of Objects and it will automatically reorder and change without any need for user interaction. What are the options for displaying this kind of list in the GUI? Thanks
One option, which I personally have used, is to have a method on the object containing this list, which, when called, modifies the data in the list, and then calls updateUI() which causes the UI to update without any user interaction. In order to detect whenever this list's data changes (I'm assuming you're looking at something external to the program) I would poll using another thread. The method you'd have on the object containing the list would have to be synchronized of course.
I hope this helps...
A Swing JList can take 3 types of collections as input.
An Object array - public JList(Object[] listData)
A Vector - public JList(Vector listData)
A ListModel - public JList(ListModel model)
You're going to have to convert your LinkedList into one of these 3 collections.
My recommendation is the ListModel. You can use a DefaultListModel, extend the AbstractListModel, or write your own class using the ListModel interface.
It is a very popular task when designing UI. To achieve your goals you need to follow next principles
Update your data in list
Send notification to UI Thread for update UI, here is a link to good tutorial
When to much data updates you need to limit amount of UI updates to acceptable (1 per 100 mills or smth), otherwise UI will suffer
I have a lot of existing data in my database already, and want to develop a points mechanism that computes a score for each user based on what actions they do.
I am implementing this functionality in a pluggable way, so that it is independent of the main logic, and relies on Spring events being sent around, once an entity gets modified.
The problem is what to do with the existing data. I do not want to start collecting points from now, but rather include all the data until now.
What is the most practical way to do this? Should I design my plugins in such a way as to provide for an index() method, which will force my system to fetch every single entity from the database, send an EntityDirtyEvent, to fire the points plugins, for each one, and then update it, to let points get saved next to each entity. That could result in a lot of overhead, right?
The simplest thing would be to create a complex stored procedure, and then make the index() call that stored procedure. That however, seems to me like a bad thing either. Since I will have to write the logic for computing the points in java anyway, why have it once again in SQL? Also, in general I am not a fan of splitting business logic into the different layers.
Has anyone done this before? Please help.
First let's distinguish between the implementation strategy and business rules.
Since you already have the data, consider obtaining results directly from the data. This forms the data domain model. Design the data model to store all your data. Then, create a set of queries, views and stored procedures to access and update the data.
Once you have those views, use a data access library such as Spring JDBC Template to fetch this data and represent them into java objects (lists, maps, persons, point-tables etc).
What you have completed thus far does not change much, irrespective of what happens in the upper layers of the system. This is called Model.
Then, develop a rule base or logic implementation which determines, under what inputs, user actions, data conditions or for all other conditions, what data is needed. In mathetical sense, this is like a matrix. In programming sense, this would be a set of logic statements. If this and this and this is true, then get this data, else get that data, etc. This encompasses the logic in your system. Hence it is called "Controller".
Do not move this logic into the queries/stored procedure/views.
Then finally develop a front-end or "console" for this. In the simplest case, develop a console input system, which takes a .. and displays a set of results. This is your "view" of the system.
You can eventually develop the view into a web application. The above command-line view can still be viable in the form of a Restful API server.
I think there is one problem here to be considered: as I understand there's huge data in the Database so the idea to create only one mechanism to calculate the point system could not be the best approach.
In fact if you don't want to start collecting points but include all the data, you must process and calculate the information you have now. Yes, the first time you will run this can result an overhead, but as you said, you need this data calculated.
By other hand you may include another mechanism that attends changes in an entity and launches a different process capable of calculate the new pointing diffence that applies to this particular modification.
So, you can use one Service responsible of calculate the pointing system, one for a single entity and another, may be longer to finish, capable of calculate the global points. Even, if you don't need to be calculated in real-time you can create a scheduled job responsible of launch it.
Finally, I know it's not a good approach to split the business logic in two layers (Db + Java) but sometimes is a requirement do it, for example, if you need to reply quickly to a request that finally works with a lot of registries. I've found some cases that there's no other option than add business logic to the database (as a stored procedures, etc) to manage a lot of data and return the final result to the browser client (ex: calculation process in one specific time).
You seem to be heading in the right direction. You know you want your "points" thing decoupled from the main application. Since it is implied you are already using hibernate (by the tag!), you can tap into the hibernate event system (see here section 14.2). Depending upon the size/complexity of your system, you can plugin your points calculations here (if it is not a large/complex system), or you can publish your own event to be picked up by whatever software is listening.
The point in either design approach is that neither knows or cares about your point calculations. If you are, as I am guessing, trying to create a fairly general purpose plugin mechanism, then you publish your own events to that system from this tie-in point. Then if you have no plug-ins on a given install/setup, then no one gets/processes the events. If you have multiple plug-ins on another install/setup, then they each can decide what processing they need to do based upon the event received. In the case of the "points plugin" it would calculate it's point value and store it. No stored proc required....
You're trying to accomplish "bootstrapping." The approach you choose should depend on how complicated the point calculations are. If stored procedures or plain update statements are the simplest solution, do that.
If the calculations are complicated, write a batch job that loads your existing data, probably orders it oldest first, and fires the events corresponding to that data as if they've just happened. The code which deals with an event should be exactly the same code that will deal with a future event, so you won't have to write any additional code other than the batch jobs themselves.
Since you're only going to run this thing once, go with the simplest solution, even if it is quick and dirty.
There are two different ways.
One is you already know that - poll the database for for changed data. In that case you are hitting the database when there may not be change and it may slow down your process.
Second approach - Whenever change happens in database, the database will fire the event. That you can to using CDC (Change Data Capture). It will minimize the overhead.
You can look for more options in Spring Integration
I'm helping to build a GWT application for a client and rewrote most of the stuff to work better, shorter code, faster, etc. However in all the GUI application I've worked on (not so many really) there comes a flexing point where you just have to put a lot of rules and move logic from the listeners to some common mediator. Then some times this could get an ugly mess so you whatever small think you need to do in the listener.
Let's take an example:
form with 10-20 fields
two exclusive radio control about half of the state of the other fields (enabling, validation, input limits)
three exclusive radio controls control again almost the same fields, but in a different way (affecting calculations, enabling); they are also controlled by the above
4 or so number fields are validated on the fly depending on the previous selections and some real-time data object; they can have upper/lower limits, be enabled/disabled
one drop-down box controls the next 6 or so controls - displaying/hiding them, modifying validators
some checkboxes (shown by the above combo) activate some input fields and also determine their validation algorithm
While everything is up an running, without known bugs, there are a few coding gotchas that really bother me:
code is spread among listeners and some mediator methods.
loading the form with some preset values presents its own challenges: like data objects that might be available or not, data objects that might alter their state and subsequent field behaviour
some fields are having a default value set and this should not be overwritten by automatic filling, but if the data objects are not there (yet) then they will need to be filled eventually when the later become available
form cannot be submitted if any of the fields are not validated
My approach:
identify which fields share a common afair and move code into one place
each radio group shares a single listener implementation between its radios
default form filling is deferred until the live data is available (as much as possible) and as a result it gets called multiple times
each action has a call to a common validator method
the validator runs through all the fields in the form, calls their validators (which highlight all errors) and returns a single boolean
each relevant keypress or mouse action, data change it gets deferred to be called after 250ms from the last call; this means first call just places the validator as a delayed action, subsequent calls reset the timer
Ok, it doesn't make any sense to dwelve into more details but I'm more upset about the fact that there is no clear separation between visual actions (enabling), data actions (setting form field values), field listeners, retrieving form values and live data listeners.
What would be a good approach/pattern (next time maybe) to make sure that MVC get separated and lends itself better to maintenance? I know this is not a typical question but I've read every documentation I could get my hands on and still did not find some helpful answer.
I'd move closer towards MVP than MVC. It's clearly the way Google intends to go, so adopting it will probably mean that you're able to go with the flow rather than fight the current.
How does this affect you? Well, I believe you should accept that a tidier implementation may involve more code: not the 'shorter code' you were hoping for. But, if it's logically structured, efficient code the Google compiler should be able to trim lots out in the compiler optimisation phase.
So, move as much of the logic as you can into the model layer. Test this thoroughly, and verify that the correct level of page reset/tidying happens (all of this can be done with plain JUnit, without any UI). Next, use your Presenter (Activity) to tie the View to the Model: handling the interactions, populating the fields, etc.
you can divide a Huge class in different classes bu dividing the GUI in different JPanels. All the panels are implemented in different classes extending JPanel. Guess that would help you.
I have already posted a question today. This question is about the same project but unrelated. I am developing an application for the Lego NXT Mindstorm robot. I have two robots and a GUI running on a PC.
In leJOS NXJ you can only use one input reader. This means that you can't connect the PC to two robots directly and let the two robots connect to each other directly. So this is what i have done. I have connected the PC to the two robots directly and and when the two robots want to communicate directly, i send their messages through the GUI.
There is a whole lot of communication between the GUI and the robots as well as between the robots themselves. For this reason anytime i write data to the output stream it seems that some of the data are overwritten by others and the system is not working correctly as suppose to.
I have been advice to write a class that will hold a collection(Queue) object so that anytime the robot want to send something, it add it to the collection(Queue) and from that class which hold the collection object, there will be a method so that it checks the collection constantly and whenever it is not empty, it sends the data in the collection to the output stream.
It means that whenever the data in the collection are been sent to the output stream, it is possible a new data is been added.
Some people suggested to me of using ArrayBlockQueue and etc.. but those classes are not available in the class.jar file which the robot uses.
The collections classes that i know in this jar file are Vectors and Queue.
I am asking if someone can help me by giving me ideas of how to implement such class. A method in the class will check from time to time if there are data inside the collection and it will send them through the output stream. While it is sending , it is possible that new elements are being added.
Since the data are being sent from one place, no data will overwrite the other. It sounds to me as a good idea.
All your suggestions are welcome.
Thanks.
Vector is good because (at least in JavaSE - I don't know what Mindstorms uses) it's synchronized, so all calls are atomic - if another thread tries to add something to the Vector when you're removing from it, it will block until you have finished, avoiding the issue where data can get lost.
Alternatively, you may want to have a look at the synchronization wrappers in the Collections class.
Alternatively, you could do your own implementation of a blocking queue by subclassing a standard Queue. Although more complicated, a blocking queue is a better solution, as it avoids a busy wait, where you repeatedly check the queue and are each time told it is empty.