We Keep Coding

Why use CustomComponent for Layouts in Vaadin 7?

Both the Book of Vaadin and the Vaadin training course recommend using acom.vaadin.ui.CustomComponent to contain a Layout.
I can understand this in pure theory, to encapsulate the contents without needlessly exposing a specific layout such as GridLayout or HorizontalLayout. Encapsulating has benefits of:
Encouraging de-coupling between classes
Makes it easier to change the layout without having to change the declarations in the outer class.
But in terms of practicality, I assume the rendering of a CustomComponent means extra HTML/CSS layout instructions such as perhaps an another div. The last thing Vaadin rendering needs is yet another layering of HTML structure.
I wonder if this might be old folklore. Perhaps using the visual composing tool in Eclipse accepts only CustomComponent objects rather than Layout objects? (Just a wild guess, I have no knowledge)
➤ Alternatively, why not just declare in the outer class a reference variable of type com.vaadin.ui.Layout to get the same encapsulation?
➤ Am I exaggerating the impact of adding a CustomComponent to Vaadin rendering?
➤ Is there some other benefit of CustomComponent which I’ve failed to perceive?

You can compose the content of a CustomComponent with the Visual Designer. This saves a lot of time in the development process

The main advantage of the CustomLayout is, that you can place your components inside HTML code which you otherwise can't generate via vaadin means.
If this adds more div/html as with native Layouts depends on the specific case.
We ususally use it only when a clean Vaadin only solution would introduce more components/div's or is not possible to implement.
The second idea is the separation of layout and logic, which can be implemented partially with this Layout. You just specify which components you have and then a UI designer (in theorie) could make your HTML code, with the correct blocks where your components will be placed.
In real life I do not find this a real advantage, since the whole CSS, sizing etc. is anyway done with vaadin.

How can I get a new Window instance on Android?

I am attempting to create a custom Media Controller by duplicating the source and providing my own layout. The final component is a substitute for PolicyManager.makeNewWindow(mContext);
The PolicyManager class is an internal class and I can not seem to find a way to get a new Window. The documentation suggests new Window(mContext) but eclipse complains that it 'Cannot instantiate the type Window'. Any ideas?

Unless you use the NDK to access private implementations, you cannot actually create a Window. I have done exactly what you are trying with an embedded system, but it is not safe to do for a general purpose app (the underlying implementations have changed and will change again).
Regardless of whether you are using a SurfaceView or TextureView for the MediaPlayer, you should be able to a achieve a similar effect with a regular old transparent custom View. The separate Window shouldn't be necessary. It won't be as easy as copying Android's MediaController code, but it shouldn't be too complicated.
Also, if all you want is a different layout and not a drastic change in functionality, have a look at these two links (the second refers to the first, but it adds commentary & an example project).

Writing an AWT widget

I fear I'm just making a ten-times duplicate question, but I've been trying to Google this for quite some time without finding anything, neither in general nor even here on SO, so I'm starting to think it's worth a shot.
I'm wondering, is there a good guide on what is necessary to implement an AWT widget in Java? What needs to be implemented in order to respond to such things as redrawing, resizing, placement, focus behavior and all other such things as widgets may or should do, in a proper manner? All the articles I manage to find describe the process from the perspective of a user of widgets, never from the perspective of the one implementing them.
Also, what would be the primary differences between implementing an AWT widget and implementing a Swing widget? Is there even a difference from the implementer's point of view?

Probably the best way to learn how to write an AWT widget would be to look at the source code for an AWT widget. Here's the source code for the java.awt.Frame class.
I haven't worked with AWT much, but Swing is much better from the GUI developer's point of view. The only difference that I know about from the implementer's point of view is Swing's usage of Listeners.
Again, you can look at the source code to see what's different. Here's the source code for the javax.swing.JFrame class

Not too much difference aside from the fact that AWT widgets are simpler.
You extend one of the 4 classes: Component, Container, Canvas, Panel. The first two are heavyweight, the latter two are lightweight (don't have native window system peers). Override paint(Graphics) (or update()) and getPreferredSize() to make it visible, then look into javadocs for overriding event handling methods.
Sure you know this link, http://docs.oracle.com/javase/6/docs/api/java/awt/Component.html

How's View gonna know what component to create?

I'm developing this application where you can put text and drawings in a page. My application is in MVC pattern, and I need all the model parts, text and shapes to be of the same notion. They all extend an abstract ReportElement clas, for example.
But the problem is I crate a JPanel for every shape in the page, but to handle text I need to use JTextArea or something. To render the elements the View directly gets the report elements list from the Model and draws one by one. How can I distinguish a text element without hurting the MVC pattern.
I mean, it's impossible, right? I don't know, any ideas?

I think you're looking for the "Factory Pattern"
You need to have a wrapper method that returns a JComponent based in your own ReportElement conditions.

I would handle this situation by building a factory method that produces the right type of Swing component for any given ReportElement, like this:
public static JComponent buildViewForReportElement(ReportElement element)
Inside this method, you will need to actually inspect the ReportElement objects to see what type of component to build. This inspection might mean checking a field or a flag on each object, or might even mean using instanceof to distinguish different subclasses of ReportElement from one another.
Note that inspecting ReportElement objects like this violates the philosophy of object-oriented programming. A simple "object-oriented" solution would require all of your ReportElement objects to have a buildView() or getView() method, and so your GUI code could just call getView() on every ReportElement without knowing which implementation of getView() was actually being called.
Unfortunately, the object-oriented solution forces you to mix your view code with your model code, and it's good that you are trying to keep the two separate. That's why I would advocate keeping the GUI-building code out of ReportElement objects and instead using a factory method to build the right view for any given ReportElement.

Reset/remove a border in Swing

Here's a very specific coding question:
I've recently been asked to maintain some old-ish Java Swing GUI code at work and ran into this problem:
I've attached my own subclass of InputVerifier called MyFilenameVerifier to a JTextField (but it may as well be any JComponent for these purposes). I've overridden the verify() method such that it calls super.verify(input) (where input is the JComponent parameter to verify()). If super.verify(input) comes back false, I do:
input.setBorder(BorderFactory.createLineBorder(Color.RED));
This is a convention used throughout the UI of this application that started long before me, so I don't have a lot of choice as far as using other ways to get the users attention (wish I did). This is just the way it works.
Problem is, once the user goes back and types something valid into the text field, I need a way to set it back to default border (instead of just saying set it to Color.GRAY or whatever, which is a different color from its original border). I need a way to say, "remove the extra decoration and go back to normal" or just set the border to its default, in other words.

Couldn't you just call input.getBorder() and cache it somewhere before setting the border to red?

Or without caching anything, you could tell the JComponent to update its UI back to the look and feel's defaults via component.updateUI. That should make the component reset its colors, borders, fonts, etc to match the original settings.

input.getBorder()
Wouldn't it be awesome if no one ever saw this and I got away free without the ass-beating I deserve for asking this question?

Not sure how your system is build, but I think you can store the original border before changing it. So you can change it back later
// assuming the Border was not null before
if (!super.verify(input)) {
original = input.getBorder();
input.setBorder(...);
} else {
if (original != null) {
input.setBorder(original);
original = null; // not needed
}
}

You need to preserve the existing border when you change it.
One way to do this is to use the methods putClientProperty() and getClientProperty(), which you'll find documented in the API.

Another possibility, if there are only a few input widgets you need this for is to subclass, e.g. JTextField, add setBorderOverride() and modify getBorder() to return "overriddingBorder" if it is not null.
Then you just use setBorderOverride(redBorder) to make it red and setBorderOverride(null) to clear it.
This of course depends on the painting to use getBorder(), which it may or may not do, and which may be implementation specific.

Incidentally, you only need a single static reference to the border-- it's the selfsame border instance used by all JTextFields.