Hello, community! We would like to announce Liferay Push, our new framework for sending push notifications from Liferay Portal to your mobile apps.

Push notifications is a technology that allows servers to broadcast messages to mobile devices. Instead of having your app poll the server for new messages every few seconds (that drains your phone battery and your monthly data plan!), your app can just wait for notifications from the server. Your app will be notified even when it's not running, the system will wake it up.

Engaging your audience

Say you've developed your own company newsletter portlet and its corresponding mobile app for your customers. You can use Liferay Push to notify users on their mobile devices whenever a new post is published. That way your users will always be up-to-date without ever needing to open their app and refresh it.

Push notifications are usually associated with the notifications you receive on your phone notifications center but push notifications offer much more than that. With Liferay Push you can update the content on your apps or update its local database as change happen.

Currently, Liferay Push supports two push notification providers: Google and Apple. However, Liferay Push can be extended to support more platforms as needed. Liferay Push allows each user to register one or more devices. Liferay Push will query for the registered devices, identify if the user is using an Android or iOS device and send the notification to the right provider. Notifications can be sent to one or many users.

How does it work?

Here are some diagrams that explain how Liferay Push works:

Your phone app must register the user’s device to the portal.

2. Once a user’s devices are registered, your portlet or plugin can send notifications to them.

Liferay Push provides both server side and client side APIs (Android and iOS). It will help to get up to speed and make it easier to support push notifications in your apps.

At Liferay, we have a team of engineers focused on developing native mobile apps and we've learned a lot during the development of these apps. We thought it was time for us to share our knowledge with our community.

We know it is pretty easy to consume Liferay's RESTful web services, however, there are some nuances that can be trickier if it's the first time you're trying to develop a mobile app that accesses them.

Our Liferay Mobile SDK makes it easier to create mobile apps that are connected to Liferay portals, it takes care of authentication, services discovery, JSON parsing and server error handling for you. It hides complexity from the developer and almost feels like you are making local service calls from a plugin.

For those developers who are used to our Service Builder, the Mobile SDK can be seen as a client side code generator. For each new Liferay Portal version we release, we will be releasing a new Mobile SDK version that you can use to consume portal core services.

Since the SDK is auto-generated, it also means that you can generate client side code for your custom portlet services as well.

Right now we support iOS and Android, but this is only the beginning: we have plans to include support for more platforms in the future!

Say for example you want to develop an Android app that displays the latest blogs posts from your portal instance, that's how you would do with the Mobile SDK:

While you are online, navigating through folders, Sync caches the structure and let you continue to navigate if your internet connection goes down later on. For example, if you are on a plane with no connection, you can still view those important documents that were previously downloaded.

Sync is also making less and smarter requests which improves the overall user experience, it feels like you are accessing local files.

Give it a try and let us know how it goes, don't hesitate to contact me if you run into problems!

On Oct. 27 we held our first roadshow in South America, this event was sponsored by our partner SEA Tecnologia.

We got surprised by the success of this event, there were about 50 attendees, among clients, partners and people willing to learn more about Liferay.

It was as great opportunity to talk about Liferay, meeting people we knew only virtually and learn about how our clients have been using Liferay.

During the morning, Clédiston, from SEA, introduced Liferay and explained how SEA has been implementing portals. Afterwards, Thiago presented all great new features of Liferay 6, Eduardo came after that, demoing Alloy, our JavaScript framework. The ease of using Alloy to build rich internet applications was the most interesting part of his demo.

The afternoon was occupied by our customers, IBGE and CFA which made great presentations, we happily learned how helpful Liferay has been to them. SEA also talked about portal design best practices and what they have learned during this time.

We would like to thank SEA for its support and sponsorship of this event, we are also very grateful to those who attended. The success of this roadshow was so great that we're already planning a second one, this time in Rio de Janeiro later this month along with our partner Vertigo, stay tuned for details in our forums!

Suppose that you, a portlet developer, need to develop a FAQ portlet that displays questions and answers and that allows certain users to create/update/delete FAQ entries, i.e., a simple CRUD application. Usually, the first thing that comes in mind is to implement a new Java-based portlet, actually, 2 portlets, one for displaying and a second for managing FAQ entries. Fortunately, Ray Augé showed me a different approach, there are some simple cases that can be solved only by using our Web Content framework, this way, each FAQ entry becomes a Web Content entry and for displaying them you can just create a Web Content Template containing a Velocity script.

The ability to create Velocity scripts has been in the portal for a long time but we made some enhancements for 5.3 that will make it easier to build such scripts. Note that some APIs used in this blog post are still in development and will be available only in 5.3. You can download all templates and structures used in this example here.

Portlet example built with Liferay WCM

Here's a screenshot of this portlet in action:

Each pair of question and answers are Web Content entries, and the template responsible for listing them is located at /templates/FAQ-PORTLET.vm in the zip file.

There are many advantages of building CRUD applications with Liferay WCM, as a developer you don't need to care implementing many features provided by Liferay WCM for free, such as:

1.Creation, update and deletion of FAQ entries: since each FAQ entry is actually a Web Content entry, you can manage them from the Web Content portlet:

To edit an entry, you just need to fill the form, notice the category select box, FAQ-PORTLET.vm will filter entries accordingly:

FAQ entries could have other complex field types, such as images, files or any type available in Structures.

2. Versioning: you can have several versions of the same FAQ entry, you can see the history of changes and rollback to older versions if needed, just like any Web Content.

3. Approval workflow: content of each entry can be revised and approved by editors, FAQ entries will be displayed only when they are approved.

5. Export/import: you can backup or share FAQ entries with others by exporting and importing them to .lar files.

6. Staging and remote publishing: you can create FAQ entries in the staging community and publish them to the live community when they are ready, they can be also published to a remote Liferay instance.

7. Permissioning: you can define which FAQ entries an user will have permission to view.

7. Setup: Since the portlet that displays all FAQ entries is a Web Content itself with an associated Structure, you can take advantage of this to configure your portlet, in this example, there is a "show_index" option that will display or hide the questions index:

What's new in 5.3?

You might be thinking "OK, there is nothing new here, I know how to create Velocity templates and call Liferay services from them, what's new in 5.3?"

One of the problems we've found while creating these applications is that we can't query for Web Content fields separately. In the example, I needed to filter FAQ entries by their category field, however Web Contents are stored in the database like that:

As you can see, it would be hard to make a database query and fetch all FAQ entries associated to the "EE Edition" category, the table is not normalized. We fixed that by indexing Web Content fields separately in Lucene, now you have new options while creating a new Structure, you can define that a field will be indexed as a Keyword or Text by Lucene or won't be indexed at all:

Advantages of creating CRUD applications with Liferay WCM

Faster coding, no need to deploy .wars, you can dynamically edit and save your velocity script, you'll see your changes right away.

Small footprint, it's not a regular portlet with tons of jars consuming memory, it will take longer processing the script but this can be avoided by caching entries.

You get all Liferay WCM features for free as I mentioned above, you just need to code a velocity script for displaying entries.

Drawbacks

Velocity scripts are harder to debug.

You can't instantiate Java objects, creation of objects can only be made by calling factories and static methods.

If your application has many views or many actions can be performed, your script will become very big, making it harder to maintain. You can't add business logic, there is no data validation.

Plans

There are many other useful applications that can be built with Liferay WCM, one that I can think of is Jobs Listing app, we'd like to hear from you which other apps could be useful.

Templates can be easily shared, we are planning to create a new type of plugin, something like a "Webscript" plugin type, a bundle would be basically a .lar file containing templates and structures that we could publish through our plugin installer portlet.

The new release brings some cool new features for the Web Content portlet (previously known as Journal portlet), here are some of them:

1. Repeatable Structure fields

Sometimes, while creating a Structure, we can't predict how many fields of a certain type a Web Content entry will need. Now, for each row in a Structure, there is a Repeatable check box:

If I check this checkbox, I can add as many "repeatable-field" as I want while creating my Web Content entry, I just need to click on the plus icon:

Here's the template that I created to list all "repeatable-field", to get all the values I just need to call $repeatable-field.getSiblings() and iterate over them:

And here's the result:

2. Print feature

Go to Web Content Display configuration, click on "Enable Print", a printer icon will appear just below the Web Content Display portlet, when you click on the printer icon, a pop-up shows up the content in a printer-friendly version. But before that, the template being used needs something like:

We have this feature for a long time for Wiki and Document Library, we extended it so Web Content entries can be also converted to these formats, you just need to enable OpenOffice integration following this steps:

We've made some enhancements to the search infrastructure of the portal recently. We abstracted out Lucene as a search engine, now people can build plugins that integrate with others search engines frameworks.

For example, it's possible to replace Lucene with Solr, FAST and Google Search Appliance as long as a plugin is developed to interface with them.

Currently the only plugin developed is one for Solr, the Lucene plugin is the default implementation and comes bundled with the portal.

Roughly speaking, Solr is an application that listens for indexing and searching commands via HTTP requests. You can deploy Liferay in one server and have Solr running in a different server, this is very helpful for clustered portals because we got rid of racing issues when Lucene JDBC was used. Also, you can have a cluster of Solr instances that does load balancing of requests.

This works with Liferay 5.1.1, for more information about installing and running this plugin check these wiki pages:

I always thought that it would be very nice if we could compare text files in the document library portlet, just like we developers do with different versions of source code. I finally implemented this diff tool and had a lot of fun!

For the first time I think I've made something similar to test-driven development and it'd proven to be very useful for this kind of algorithm in which a small change can break something else that you didn't know it was related.

You can also compare other file types besides .txt, like .doc, .odt or .html. Thanks to the OpenOffice integration we made some weeks ago.

Some aesthetic changes need to be done, as Jorge advised me, Wikimedia's way of choosing different versions is better, it has two columns of radio buttons instead of one column of checkboxes. The way the differences are shown also needs to get better, suggestions please.