The “New Build System”

Entering the “New Build System” based on Gradle. The new build system is supposed to become the official mechanism for building Android applications. The gradle-based build combines some of the strengths of ant and maven (flexible architecture with a lot of custom tweaking opportunities), whilst at the same time providing reasonable default configurations to keep the build scripts small. Maven dependencies can be consumed from maven central, while it is also easy to consume “local file” dependencies.

Okay, but how does the “New Build System” prevail in practice?

Using the Gradle Android Build

DISCLAIMER: We are only a few days away from Google IO 2013 so the points raised here might have already changed when you read this.

Basic build scripts can be really really small when you rely on the default folder structure for your project. Your basic gradle build script can look like this:

buildscript {
  repositories {
    mavenCentral()
  }
 
  dependencies {
    classpath 'com.android.tools.build:gradle:0.3'
  }
}
 
apply plugin: 'android'

In fact the buildscript{} element is only required to bootstrap the script itself. The actual content is the lonely apply plugin: 'android'. Running this script produces a fully runnable unsigned apk.

The basics are simple but what about dependencies? As I mentioned, you can easily add dependencies from maven central or a local file. In fact, the buildscript downloads its own android tasks from maven central.

repositories {
    mavenCentral()
}
 
dependencies {
    compile 'com.google.guava:guava:11.0.2'
    compile files ('libs/gcm.jar')
}

The compile directive is similar to mavens compile scope in that the dependency will be bundled into your packaged .apk.

Gradle also supports Android library projects. The “New Build System” compiles library projects into .aar packages, which can be consumed by the main project. The main advantage of the .aar format is its ability to handle dynamic Android resource ids. You will be able to ship an *.aar archive and consume it in your main project without having to create all of its ids during compile time of the main project.

Library projects have to be listed in a settings.gradle file and all projects taking part in the build can reference any other project listed in that file.

Where the gradle build has its real strength is in creating multiple versions of the same app. For example, a free and a paid version, or different versions for various cpu architectures. I won’t go into detail but you should read all about it here.

Shortcomings

Now that we have discussed some of the strengths of the gradle build system, lets discuss some of the pitfalls:

The gradle build is not yet able to deal with the most common dependency format for library projects: the maven apklib. Currently you can only consume maven artifacts that are packaged as jars. This rules out a lot of high profile dependencies such as the actionbarsherlock or the viewpagerindicator. If you want to depend on these resources you will have to keep a source reference in your project (or package them as an .aar).

The gradle build system offers good support for instrumentation tests you run on your device, but it is currently very hard to run standalone robolectric tests. The main problem is that robolectric does not understand the gradle dependencies so that it cannot gather sub-dependencies, and so on.

Support for the Android Development Tools (ADT) is currently non-existent although this is very likely to change with future releases. The ADT cannot deal with the default folder layout by gradle, nor can it deal with declared dependencies. Therefore, you have to maintain two build infrastructures: one for Eclipse (project.properties etc) and one for the gradle build.

Wrap Up

The “New Build System” build sounds awesome! As long as it can deliver on all its promises. At the moment, I can not recommend it for larger projects due to the lack of robolectric support and problems with maven dependencies.  I have discussed the issues raised here with +Xavier Ducrohet, the lead architect of the build system, and he assured me that most of the issues will be addressed. At the Droidcon Berlin I spoke to Hans Dockter, the CEO of Gradleware and co-architect of the “New Build System”, and once gradle becomes the driving engine for the ADT the entire toolchain should be covered. If the Android library ecosystem were to adapt gradle, it would have a very bright future.

Tabris sits on top of Eclipse RAP. RAP provides a UI Toolkit to write Web applications using Java. This UI Toolkit is based on Widgets, so you don’t have to mess around with HTML. To be able to display those widgets in a browser, RAP uses a protocol which is based on JSON. Within this protocol are messages that instruct the browser e.g. to display a button, or a tree, and so on. What Tabris does is to provide two alternative clients which are an iOS and an Android client. Those clients simply understand the RAP protocol messages and display widgets using the native counterparts.

On April 28th, 2010 we have previewed a version of the RAP protocol which basically marked the start of Tabris internally. Two months later (June 11th, 2010), we had the first working prototype which has used Apple’s iAd JavaScript framework for rendering. Since then we have worked on what is today released as Tabris. It includes two native clients and an extension of the server side RAP API. This extension, which is just another jar, is necessary because the RAP API is based on the Standard Widget Toolkit (SWT). SWT is limited when it is used on mobile devices. There are no APIs for Geolocation, Camera and other things a mobile App typically use.

The first time we made our mobile clients public was the start of our “developer preview” back in January 31st, 2012. At this time we concentrated on implementing a proper support for the SWT widgets. Since then, we have released 14 milestones. The last public milestone was tagged with 0.11.0. We think that this was the most important one for Tabris. It introduced a feature called the Tabris UI. Tabris UI is a higher level API for creating a frame for your mobile application. The native clients use native navigation concepts to display a Tabris UI-based application. On Android this is the ActionBar and on iOS these are the ViewControllers. So, since Tabris 0.11.0 it has been possible to write native applications using native Widgets combined with native navigation concepts.

In the last weeks we have concentrated on Bug fixing and API cleanup to ship a release we can be proud of. If you would like to try out Tabris yourself, just download the 30 day trial version. This trial has no functional limitations! To get started with this trial we have created some detailed getting started guides you can use. We have also created a bunch of screencasts that show some of the features Tabris provides. You can find the new & noteworthy articles so far below:

• Tabris 0.5.3
• Tabris 0.5.4
• Tabris 0.5.5
• Tabris 0.5.6
• Tabris 0.5.7
• Tabris 0.5.8
• Tabris 0.6.0
• Tabris 0.6.1
• Tabris 0.6.2
• Tabris 0.7.0
• Tabris 0.8.0
• Tabris 0.9.0
• Tabris 0.10.0
• Tabris 0.11.0

At this point I want to thank the community which has provided us with great feedback, feature requests and bug reports. I also want to thank the rest of the Tabris team: Jordi Böhme López, Johannes Eickhold, Moritz Post and Ivan Furnadjiev for doing a great job over the last year! And last but not least, many thanks to the Eclipse RAP team for their great support!

Run your server side application on mobile devices and benefit from the native features of your platform. Use the Tabris UI, swipe widget, native video and much more.

See you soon.

Background

Almost a year ago we released our first public milestone (back then Tabris was RAP mobile). Since then we have worked hard towards the Tabris 1.0 release. The basic idea behind Tabris was always to use the SWT Java API to create UIs for mobile devices. This idea hasn’t changed much. Since the first milestone Tabris has had many adopters and we’ve received a lot of good feedback. One topic that especially got us thinking was stated as follows: “Tabris is nice and SWT allows me to create a rich UI. But, it doesn’t allow me to use common navigation concepts”. Said another way, the problem for developers is that each platform has it’s own navigation concepts. For Android this is the ActionBar and for iOS it is the View Controllers as highlighted in the screenshot below.

With plain SWT it’s not possible to create a UI using those concepts and as result it was not possible with the early versions of Tabris either. Note here, that the operative word in the last sentence is “was” -  because, we have created a small UI framework on top of SWT that enables you to create UIs using native navigation concepts. This framework now forms the core of Tabris.

Abstraction

Tabris is a framework for cross-platform mobile apps. The basic concept of Tabris is that you write the UI in Java and it runs on the server. A device calls the server and renders your UI with native components. This means that when you create an SWT Button on iOS, an iOS button will be created and on Android, an Android button will be created. As a result, you can create applications with one code base that serves multiple platforms. This means that we can’t (and don’t want to) port the concepts of the different platforms to a server side API. We have to create an abstraction! That is, an encapsulation of the concepts of all platforms into a simple, understandable API.

This API is called “Tabris UI”. The key parts are two types, Page and Action. To make it clear what these types are we can take a look at another image.

The red shaded area of these images is the Page which basically contains your controls. In the green shaded boxes you can see two Actions. An Action is an element that a user can press (to activate) and which is located outside of the Page.

Concepts

Let’s look a little deeper into Pages and Actions. Pages can be chained together in any order. This means a user’s button click can be used to open a new page. When you do this multiple times a chain will be created. Within this chain you will be able to browse backward to the previous page . This concept is called page chaining. Every chain has a root element. This is what we call the “top level” page. One application can have multiple top level pages and all can mark the beginning of a chain. Let’s take a look at a diagram.

This diagram could represent almost any application. The usual flow of an application is that you start on a top level page and browse through several pages, going deeper into the application. As you can see on the image this is what we call chaining. But one top level page is not enough for most application. Think about a bookstore application. The possible top level pages are “All Books, Favorites, Popular Books”. Each top level page will contain another set of books you can browse through. So, when you have several top level pages you need to be able to browse from one top level page to another or to browse from a normal page to a top level page. This is shown with the red arrows on the diagram. What’s not possible is to navigate from one page in a chain to a page in another chain because only one chain can exist at any given time. The pages in a chain are created when they are visited and they will be destroyed when you navigate in reverse and leave them (e.g. when you jump back to the top level page or the previous page).

Actions have a lifecycle similar to Pages. Similar but not exactly the same. Two types of Actions exist. Global Actions and Page Actions. A Global Action is visible regardless of which page the user is on. Page-Actions exist only on a specific page. They are created when the page is created and will be destroyed when the page is destroyed. You can see the difference in the following screenshots. In these images the Global Action is shaded in green. It has application scope. The Page-Action is shaded red. It has page scope.

Programming Model

You will create Page and Action objects to enable the main functions of your applications. And, in most cases you will quickly reach a point where the components need to communicate. Of course, you can access a Page directly from within an Action but this is not good practice. We prefer a loosely coupled communication between components. This communication can be accomplished by using a context. In the Tabris UI it’s called a UI and you can use it for navigation and influencing the state of actions too. The key feature of the communication is that you can a data store from it. When I talk about a store think about a simple Map, encapsulated in the type PageData. A PageData object has the same lifecycle as a page. Each page has it’s own data, even top level pages. This is because you will need to pass data in your chain. You can navigate to a new page and pass in a PageData object which then marks the page store of the new page. Let’s take a look at another diagram.

As you might notice it shows the same page chain as above. What’s different is that it shows the new PageData objects that will be passed to a new page. In this data you can save page state information such as a selection.

Configuration

What we have not described in the preceding paragraphs is how the different components come together. This is all done via configuration. To be explicit the type that matters is called UIConfiguration. You will need to create an instance and add your Page configurations and Action configurations to it. What are Page and Action configurations? As the name says, they are the configurations of a Page or an Action. A Page doesn’t know anything about it’s title, if it’s a top level page or about it’s image. And this is the same for Actions. This information needs to be declared within a PageConfiguration or ActionConfiguration object. The diagram below shows how this works.

As you can see, the Tabris UI framework is responsible for creating Page and Action objects from the configuration. This also means that you will need to add Page or Action Class objects to it’s configuration. After you have created your configuration it can be passed in as a constructor argument into the TabrisUIEntryPointFactory object. As a result this needs to be added to an Application within your ApplicationConfiguration implementation.

Ready to use

Using everything described above, you can write powerful applications that will have a platform specific user experience. We have created an example for the Tabris UI. It’s the bookstore example mentioned earlier. You can see the flow of this app in the picture below.

You can look into this example on github. It’s licensed under the EPL 1.0, so feel free to use it as a starting point for your application.

Outlook

The current implementation is targeted for phones because only one page can be visible at a time. Of course it can be used on tablets too, but having only one page at a time on a tablet is not the way most Apps work. We are working on an enhancement on top of the Tabris UI to be able to define groups of pages that can be visible at the same time for tablet devices.

We hope you will enjoy using the Tabris UI as much as we do. For me, it’s a breakthrough feature for Tabris and for cross-platform development for mobile apps. As always, feel free to disagree .

SWT Menus

Menus were an often requested feature in Tabris. With this milestone we have implemented support for menus on phones and tablets. A common use case for menus is a long press on any item within the UI. We even support dynamic menu items, so you can add items while the menu is open and they will be rendered correctly on the client. Just a note that when creating a menu, the style flags will be ignored because menus on mobile devices don’t currently support styles.

ClientDevice

The ClientDevice type has existed for a while now to gather information on which platform is accessing the server. For this milestone we have enhanced this type to get even more information about the client. We also transformed it into a ClientService to make it accessible with RWT.getClient().getService( ClientDevice.class ). You can get the following information from the ClientDevice:

• Timezone Offset: An offset in minutes to UTC. This is inherited from the RWT type ClientInfo.
• Locales: The locale used on the accessing device. Also from ClientInfo
• Orientation: The orientation of the accessing device. Can be landscape or portrait.
• Capabilities: Information regarding the capabilities of the accessing device such as phone or location capabilities.
• ConnectionType: The connection type of the accessing device. Can be wifi or cellular.
• Platform: The platform of the accessing device. Can be Android, iOS or web.

Accessing this information is really easy. Check out the following snippet:

ClientDevice device = RWT.getClient().getService( ClientDevice.class );
Orientation orientation = device.getOrientation();

We have also created a demo showing the full feature set, hosted on github.

ClientStore

One of the biggest advantages of Tabris is that it doesn’t store any relevant data on the device. But, sometimes it would be good to have small amounts of data stored, such as the ID of a previously logged-in user. This is comparable to cookies for a web-browser. A website will never store big data in a cookie but small ID’s that associate it with a data set stored on the server-side. With the new ClientStore implementation you can do exactly this. A small amount of data is stored on the device and is transferred back to the server during the next session (but not with every request as with cookies). Using the store can look like this:

ClientStore store = RWT.getClient().getService( ClientStore.class );
store.add( "foo", "bar" );
String bar = store.get( "foo" );

Tabris UI

A huge issue for all cross-platform technologies for mobile devices is that you can’t build an app that uses the native navigation concepts. I mean you can try to emulate these concepts but you will end up with messy code because you need to differentiate for each of the platforms. From my point of view this is also the biggest drawback of HTML5. In Tabris 0.11.0 we have created an abstraction for these navigation concepts. This enables you to create your application once and our client implementations will render it in a way typical for the platform it runs on. To make this clear we have created a “Bookstore” example which can be found on github. The following screenshots show the concepts of the Tabris UI using this example. I will tell you more about the details of the Tabris UI in a separate post.

What’s Next for Tabris

Over the next month we will concentrate on topics like bug fixing, stability and clean-up to create an awesome 1.0 release. Of course, you can comment on all topics and contribute your ideas – it’s all publicly available on GitHub Issues.

1. Top 10 Eclipse Juno Features

Eclipse Juno has been released this year and it was the first simultaneous release built on Eclipse 4. In preparation of the release, Ian has been counting down the Top 10 Eclipse Juno Features.

2. Eclipse 4 (e4) Tutorial

Jonas Helming wrote a tutorial series for the new core platform of the Juno release. It introduces the new concepts in the Eclipse 4 Application Platform, aka RCP 2.0. The Eclipse 4 (e4) Tutorial has 4 parts: Part 1, Part 2, Part 3 and Part 4.

3. Ups and Downs with Continuous Integration for iOS Apps (Jenkins, Xcode, Cobertura and Testflight)

Holger Staudacher blogged about the Ups and Downs with Continuous Integration for iOS Apps. He built a full CI system for Tabris including automated test execution, code coverage and publishing to Testflight. In his post he detailed the steps to create the system. This can be quite helpful for you when you plan to build your own iOS app.

4. Must-reads for Java Developers: From Beginner to Professional

Holger has been recommending the same books again and again to fellow developers – for different experience levels. Finally he has put together a list of must-reads for Java Developers.

5. My Top 10 Tips on how to be more productive with the Eclipse IDE

I wrote about my top 10 recommendations that will make your programming life easier and make you more productive with Eclipse in “my top 10 tips on how to be more productive with Eclipse“

6. Tabris – iOS and Android apps written in Java

Jochen announced Tabris (called RAP mobile at the time), an interesting approach for writing multi-platform mobile apps: Tabris – iOS and Android apps written in Java

7. Serial Communication in Java with Raspberry Pi and RXTX

Raspberry Pi is the darling of many developers. Johannes Eickhold wrote an introduction on dealing with serial communication in Java with Raspberry Pi.

8. An OSGi JAX-RS connector Part 1: Publishing REST services

Interested in publishing OSGi services as REST services? Then Holgers blog on the OSGi JAX-RS connector is a must read for you. More interesting reads and updates are available using the REST tag.

9. Loading, caching and displaying images in Android

Efficiently displaying an image from a remote server in a mobile application can be quite challenging on Android. Moritz provides a conceptual walk through of several established patterns to load, cache and display images.

10. Mobile Select-O-Matic

Jochen blogged about finding the right mobile development technology for businesses with the Mobile Select-O-Matic.

If you have feedback or a favorite post you would like to have mentioned, feel free to leave a comment below.

Page Navigation with Gestures (Swiping)

One of the most commonly used gesture on mobile devices is swiping. Swiping between different screens (Pages) is the default navigation on the home screens of all major mobile operating systems. Tabris introduces swiping with a simple to implement page-wise navigation feature. You simply have to add Controls to an ItemProvider to enable the navigation. You can dynamically add and remove items, lock the navigation on items and cache items on the client so that no server interaction is needed. The /swipe demo in the Tabris Demo app illustrates this new feature. If you want to take a look at the code just examine the source at GitHub as usual.

Creating custom touch elements

Many mobile applications have advanced styling requirements. You can get very far with the standard SWT API, but when composing touchable widgets you run into a subtle problem. How do you show immediate touch feedback without having to contact the server? The current release introduces a new concept to assist you here. ShowTouch enables local visual user feedback without a server round-trip. Usually you also want to handle the user event on your composed widget, and Grouped Events add the possibility to react on any interaction happening on a set of widgets that belong together.

ShowTouch

Immediate visual feedback improves the user experience. When added to a composite as in the following example, the whole area of the composite, including its child widgets, will be highlighted immediately. ShowTouch works on any single widget, too.

Widgets.onWidget( composite ).showLocalTouch();

Grouped Events

If you group some controls together in a composite, you can now listen to events on any of them in one central place. This feature is a useful complement to ShowTouch. The following example shows how to add such a listener to a composite.

Widgets.onComposite( composite ).addGroupedListener( SWT.MouseDown, new Listener() {
    public void handleEvent( Event event ) {
        ...
    }
} );

Navigating hierarchical lists on Android

Tabris offers a simple mechanism to display a hierarchical list – by rendering a Tree widget branch-wise. The first implementation offered an “up” button at top of the tree for back navigation. Now we replaced the button with the native back-button. Pressing the back button on the device now navigates you “up” through the tree hierarchy.

Bonus: App Events

When a Tabris application is sent to the background by the user, or activated again, the new AppEvent gets raised. Listening to AppEvents enable a couple of use cases like locking the app or saving resources (turn off GPS). You can meet HAL if you take a look at the example /appevents in the Tabris Demos app.

Bugfixes and Minor Changes

Next to the usual bug fixes the Tabris client now can also be found in Google Play for tablets again.

Feedback Always Welcome

We keep an eye on your comments and suggestions at our GitHub Issues. Your suggestions and comments are welcome and always have a chance to influence our schedule.

AppLauncher API

The new AppLauncher API enables tight integration between your Tabris apps and all the common apps on iOS and Android. For each type of app you can interact with, there is an Options object you provide as parameter.
Here is an example how to use the AppLauncher API to show an address within the Maps app using MapsOptions:

AppLauncher launcher = RWT.getClient().getService( AppLauncher.class );
launcher.open( new MapsOptions( "Lammstr. 21, 76133 Karlsruhe, Germany" ) );

• BrowserOptions - Open a URL in the Browser app.
• MapsOptions - Open the Map app with latitude+longitude or a address as text query.
• SMSOptions - Open the Messaging app with a number and the message.
• MailOptions - Open the Mail app with to, cc, subject and the message body.
• PhoneOptions - Open the dialer to start a phone call.
• Twitter- and FacebookOptions- Open Twitter or Facebook to add social integration in your app to post a message with an optional URL.
• Generic openURL - With this you can open arbitrary URLs with the most appropriate app, which is determined by iOS or Android.

Check the sources on GitHub of our “Breaking Bad“-themed demo app called “launcher” to see how the API is used.

Alternative Selection for List and Tree

We now support a new UI element on SWT List and Tree (aka Detail Disclosure Button on iOS) on Android and iOS.

Here is an example how to activate the alternative selection on an SWT Tree only for the leaf TreeItems:

Widgets.onTree( tree ).enableAlternativeSelection( TreePart.LEAF );

tree.addSelectionListener( new SelectionAdapter() {
	public void widgetSelected( SelectionEvent event ) {
		if( (event.stateMask & SWT.ALT) != 0 ) {
			// Alternative Selection
		} else {
			// Standard Selection
		}
	}
});

Remote Application Platform (RAP) 2.0

Starting with Tabris 0.9.0 we are now built on RAP 2.0. Have a look at the RAP 2.0 New and Noteworthy and the RAP 2.0 migration guide to see what changed and what adjustments you might need to make to your code.
Please ensure you update your Target! In case you forgot, here is the URL to the p2 repository: http://developer.eclipsesource.com/technology/tabris/downloads/releases
In Tabris, the following changes relate to the RAP 2.0 migration:

• Reworked the clients and how they communicate to the server. All communication is now 100% JSON.
• UICallback is now ServerPush, which is now a way more robust implementation on the Tabris clients.
• New Bootstrapper mechanism. It is used to enable Tabris in your ApplicationConfiguration without the need of confusing startlevels.

  Bootstrapper bootstrapper = new Bootstrapper( application ); bootstrapper.bootstrap();

Next for Tabris

Since the last Tabris release, we also published our new Tabris website. One of the highlights is the Roadmap section. There you can see what happend in the past, what we are currently working on, and what you can expect in the future. Of course, you can comment on all topics and contribute your ideas – It’s all publicly available on GitHub Issues.

Follow this link for detailed information on Tabris.

Thank you Eclipse Foundation and Google for organizing this event for the fourth year now!

Most of the resources also have an active community on Google+, so a link is added when available.

developer.android.com/design - The official website of the android style guide.

Android design in action [g+] - The “official” Google Developers Live show for Android design. The weekly show features app redesigns, usability patterns and best practices when designing for multiple screen sizes.

Styling Android [g+] - A great set of tutorials on how to change the visual appearance of the various Android UI elements.

Android Niceties [g+] - Android niceties publishes a list of well designed Android apps.

Holo Everywhere [g+] – Holo everywhere is a “design review” page for holo styled apps.

Android Views [g+] - Android views collects links to opensource Android widgets and presents them in a Google Now like card design.

Asset Studio - An online tool to create graphics and other UI artifacts for Android applications.

Android UI Patterns [g+] – Great website focusing on Android design news, observations and UI patterns. Also home of the book “Smashing Android UI” by +Juhani Lehtimäki.

Android UI UX - +Taylor Ling discusses Android design and UI patterns.

Android design community on Google+ - A (still young) community of people discussing Android design.

Do you know of other Android design resources? Let me know.