Using GWT 2.8 beta 1

EDIT : An earlier version of this post talked about Java 8 Streams, which are not supported by GWT 2.8 for the moment. My apologies.

A few weeks ago, the GWT Team released on Maven a beta for the new version of GWT: GWT 2.8 beta 1. This new version has been announced for a while and was eagerly awaited by the community.

Other than speed improvement and many cool new enhancements, there are new features we can now use in our GWT application. One big feature of this version, in my opinion, is the support of lambdas, a part of Java 8.

Lambdas

In Java 7, if one wanted to pass a function in parameter, they had to do something like that :

In Java 8 (and also in GWT 2.8), simply do this:

We now have a more elegant way to write exactly the same functionality. It makes for more compact code, with less clutter and cleaner code.

JSInterop

Another thing to note, the interoperability with JavaScript is no more experimental. You can now simply use the annotations (@JsType, @JsProperty, etc.) and directly use a JavaScript library in your GWT code.

As Brendan Donnelson said in his Q&A, you can now imagine – if you have a GWT and JavaScript expertise in your business –  a seamless collaboration between JavaScript developers who do part of the application and GWT developers who use their work in the GWT application.

For example,

This example was taken from the current specification of JSInterop which covers a lot of the possibilities of JsInterop. It is also possible to make content in Java that could be exported and usable in JavaScript. A few of our developers are currently exploring on both sides of this coin. I think it will make for good next articles on this blog.

Concrete example

If you want to see concretely what a migration to GWT 2.8 beta1 is like on a typical GWT 2.7 application, just refer to this pull request. I am currently in the process of moving our BeeStore sample to GWT 2.8. It will give you an idea of how to do so.

We just covered the tip of the iceberg of what is new in GWT 2.8. See the complete release notes for the complete list of features that GWT 2.8 beta 1 brings.

Feel free to tell us what cool web application you did (or plan to do) with GWT 2.8 or JsInterop in the comments!

Live GWT Q&A with David Chandler on GWT 3 and the Sencha GXT roadmap

We are pleased to announce that we are going to hold our February live Q&A with David Chandler on February the 10th..

David Chandler will be our guest for this one and he will be discussing the upcoming changes in GWT 3 and how it fits with the next version of Sencha GXT.

David was formerly the GWT Developer Advocate with Google and is now GXT Product Manager and Developer Advocate with Sencha, Inc

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Return on Kevin’s answers on live Q&A on GWT Material

As you may know, 4 months ago we decided to put in place a new initiative for the GWT community. We wanted to highlight what was happening in the GWT community and start sharing the knowledge.

We held 4 Q&As already, which you can watch here. In preparation of those Hangout on Air events, we prepared a series of questions for our guests.

We know that some of you don’t have the time to watch a 30 min. video, this is why we took notes during the event.
You will have a hint of the live event which you can watch below:

Mark Kevin Baldemor was our guest for this Q&A and he talked about GWT Material. Founder of the Gwt-Material Project,he has been involved in the community for three years now.

Phil: Who are you and what do you do?
Kevin: I am Mark Kevin R. Baldemor, I’m currently staying in the northern part of the Philippines, surrounded by oceans and tall mountains with different species of wild animals. I am now 21 years old and I graduated at Informatics College Philippines with an Advance Diploma on Multimedia Technology in the year of 2013. I have my Internship at BPM Conseil, a french company located in Lyon, France and luckily I did my first job there with the introduction of GWT Technology, HIbernate, OSGI and lots of Google API’s. I do web and mobile development using open source kits like Android SDK and Phonegap. After my work life with BPM, I continued my journey to develop my own open source GWT Ui Framework built Material Design called “GWT-Material”.

Phil: What company are you working for? Can you tell us more about it and your role there?
Kevin: Now, I am working for I3 (Canadian Company) – on the IT Department as a Gwt UI UX Developer and a Project Owner and Contributor of gwt-material open source project.

Phil: Some questions about GWT first: When and why did you start using GWT?
Kevin: I started using GWT on 2013 from version 2.5 to 2.8. I loved the architecture pattern of GWT using RPC to communicate with the Server side components. Then, I tried to make some sort of starter projects using GWT for front-end and Hibernate for the back-end which makes the development process more exciting. As a result, I did more and more projects inside my company and the result was very nice but there was a code duplication when I included the CSS, JS Resources to build a custom widget. That’s when I tried to learn how to build a UI Framework and hosted it on Github with the help of other GWT Contributors to make it more Modular and easy to integrate to other projects.

Phil: Now about GWT Material in itself, you are the founder of this project. When and why did it start?
Kevin: Yes I am the founder of this project. It was founded January of 2015 with an alpha version hosted on Google Code, but later on with the help of other GWT Contributors, we tried to host the project on Github and released a Maven version (1.0) which improved the productivity of the project plus the showcase app. The history of this project started when Google announced their design language called “Material Design” and I discovered Materializecss (a CSS Framework) founded by Mr. Alvin Wang and his team. They wanted to build a website using the design specification of Google. With the whole idea, I finally decided to create an open source Apache 2.0 license GWT Based widgets built in Material Design specifications called “gwt-material” and I added some custom components and called them “gwt-material-addins”, like Autocomplete, Time Picker, PathAnimator, Subheader and etc.

Gilberto Torrezan Filho: Talking about GWT Polymer, doesn’t GWT Material have the same purpose as Vaadin’s project? Will they be competitors to each other in the future?
Kevin: GWT Material is totally different from GWT Vaadin Polymer project, because our project is totally based on GWT widget based systems built on Material Design Specifications and with the help of Materializecss contributed by Avin Wang. GWT Vaadin created their generator api to create paper components using JSInterop, soon on GWT Material we will also implement those features using Elemento and JSInterop to support GWT 3.0.

Zakaria Amine: Is GWT material design library production ready?
Kevin: Yes it is production ready, and honestly we have news coming from the community: they have successfully built a gwt-material design application on Web and also on mobile development using Phonegap. We also provided templates for a guideline on how to develop using gwt-material.

Below are the list of applications built by the community for their personal and company projects:

  1. TripWeGo by Julien Guibert
  2. Healthphere by OrNot (Github username) – http://www.healthphere.com/
  3. MyMoney by Werner Kok

Here are also the list of the templates we provided :

Phil: Question # 5 : What can you tell us about the community?
Kevin: About the community, we have now 118 members on Gitter Channel, 116 members on Google Plus and 128 Stargazers on Github which is a good news for the project itself. Many users submitted their Pull Requests for new exciting material design widgets. Some are submitting issues which improves the stability and quality of the project. GWT Material has 9 members, some are part time contributors and others are actively contributors of the project. Thanks to Ben Dol (New Zealand) on the huge code refactoring made on 1.4 release including the modular theming of the project called “gwt-material-themes”. For the Maven releases of the project, Christian Lacerda (Brazil) is our active releaser for the said project. Sometimes we organize online session using Team Viewer to help one another on how we can leverage and discuss about the project.

Phil: Question # 6 : What can you tell us about it and its evolution?
Kevin: GWT Material is a Material Design based widgets with the help of Materializecss as core framework. We release

  • 1.0 for the (Production Release) it includes the core material widgets.
  • 1.2 Integration of Phonegap plugin with gwt-material
  • 1.3 Maven Official Release
  • 1.3.1 Bug fixes for 1.3
  • 1.3.2 gwt-material Themes
  • 1.3.3 Material Design templates
  • 1.4.0 Huge Code Refactoring
  • 1.4.1 Bug Fixes for 1.4 (Upcoming)
  • 1.5.0 gwt-material-addins components (Upcoming)

On each release we are very thankful to the contributors for their support on gwt-material project. I am very happy that until now the project status is still actively maintained.

On 1.5.0 version, we added MaterialPathAnimator to provide meaningful and delightful animations to transform a source widget into target widget. It helps the users to not loose their interaction between two components e.g a Card transforms into an overlay panel or a button transforms into a card. Also we tried our best to implement core animations like fade in/out, slide in/out or even page transitions into the Material Design widgets. We also added a built in Google Icon Fonts hosted internally and we provided a morphing animation using MaterialIconMorph.

Mohammed Al-Hammouri: What about the performance or size of the library?
Kevin: First, I’m not really good on performance optimization about web applications, but for the css or js resource, files of Materializecss can be measured using their jasmine test. Now, I am developing some big applications and the result is great, it is fast. I don’t have any issue on app’s performance including the server side and populating the data into a specific material design view component. On Phonegap, I tried to integrate my web app but it seems to be too slow because of the JQuery animation plugin which kills the performance. What we did is that we separated the modules into different repositories like gwt-material-theme and gwt-material-addins so that the user can choose whether they want to have only the core components or include the addin components.

Gilberto Torrezan Filho: Materialize CSS is the base project for GWT Material, but currently GWT Material have more components than Materialize CSS. How is the relationship between Materialize CSS and GWT project teams? What would happen to GWTM if materialize CSS is discontinued?
Kevin: This is a good question. I talked to Mr. Alvin Wang about the project and he was happy that their project was used by GWT Material. As for me, I am very thankful for their contribution to the world of web development. If Materializecss were to be discontinued, it is likely that we would have already created our Plan B: “gwt-material-addins” – a collection of custom Material Design Widgets plus Community contribution built in pure gwt-material widgets.

Phil: Question # 7 : What is the future of the GWT Material?
Kevin: This is a good question. As for now, we all know that we are waiting for the GWT 3.0. Everything is new as I heard on the GWT community, such as the usage of JSInterop, Java 8, Web Components and other tech behind it. With gwt-material 2.0, we are thinking about implementing all of these inside the project to provide a bullet proof support for the said open source project to make gwt-material a great project and supports GWT 3.0.

Also we are trying to build more Material Design Widgets and trying to refactored it using JSInterop. We are on the Research and Development process to learn how to use it and provide the architecture of GWT Material 2.0 and will be able to release on Maven Central as soon as possible.

Martin Hollerweger: How do you see the future with GWT and js-Interopt? What are the main benefits of GWT compared to other solutions like ionic?
Kevin: The future of GWT and JSInterop is interesting but it has a minor effect. First with the use of UiBInder and widget system: these features will be removed on GWT 3.0, I think. But for gwt-material, we will try our best to support it using JSInteropand Java 8 other features. For the last question, sorry but I don’t have any idea about Ionic.

Martin Hollerweger: Will Gwt-material switch fully to js-interopt?
Kevin: This will depends on the discussion with the community. If they want to switch fully to JSInterop then we will do it for them but in my opinion as a founder, it is good to have backup plans to anticipate the migration such as creating an old branch to backup the previous features that does not support JSInterop. Then, we will create a new branch for the JSInterop migration so that the user will have options if they want to switch their apps into JSInterop support or not.
Resources

Project shared
GWT Material repository – https://github.com/GwtMaterialDesign/gwt-material
GWT Material Addins – https://github.com/GwtMaterialDesign/gwt-material-addins
GWT Material Themes – https://github.com/GwtMaterialDesign/gwt-material-themes
GWT Material Showcase – https://github.com/GwtMaterialDesign/gwt-material-demo
GWT Material Phonegap – https://github.com/GwtMaterialDesign/gwt-material-phonegap
Google Plus Page – https://plus.google.com/communities/108005250093449814286
Contributing Guide – https://github.com/GwtMaterialDesign/gwt-material/wiki/Contributing

4 Rules of Simple UI Components

Too often have I seen simple web applications become a huge pile of intertwined, indecipherable JavaScript code. As features are added, code is added into seemingly random files, event listeners are accidentally duplicated, jQuery selectors stop working because someone moved the DOM around one too many times and sooner or later you start to feel the consequences.

It fails randomly.
It breaks in strange places.
It has regression bugs.
And no one wants to change it (for fear that it will become their code!).

Chaos and pain ensues. From my experience, the code becomes complicated way before the interface becomes complex. I know very few truly complex user interfaces, but the internet I browse is an endless stream of complicated JavaScript code. Sometimes, I look at the source code just to amuse myself. Sometimes, I even do so before applying for a job. Uh oh.

How did the web become a breeding ground for both simple interfaces and complicated code? To make things worse, this complicated code is located in a codebase that changes all the time! It is very hard to get an interface right in a one swift commit. It requires successive refinement based on customer feedback. Although this code changes all the time, it is often the hardest part to maintain.

Maybe it is our infatuation for cool new JavaScript frameworks that led us astray, but we seem to have lost basic software craftsmanship practices.

Corey Haines wrote an awesome book called Understanding the Four Rules of Simple Design based on Kent Beck’s 4 rules of simple design, which I highly recommend. Inspired by this book, I tried to distill UI complexity and found 4 rules of simple UI components that should help us write better, simpler interfaces. This is nothing new, but somehow it seems to have been forgotten along the way.

Rule #1: Break it down into named components

Thou shalt not underestimate the power of good naming

Break it down into named components

This is the simplest, yet most powerful rule of software design. Whether it is to discuss with the client or to understand each other when saying “the thingy” broke, good naming has the virtue of bringing people together. Picking a good name today might even help your colleague better decouple code in 6 months. This is what Corey Haines calls behavior attractors in his book. It is easier to see where your new code should go when things are properly named.

For UI design, this boils down to sitting with the client and figuring out a name for each thing. What is this portion of the page called? This new kind of input, what should we call it? Name small things, agglomerate them, then name bigger things! If you want, you can follow principles from Brad Frost’s atomic design, which is a good starting point. Instead of saying “the blue bar in the viewer thingy is overlapping with the other side”, you could say that “the document toolbar in the patient history viewer is overlapping with the annotation explorer“. Once the vocabulary is agreed upon, this makes your code less prone to bugs and misunderstandings with the customers.

In order to name components, you must break them down to a manageable size. If not, you maybe end up with names that include multiple “and’s” or end with “Util”. Be careful to name components according to their level of abstraction. If you name something “Intervention Plan”, I expect it to be high level and be broken down into smaller components. Maybe an “Intervention Plan” is made up of “Observations” and “Directives”. Maybe “Observations” is made from an “Action Bar” and an “Observations Grid”. Notice how “Observations” and “Observation Grid” differ in their level of abstraction, this is important.

If you need to spark your imagination, I suggest you read this article from J.B. Rainsberger.

Rule #2: Do not assume your context

Thou shalt not care to know who thy DOM parent is

Do not assume your context

Now that you have components of decent sizes and with good names (don’t worry, this takes time to master), you might realize that there are far more opportunities for reusability than you ever envisioned. Read the remainder of this article to be ready for this!

DRY (don’t repeat yourself) is a good principle to adhere to, but components are not reusable by default; they must be made that way. The first thing you must be careful about is to make your components as context-agnostic as possible. After all, how reusable can a component be if it requires a specific context? Picture 40 components requiring 40 different contexts. Are you crying yet? If not, just know that in most cases, those contexts are neither obvious nor documented.

Do not worry, there is a simple way to prevent this! First of all, simply do not make use of your DOM parents or siblings! Imagine your components as having a “root” DOM node. You are not allowed to go upwards in the DOM past this point. Until web components are finalized and included in all major browsers, you may have to use discipline not to cross this boundary, but this can be done!

Now, this raises the question: how can we update a sibling or parent component? Think about it. It is OK for the parent to know about its immediate children, but a child should not know about its parent, yet it has to send a message to its parent. What pattern comes to mind?

There are a few acceptable solutions here, but one that is childishly easy to implement in JavaScript is an observer pattern. Call it observer or listener, for our purposes it serves the same goal: the child exposes a couple of listening points (say, onError, onNewDirective) and the parent registers a callback for it. Now you get components that do not need to know where they are included in the DOM or where in the DOM is the component they need to update. Awesome!

Rule #3: Give complete privacy to your children

Thou shalt not covet thy children’s DOM

Give complete privacy to your children

So far, we have named components that can be included anywhere in the DOM. Okily dokily! This is all fine and dandy, but chances are you will need components that are made from other lower level components (again, refer to atomic design for inspiration here!). That’s a good thing, but there is one strict rule: do not query your children’s DOM! I mean it. This is where most ripple effects start! You change one thing in that observations grid and somehow you end up breaking something else without noticing it. Or you do notice it and spend the next hour fixing all those places where they used that CSS class you just removed. Ouch!

This is fairly easy to avoid. However, as I said before, until web components are finalized, you may need to do this out of discipline. The reward you get in return is very high.

We now have clear boundaries for what a component can and cannot do. You are not allowed to explore the DOM upwards past your root node and you are not allowed to drill down in the DOM past your children’s root nodes.

This is nothing new. This is what encapsulation is all about! This concept has been around for as long as most of us can remember, yet we sometimes forget the consequences of not respecting encapsulation. Let the action toolbar know whether buttons are arranged with an <li> or a <div>. Instead, just call .addButton(myButton) on it. Do not interfere with the action toolbar’s affairs and let it handle its own buttons: it is its job! Now you have no reason to have duplicated jQuery selectors! All ripple effects from changing the DOM structure should now be contained within the boundaries of the component that manages it.

Oh, one last thing before one of you tries to hack this! Creating a method .getButtonElement() is not the way to go! Remember Tell, Don’t Ask? If you communicate with your parents using events, you communicate with your children using plain old message passing (i.e. method calls).

Rule #4: See the world from what you are given

Thou shalt assuage with what hast been given

See the world from what you are given

This is not a rule specific to UI components, but it is of crucial importance in JavaScript. Mainly this is aimed at all of you still using global variables everywhere, I hope you hit your toe on some piece of furniture!

You could state the rule this way: if a component requires a certain object to complete its work, it should be explicitly given to it. The only exception to this is if it is your responsibility to create said object. Since you have good names, it should now be obvious whether or not it is this component’s job to create the object. Just keep in mind that the factory pattern exists and is easily achieved in JavaScript.

Luckily, this is easily fixed in most codebases. Remember that your goal when refactoring is to work in small increments and keep the tests passing (you have tests, right?). If a component uses a global variable, just turn it into a method or constructor parameter instead. Then, whoever uses that component just passes in the global variable. Now fix those higher level components too. Rinse and repeat until you find the point of origin, then make an educated decision about where the object should reside.

This may seem complicated, but it is not. Now your components have explicit dependencies instead of requiring an implicit context. You improved the readability and reusability of your code, you should be proud! You will thank yourself in six months time.

As an added bonus, you just got rid of global variables which are a nightmare once you add concurrency. So far, JavaScript has been single threaded, but this will change. Better be ready than sorry!

What you should take home from all this

It sounds simple, doesn’t it? It should. Find good names, use events to decouple from your parents, delegate to your children and respect encapsulation, and make dependencies explicit. That’s it! This is not new nor ground breaking, but it should get you started on an happier path. Most of these principles are simply based on known best practices like SOLID principles or atomic design and none of this is web-specific. User interfaces have been around for ages and I think web developers should read more about the accumulated knowledge drawn from these years of experience.

The even better news is that it is fairly easy and fast to go from a humongous entangled to a structure of well defined and well behaved components. It is out of the scope of this article, but I might write about this at a later time. I will also show how to do it at my conference for Agile Québec on January 20th (in French). In the meantime, you can see a working example of this on my github repository. You will find 3 examples: one is a huge JavaScript file, one is a rewrite using React and the last one is a rewrite using only RequireJS.

Oh, also, here is one last bonus for you! You now have components that are trivial to test! Try it out, you might be amazed.

GWTP Typed Slots

This article discusses the different slots available in GWTP and different use cases for each of them. All examples and code snippets are taken from the BeeStore source code, also available here.

Post_GWTP_Howto_Typed Slots_v1-02

What are slots?

In GWTP, slots are a feature that facilitate the creation of a hierarchy between presenters. They allow you to nest presenters into each other, allowing for child and parent presenters. A presenter is defined as a “child” when it is “set” into the slot of another presenter. Inversely, a “parent” presenter is defined when a child presenter is set into its slot. Such nesting can be useful when, for example, you want to include a widget into an existing presenter, or even when you want a whole presenter to be the child of another.

How to use them

To use a slot, it must first be declared in the presenter defined as its “parent”. Once you’ve chosen the best slot type for your use case (more on this later), you declare it like so:

public static final SingleSlot SLOT_SIDE_PANEL = new SingleSlot();

Then, assuming you have injected the presenter that will be “child” to the current presenter, you call the setInSlot(SLOT_SIDE_PANEL, sidePanelPresenter) method. This method will make the sidePanelPresenter a child of the current presenter. Alternatively, you can call addToSlot(SLOT, presenter) to append a child to the current children of a presenter. However, make sure that you’ve declared a slot that takes multiple presenters as children.

To display the presenter, a container must be declared. Inside the parent presenter’s view, we declare a field that will act as the container: @UiField ReplacePanel sidePanelContainer. Finally, we call bindSlot(ApplicationPresenter.SLOT_SIDE_PANEL, sidePanelContainer) from the parent’s view constructor.

Multiple Slots in a Presenter

There’s no restriction to the number of slots you can declare in a presenter. You can also declare slots with different types without problem. For instance, take a look at the ApplicationPresenter available slots:

Slot Types

GWTP now provides different types of slots for different uses. The generic Slot is still usable, however you can now choose a slot that is more adapted to a specific situation.

SingleSlot

This slot can only take one presenter. This is useful when you want to reserve the slot for specific presenter. For example, this slot is declared in ProductPresenter. The slot is for the PricePresenter which holds the product name and price of a specific item for sale.

static SingleSlot SLOT_PRICE = new SingleSlot<>();

The slot is package-private so it can be accessed by the ProductView but not externally. Calling getChild(SLOT) will return the child presenter.

PermanentSlot

A PermanentSlot is the same as a SingleSlot, the only difference being that once a presenter is added, it can never be removed. This means that getChild(SLOT) will never return null. We used a PermanentSlot for the CartItemsPresenter which holds individual cart items.

public static final PermanentSlot SLOT_CART_ITEMS = new PermanentSlot<>();

Here we’ve chosen the PermanentSlot instead of the SingleSlot because we don’t want the presenter containing the client’s order to be removed.

NestedSlot

This slot is the same as the SingleSlot but it can only take presenters with a proxy. This means that you can’t use PresenterWidgets with this type of slot because they don’t use proxies. In the BeeStore, this slot is used on the ApplicationPresenter which is the root presenter for the application. The NestedSlot is used here so that HomePresenter can be nested into it.

public static final NestedSlot SLOT_MAIN = new NestedSlot();

Other presenters also use this slot such as the ProductPresenter and the NotFoundPresenter.

Slot

This slot is the most permissive of all. It can contain multiple presenters or presenter widgets. You can call getChildren(SLOT) to see which presenters it contains. For instance, this slot is used on the home page of the BeeStore to display the products.

static Slot SLOT_MAIN_PRODUCTS = new Slot<>();

Each product has its own presenter widget created from a factory. Then the widgets are added to the slot on the onBind() method:

A note on Typed Slots

When you need to add different types of presenters to a Slot, you can declare a slot without specifying a generic type. For example, let’s take a look at the SidePanelPresenter:

static Slot SLOT_MAIN = new Slot();

If you need to know what presenters the slot contains, you can call getChildren() which will return a set of all child presenters associated with the slot.

Conclusion

Now that you’ve seen how great slots are for nesting presenters into each other, you can start experimenting with every one of them. Don’t hesitate to take a deeper look at the BeeStore source code, and star the repository if you appreciate it. We did it for you guys!

Feel free to leave feedback or comments in the comment section below.

Live GWT Q&A with Mark Kevin Baldemor on GWT Material on January 19th

We are pleased to announce that we are going to hold our January live Q&A on January the 19th with the founder of Gwt-Material Project, Mark Kevin Baldemor. He is very involved in the community and he will talk about the GWT Material project.

A bit of information about our guest for this month:

“I am currently staying at the northern part of the Philippines with lots of beautiful scenic spots which leads my development life into peaceful and exciting work condition. I tried to help the gwt community and my current company to build rich web / mobile applications with the help of Google Material Design UI / UX specifications which improve the gwt developers productivity. With 3 years expertise on gwt development, I experienced the copy pasting of styles from one project to another, so I decided to create an Open source project api for Front End Framework with the help of Materializecss bringing Material Design to Web Application development with Rich UI / UX and Meaningful Animations.”

Mark Kevin Baldemor

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Code Splitting for Non-Presenters in GWTP

One of the interesting features in GWT is Code Splitting. It allows you to load part of your application only when it is needed. This reduces your app’s loading time and makes for a better user experience.

What is a split point?

Code splitting allows you to separate your code in multiple fragments (more specifically, in multiple JavaScript files). Each location where you choose to separate your code is called a split point. If you want an analogy, each split point is like a door for the content behind it. The main advantage (other than a faster initial loading time) is if a user never accesses some heavy part of your app that is less often used, the total download that the user requires to navigate your app is also reduced.

ProxyCodeSplit

In GWTP, when you want to put one of your Presenters behind a split point, you can use the @ProxyCodeSplit annotation to do it.

ProxyCodeSplitBundle

Sometimes, you want to group some Presenters (“bundle” them) behind a split point. That way, they will be grouped in a unique JavaScript file, which is sometimes more time-efficient than multiple files.

The first thing that you have to do is create an interface with the names of your different bundles, and use the @ProxyCodeSplitBundle annotation. GWT Code Generation will kick off and generate all that you need to separate the Presenters as you wish.

For example, you can write your interface like as follows (taken from Arcbees’ website) :

You can then use the annotation on your Proxy and the name of the bundle you want your Presenter to be in :

Bundles for Non-Presenters

A question that we get quite often these days is how to use this annotation function for Java classes that are not Presenters. These annotations are tailored for Presenters, but not for other use cases.

Suppose we want to bundle two services (FirstService and SecondService) behind a split point. We will have to first create a concrete class for our bundle.

We now have access, via our getters, to each of our services.

Now, if we want to use these services, we can inject the MyBundle class with AsyncProvider (this is necessary for GWT to do its code splitting).

You can now retrieve your service (the best practice is in the onBind() function if you are in a Presenter) this way :

I hope this article helped you understand how split points work, in particular with the non-Presenter bundles. Don’t forget to subscribe to our newsletter if you want more articles like this.

Live Q&A session with Brandon Donnelson on GWT Plugin for Eclipse on December 10th

We are pleased to announce that we are going to hold our december live Q&A with Brandon Donnelson on December 10th.

Brandon will be our guest for this one and he will talk about the Eclipse Plugin for GWT. This Q&A is a great opportunity to learn more about Brandon and the Plugin.

He is really involved in the GWT Community and if you don’t know him, it’s a great occasion to discover who he is. A bit of information about our guest for this month:

  • Brandon is a GXT Support Engineer for Sencha and here is his bio: “I live in Arlington Washington on a small farm with my lovely wife and 5 kids. We’ve got a llama, couple alpacas, some goats and chickens. I enjoy working with the GWT and I like helping others use it for application development. Often in my spare time I’m working on things that help others.”

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Styling Chosen

Using libraries like Chosen is a good way to simplify your code. Otherwise difficult tasks can be completed in a matter of seconds. The main problem we find with libraries though is that their default styles almost never blend well with our own designs, in terms off color, size, shape or something else. Following up on Olivier’s blogpost about how to set up and use Chosen, we will try to fix that styling problem, step by step. If you prefer to read some code instead, have a look at the final application repository.

The basics

Styling Chosen can be achieved by overwritting some classes or simply providing a new stylesheet.

As shown in the default resources file for Chosen, there are 3 stylesheets that can be easily swapped to match your needs :

Chosen also uses a set of icons that you can change, to uzs GSSS Mixins instead.

Changing colors

Creating a custom stylesheet

In this first example, we will create a dark style for Chosen.

Screen Shot 2015-11-03 at 2.37.22 PM

We will copy the default colors.gss, create a new file with it in the CSS resources folder of our project, and call it chosenDarkColors.gss. We will fine tune the colors later, but to be sure that we are loading the new stylesheet, we should change at least one variable. Giving the #000 value for the CHZN_C_PRIMARY variable will do the trick.

Don’t forget to keep the @provide 'chosen-color';, otherwise it will crash.

Creating the associated resources file

In order to make our Chosen widgets use the new colors, we need to provide the widgets with a resources file that will make use of this new stylesheet, instead of the default one.

We only need to mimic the default resources file for Chosen, swapping the color.gss for the one we created, and providing the default files for the rest, using relative paths.

This new resources file then need to be loaded in the application via the ResourceLoader.

Loading the custom style

Now that we have our custom stylesheet and it is loaded into the application, it’s time to tell our Chosen widgets how to use all of this.

In the view file where the widgets are declared (HomeView.java in this example), we will start by creating a variable containing the link to the newly created resource. Then, we will create the ChosenOptions object for our widgets (if it’s not already done) and pass it the new resources. And that’s it!

Go ahead and style! The hardest part – and I can’t help you with this – is choosing the right combinations of colors!

Changing the default style

You can use the same process seen previously in Changing colors to change anything defined in chosen.gss and mobile.gss.  Even better, you can overwrite only the part you want, so you don’t have to duplicate the whole stylesheet.

Conclusion

Styling Chosen is not that hard, in fact it can even be fun! I created an open project on Github with the completed dark style that we started working on (it is an example of the custom stylesheet approach) and, as a bonus, were are including a second color scheme called Unicorn style (you will have to run the application to see it in action).

Have fun styling!

Testing GWTP applications with Jukito – Introduction to Jukito

In this second post of the Testing GWTP applications with Jukito, we present : Jukito!

The purpose of this post is to show the basics of Jukito, and to show what are the advantages for you and for your project.

What is Jukito?

Jukito is a Java library that allows you to reduce the amount of code to write when testing code that is written using dependency injection. Typically, people use Mockito to mock their dependencies and it ends up being cumbersome. Jukito creates mocks for you for all the injected dependencies.

Here is an example made with Mockito and an example done with Jukito.

As you can see, the only differences with the two snippets, are:

  • With jukito you don’t have to call the class under test’s constructor
  • The annotation used to mock dependencies is @Inject instead of @Mock
  • The TestRunner annotation changed

At first, it doesn’t look like a big deal, but when the code base grows, things can get out of control. For example, imagine that we want to add a new dependency to the Endpoint class and inject it via constructor.

With Mockito, this kind of change will produce a compilation error. On the other hand, with Jukito, everything still compiles fine, since the call site doesn’t change.

OK, what now?

Jukito uses Google Guice and Mockito behind the scenes. However, even if you’re not using Guice, you can still use Jukito. The only requirement to use Jukito is to use Java’s standard annotation @Inject on your class’ constructor.

Everything that is possible in a Guice Module can also be done in a Jukito module.

Example

Let’s say you have an interface called UserInformationService. You could have a test that uses a fake implementation, another test that uses the real implementation and another test that uses a mock implementation. By default, Jukito injects Mockito mocks, but it is also possible to bind the interface to whatever implementation you want. To do so, we have to declare a Jukito module in the test class, and setup things there.

There is another cool use case for Jukito and Guice. A lot of Java code use factories. Guice has the ability to generate a factory implementation from an interface. We can either inject a mock factory or create a real factory with a binding in the Jukito module.

The first case would be to inject a mock factory as in the second gist, where we used Jukito.

We had to change the code a little bit here so that the factory would be managed by Guice. As you can see, the scope of the test is a little bit wider. The test verify that the endpoint returns the correct status code.

There is no best solution, it mostly depends on the level of integration you want your test to have. In the first, the response would be the one that you crafted yourself, whereas in the second, the response returned by theResponseFactory would be the same as in production.

Conclusion

In summary, Jukito is a library that does whatever is possible with Mockito and Guice. When writing big projects, it can really help scaling the code base and all its tests.

It is even more useful in a context like a GWTP application, where :

  • Almost all components use dependency injection
  • GWTP uses GIN (which is Guice for GWT)
  • Testing interactions is very natural. Therefore using mocks for testing and driving the design is also natural

Hopefully, this post gave just enough information to understand the upcoming examples about testing GWT components, like Presenters.