I have a Java Swing application. I want to upload information to a web endpoint, and that process will take enough time to justify spinning off the work onto another thread. I'd like to use the Swing SwingWorker paradigm to do that. I'm confused on where I should be extending the SwingWorker.
Right now I have a single class for each web endpoint, and that class stores all the data destined for that endpoint, as well as the code necessary to interface with the endpoint (housed under a method called upload()). Should these classes implement SwingWorker since all the data is there that it needs to perform its task? Or should I have a secondary class FooWorker implement SwingWorker, that will call Upload() off of an internal Site object?
If I make a secondary FooWorker class, then it seems like I have to go to some trouble to stuff references to the Site into each FooWorker object that I instantiate (one thread/worker for each web endpoint), but that the Site won't be polluted by a bunch of SwingWorker methods and code.
If I extend SwingWorker with the Site class, then I can just call .execute() directly from the EDT for each Site which is much cleaner, to me, than creating a worker for each site, and then having that worker call upload() off the site.
Just looking for opinions and ideas about which approach is better. The Site class is already fairly complicated, and I'm afraid of putting a bunch of domain unrelated stuff into it if I extend the SwingWorker class. But the FooWorker class, if I go that route, will basically just be a thin wrapper around the Site class. Is that wrapper worth the trouble of keeping the Site class focused only on its own domain methods/data?
It is always a good idea to introduce abstractions where it makes sense. In this case, I'd say it makes sense because you might end up creating several SwingWorker classes.
What you could consider is to create a single SwingWorker class called, say, SiteWorker. Then, I'd create Site interface which implements the method upload(). Each class representing a connection to a site endpoint would implement this Site interface. You could then simply have SiteWorker to deal with the Site interface instead of you having to deal with all different sorts of Site classes implementing SwingWorker.
Remember, program to interfaces and not implementations. It makes your life easier if you can just create a single SiteWorker and then concentrate on the various site implementations.
Thus, you could pass the Site instance (which would be any class implementing Site) as an argument to the SiteWorker class, which would then, in its doInBackground() method simply call the upload() method of the instance implementing Site.
Related
I have a method inside of a class called
ChopraWisdom.GetQuote()
that pulls in some data from the interwebs. To use it I have to use an AsyncTask in my activity. Thats fine and all, but my Activity code now gets cluttered with the AsyncTask code.
I was hoping that I could hide the AsyncTask in my Class and then create another method called
ChopraWisdom.GetQuoteAsync()
But I'm not sure how to pass in "Actions" (I come from a .Net background) in order to handle the various UI updating that needs to take place.
In C# I would define the method signature as something like:
ChopraWisdom.GetQuoteAsync(Action preExecute, Action postExecute, Action updateProgress)
Questions:
Does java have something comparable to 'Action'?
What is the acceptable pattern for 'wrapping' Async functionality like this in Java?
I like clean code, but am I being to picky here?
Please provide examples.
EDIT - Added Example class
public class ChopraWisdom
{
public string GetQuote()
{
//...do stuff and return a string
}
}
You should really think about using Loaders instead of AsynkTask(with android support lib).
If you still want to use AsyncTask in your situation best way would be to create new interface Action(something like https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/functions/Action0.java)
You could use RxJava in your project and use all they have https://github.com/ReactiveX/RxJava/tree/1.x/src/main/java/rx/functions
You could use https://github.com/evant/gradle-retrolambda in combination with (2) option to provide C# like lambdas in your java code.
Java does have something comparable to Action. It is called Function and only available in Java 8. The standard way for passing a function as parameter is to create an interface and provide it as a parameter. That way you can either pass in an instance of a class implementing that interface or create an anonymous class inline. You encounter the latter everywhere in Android (OnClickListener, etc ...)
I would highly recommend you to take a look at Android Annotations. It provides useful features like:
Dependency injection
View injection
OnClickListener via annotation
AsyncTask via annotation
...
And the best thing: everything is done at compile time through subclassing, therefore there is no performance impact and you can check what the framework is doing at any given point.
You are not too picky at all. Clean code is very important in Android development as you have to write a lot of boilerplate- / gluecode anyway.
Here are some other handy android frameworks that are definitely worth checking out:
GreenDao
Eventbus
I am working on a project in which I am supposed to make a client and the role of that client is to construct a url basis on input passed and make a REST call on the right server.
And they can do it in two ways, either making a synchronous call or making an asynchronous call. So now I am not sure what is the right way to do this?
Should I make an interface for this with two methods synchronous and asynchronous method and a class that will implement this Interface or should I just make a simple class with these with these two methods inside that?
What is the better approach?
I would not put both methods into the interface, just the synchronuous one.Then imagine N different implementations which really only care about getting the data. All of them can likely be wrapped into a single asynchronuous wrapper class. No need to force each implementation to reinvent the asynchronuous behaviour.
I need to create a Playlist, I want to separate code/logic and GUI by using two classes:
Playlist (code/logic)
PlaylistGui (GUI)
It shall be possible to use the Playlist class standalone, e.g. in some kind of command line environment. The question now is, how would one plug both classes together, when using a GUI? My ideas until now:
Expose an observable list from the Playlist class, create a method setItemSource(Playlist source) on the PlaylistGui class
Not sure if possible in Java, just know this from .NET: Let Playlist class fire events and let PlaylistGui catch them, should lead to uncoupled code? :-)
Open for new ideas :-) Note I am using Java 7 and JavaFX, though I guess JavaFX doesn't limit possiblities, just extends them.
Events in Java:
http://castever.wordpress.com/2008/07/31/how-to-create-your-own-events-in-java/
Other alternatives are:
Java Delegates?
or both as separate processes with communication via sockets
Have a look at FXML, Controllers and the SceneBuilder tool.
I think your basic concept is sound, delegation of responsibility.
I would create an interface of the model, exposing only those methods you think that any basic controller/viewer would want. This means you can change the implementation without effecting any of the components that rely on it.
Listeners are, essentially, just a call back mechanism, where interested parties register themselves (through a common interface) to be notified when something occurs that they are interested.
Take a look at Writing Event Listeners for more information.
I would basic start out with a common library which defines the basic interfaces that all parties would need to know out (such as the PlayList and listeners).
This would allow to design 'n' implementations of the playlist based on your needs
I have a class which extends JFrame and forms the GUI of my program. I want to use the GUI for two main purposes:
I want the user to be able to input values to the program.
I want the GUI to display values created by my program.
Considering my class has a lot of GUI elements, the source file is already rather large and It does not seem like good practice to bundle all the program code in with the GUI code. I'm wondering what is the best way to structure my code? I believe there is an issue where requirement 1 creates a dependency from the GUI to the program code, and the second requirement does the opposite.
So, I want one class for my GUI which contains all my GUI related tasks. I then want another class for my program logic. I should then be able to call methods from the program logic class from the GUI and vice versa.
Sounds like you are looking for a textbook MVC (Model-View-Controller) design pattern. I recommend you google "MVC Design Pattern" for summaries and use cases. That being said, you might want to put your program logic into a "Singleton" class (again, google "Singleton Design Pattern"). A properly implemented Singleton should be accessible from any other class in your code.
Consider also a third middle class which acts solely for data storage, you put values into it for storage, and you fetch values from it for work. This now creates 3 clear segments for your code, the Data (the Model), the GUI (the View), and the logic (the Controller). Voila, you've just implemented the MVC (Model-View-Controller) design pattern...
The business logic should not depend on the GUI logic.
Have your GUI take inputs from the user. Call business logic methods with these inputs as method arguments, and use the values returned by the methods to display the result in the GUI. The GUI thus depends on the business logic, but the reverse is not true.
If the business logic must callback the GUI, it should do so via well-defined GUI-agnostic callback interfaces, or listeners. For example, you could register a ProgressListener on some business logic object, and this object would call back the progress listener. The GUI would have an implementation of the ProgressListener which would in fact update some progress bar or text area. But the business logic only depends on the interface, and not on the specific implementation.
I'm not sure there is one "best" way to structure GUI code. As a general rule though, you should follow MVC. Your program (Model) should never directly depend on your View code. What it's allowed to do is notify the controller that the model (or parts thereof) changed, and that whichever views are currently displaying said part of the model should be updated.
Swing already provides this abstraction layer for some of its types of component, most of the classes are (somewhat confusingly) suffixed with Model. A simple example you could look at would be BoundedRangeModel. There should be only one instance of such a Model for every "unit" of data your program manages, and different views displaying this data should share this instance. Your business code manages this object, and whenever this piece of data changes, the GUI is notified using it by firing off some event listeners.
So for my current project, there are basically three main Java classes:
GUI
Instant Messaging
Computation
Essentially, there needs to be full communication, so we've decided to use the mediator approach rather than than allow the GUI to run the entire project.
Basically, the mediator is going to encapsulate the communication. The problem we've run into is how to allow the GUI components to update without building a ton of methods for the mediator to call anytime something completes.
Ex. Say the GUI wants to log in the user, it goes through the mediator to create a thread and log in, but then the mediator has to relay the success/failure back to GUI as well as update a status message.
The other issue is things that need to update the GUI but do not need the moderator. Is it practical to just allow the GUI to create an instance of that class and run it or should everything go through the mediator?
Our original design just had the GUI managing everything, but it really killed reusability. Is there a better design method to use in this case?
If you're finding Observer to bring too much overhead, Mediator may be the best way to go. I definitely think that you shouldn't have the GUI run the show. If you're going to use the Mediator pattern, the mediator itself should be in charge. Something you might consider is a variant of the Command pattern. If you were using Ruby, I might recommend passing function callbacks around as a means of avoiding having the mediator contact the GUI for every little thing. But since it's Java, some form of encapsulating an action in Command pattern style may help.
If you don't want the callback/notification to be triggerd by the mediator, you can inject the callback into the login function and have login call it when it finishes.
I don't know how you would go about injecting the callback in Java, though. In a language where functions are first class citizens, you could just pass the function, but you're in Java so I guess you will have to use the command pattern as kmorris suggested.
You might also try having the GUI give the mediator a callback object that handles retrieving return values or setting whatever values you need (a version of the Command pattern). There would then be one per call from the GUI to the mediator.
Another thought is to group the methods the mediator calls into semantically related chunks. In particular if the mediator has sections where it tends to call several GUI methods in a row:
gui.a()
gui.b()
gui.c()
you can create a single method that handles the result of calling all three. The advantage of semantically grouped methods (i.e. setFileInformation over setFileMenu, setTab, etc.) is also then if you need to change the GUI, the contents of the methods might change, but the call the mediator makes may not.