Grails 3 - Step By Step
Table of Contents
- How this book is organized
- Introduction to Grails 3
The Mobile Application - Rest API Profile
- About this chapter content
- Introduction to Ionic 2 and Hybrid Mobile Applications
- Rest API
- To the app store
- To do list
How this book is organized
We try to describe here how a complete greenfield application can be implemented with Grails 3 in a fast way using profiles and plugins - and we do this in the sample application that accompanies this book. You can find news about this book on its presentation site located here: www.grailsthreebook.com. This book is not a replacement of the Grails 3 Reference Documentation which is a complete description of Grails 3, made by the creators of the framework.
The source code used in this book is part of this sample application which is a free project hosted on GitHub on this location: https://github.com/colaru/mvp-application. If a source code fragment is included in this book, then it is taken from this project. We use BDD or other specification by example techniques for describing the sample application specification - the leaving documentation for the project can be found here: http://serenity.itjobsboard.eu. The application code is tested in a TDD style using automated unit, integration and functional tests.
The sample application is based on a multi project Gradle build so the application can be automatically built using Gradle - the build tool used by Grails 3. The web application is available here: https://www.itjobsboard.eu. The admin application is available online here: https://admin.itjobsboard.eu - users admin, operator or customer with password Password123!. The deployment is done automatically to AWS cloud in a Continuous Deployment style using Jenkins.
We use links to various external resources in this book (you will see them in the page’s footers), because this book is intended to be in electronic format from the beginning. The reader can use these links for consulting external references in an easy way.
The book has two parts.
First part - Grails 3 Essentials
An introduction to application development with Grails 3; we describe the main application that will be implemented in the second part of the book
Chapter 1 is an introduction to the framework. You will find here some history of the framework and a lot of links to the Grails resources; it is presenting the classical three layered architecture for a web application provided by Grails 3
Chapter 2 describes how to start your work with Grails 3 framework and how to install all the tools for a free working environment - free as much as possible because you have to pay some money for the best tools on the market
Chapter 3 presents the project we want to implement as an example; it is presenting also the way we choose to work on implementing the sample application, based on BDD, TDD, CI and CD; it shows how the main application is split into multiple parts based on Grails 3 profiles
Second part - Practical example with Grails 3
A practical implementation of a greenfield application with Grails 3; the application is composed of multiple parts corresponding to various Grails 3 profiles
Chapter 4 describes the implementation of the application admin portal that will be used in Intranet by the site administrators, based on a classical Grails 3 Web profile
Chapter 5 describes the implementation of the application site exposed to the Internet to the customers, that is based on Grails 3 Angular profile
Chapter 6 describes a REST web API exposed with Grails 3 Rest profile and consumed by a mobile hybrid application created with Ionic 2 (published in Google Play Store, Apple App Store, and Windows Store)
Chapter 7 describes a Microservice developed with Grails 3 Rest API profile;
Introduction to Grails 3
Grails is a full stack Web framework, covering all the aspects of a modern web application development. Its plugins system is unique in the Java world - you can divide your application into complete functional modules, containing presentation and business logic. Because it runs in JVM, it has access to the entire Java ecosystem. Because is written in Groovy, it has access to all Groovy libraries and tools.
The main site for Grails 3 is grails.org. Here is the definition of Grails on the official site:
Grails is a powerful web framework for the Java platform, aimed at multiplying developers’ productivity, thanks to Convention-over-Configuration, sensible defaults, and opinionated APIs. It integrates smoothly with the JVM, allowing you to be immediately productive, whilst providing powerful features, including integrated ORM, Domain-Specific Languages, runtime and compile-time meta-programming, and Asynchronous programming.
If you have developed multiple applications over time, you have recognized a set of principles and good practices that can be reused. You don’t want to start from scratch each time you build your new application. Grails has good technical principles that make it a good starter for your new applications. With Grails, you have an established architecture from the beginning, and you can implement new features in an easy way, using scaffolding and the plugins ecosystem. And this is more valuable when you have to get to the market first, before your competitors.
First it was Java, and was created by Sun Microsystems and its father was James Gosling. Java came with the idea of JVM - Java Virtual Machine that lets you Write once, Run everywhere. Everywhere means on any operating system. You write the code in a source file which is compiled to a byte code runnable by the JVM. Any operating system has an implementation for the Java Virtual Machine specification.
Because Sun was bought by Oracle, now Java is in Oracle’s portfolio. Java is used by millions of developers (Oracle claims 10 million) and is the number one TIOBE index of most used languages in the world.
Why was Java such a strong language from the beginning? Some clues:
- It was totally object-oriented from the beginning and let people think everything is an object (this is the name of a chapter from one of the best Java books Thinking in Java - TIJ) written by Bruce Eckel.
- It eliminates the pointers and memory deallocation, letting this be handled by the JVM and the garbage collector; the GC is constantly improved by the Oracle team. G1 GC is the most advanced GC these days.
- It has multithreading inside from the beginning.
- It has exceptions handling inside.
- It has modularity inside, represented by packages and the possibility of packaging libraries in .jar files that can be reused between projects; there are a lot of libraries on the market, and as proof, you can search a Maven global repo
Java EE history
After this was the Java EE (known in the past as J2EE or JEE) – an attempt to make it easy to create enterprise applications (compared to other 2 profiles Java SE for desktop applications and Java ME for mobile applications). The language and Java EE is specified by a committee named JCP Java Community Process, which is responsible for creating JSRs, specifications implemented by various vendors. Any JSR has a reference implementation which is a proof that the specification can be implemented.
For example, the last specification for the Java Servlet is JSR 315: JavaTM Servlet 3.0 Specification and the reference implementation for this standard is Oracle GlassFish 3.x (RI). Grails embeds by default inside, in DEV mode, a Tomcat server and you can see what version of Java Servlet is implemented on each Tomcat version.
But the Java EE standards were too de jure for the Java community, compared to a lot of frameworks that emerged in the Java open source space, considered more the facto standards like: Struts for Web, Hibernate for persistence, etc. And then Spring Framework was born as a response to this committee style and specification centric style of driving the Java future - Rod Johnson and others put the foundation, and Juergen Hoeller is now responsible for the framework as part of the Pivotal portfolio. The framework introduced Dependency Injection and reaffirmed the power of POJOs (Plain Old Java Objects) - in contrast to EJBs (Enterprise Java Beans) which were at version 2 when Spring emerged - things have improved in EJB 3.
In time, these two technologies are evolving in parallel. For example, Java EE adopted the DI in its CDI, some implementations of JPA wrap Hibernate. Spring embraces annotations for configurations, instead of XMLs, as in Java EE. And Spring Framework has integration with some JSRs and is based on some technologies provided by Java EE.
The main documentation for Spring Framework is the reference documentation.
Java is an imperative style programming language and, compared with functional programming languages, it suffers from accidental complexity as Venkat Subramaniam says.
Groovy is a functional programing language that is bringing functional style to Java programming. It introduces the notion of closure which is the idea of function as a main citizen of your code. It is also a scripting language because it has the characteristic of incorporating a lot of semantics in a short syntax.
It was started by James Strachan, back in 2003, as a dynamic language for the JVM, inspired by Ruby, but closer to Java. Guillaume Laforge become the project lead after James leaves the project, and he is still the lead today. Here is a history of the most important moments of the language and the main contributors to the project.
The official Groovy site is groovy-lang.org. Here is the definition of Groovy on the official site:
Apache Groovy is a powerful, optionally typed and dynamic language, with static-typing and static compilation capabilities, for the Java platform aimed at improving developer productivity thanks to a concise, familiar and easy to learn syntax. It integrates smoothly with any Java program, and immediately delivers powerful features to your application, including scripting capabilities, Domain-Specific Language authoring, runtime and compile-time meta-programming and functional programming.
Some characteristics of Groovy:
- it was a way to get functional programming into JVM; it introduced closure to the Java world long before the Lambda Expressions in Java 8
- it is compiled to Java bytecode that is running in JVM (there is a groovyc compiler that is compiling Groovy code to Java bytecode in the same way the javac compiler is doing with Java code)
- Groovy scriptlet can be embedded in Java code and the resulted mixture is still working after compilation
- is enriching the Java classes with other convenient methods resulting in a new API named GDK
As you can see in this diagram the Grails framework was born in 2008 with its first GA release. Grails 2 was released in 2011. And Grails 3 was first released in 2015.
Here is a top of Java Web frameworks published by RebelLabs in 2017. Grails is placed on the 5th position immediately after SpringBoot (and Grails 3 has SpringBoot inside). Grails 3 is not a simple Web framework like the majority of the frameworks presented in this top but a full stack framework like Play which is the 7th position. JHipster which can be an alternative to the Grails 3 Angular(2) profile is the 10th position on the list.
What makes Grails a good choice from the multitude of frameworks for building Web applications:
- Grails is a full stack web framework in the sense that you can create an entire Web application using it. It covers the web presentation, business domain and database persistence aspects of your application. Not alone, but integrating the right technologies for this: Java, Spring, Hibernate. And all of these are linked by Groovy language with is used for configuring your application - the DSL for configurations are Groovy based (now in Grails 3 you will have the option to use YAML also)
- conventions over configurations
- for creating a service, it is enough to place a groovy file containing a class without state in /service folder without annotating it with @Service or mark it in a configuration file like in Spring or annotate with @Stateless for a EJB 3 stateless session bean
- for creating an entity, it is enough to place a POJO class in a /domain folder and no @Entity annotation like in JPA or Hibernate or declaring it in configuration files
- scaffolding for generating a seed application or a variety of elements starting from domain objects; it can be static (generating the corresponding files in filesystem) or dynamic (generating just proxies in memory)
- environments inside from the beginning like TEST, DEV, PROD (or a custom one) letting you take different actions in runtime based on the given environment
- testing inside the framework (unit - in isolation using mocking, integration, functional) using JUnit, Spock and Geb
- static resources served in an optimized way (asset pipeline plugin replacing resources plugin)
- asynchronous features based on plugins in first versions and directly inside in version 3 using Reactor
- dynamic reload of classes and resources in runtime based on spring-loaded technology and on the fly reloading in Tomcat (dev mode); no server restarts are needed in development mode or products like JRebel
- and many more…
Also, the history of the companies that stay before the framework is interesting. First it was supported by G2One Inc a company founded by the Groovy and Grails project leads, Guillaume Laforge and Graeme Rocher. It was acquired by SpringSource (first Interface 21) which was on background of Spring Framework. SpringSource was acquired by VMWare and transferred to the Pivotal portfolio. In 2015, the end of support from Pivotal for Grails and Groovy was announced and Grails is now supported by OCI and Groovy was adopted by Apache Foundation.
We present here a list of the main contributors to the Grails framework and the plugins ecosystem, Groovy or other related tools:
- Graeme Roche - the father of framework with more than 10 years of development
- Jeff Scott Brown - Cofounder, implementer of Rest API and Grails books writer
- Guillaume Laforge - Groovy project lead
- Burt Beckwith - Security guy (Spring security and other security plugins)
- Craig Burke - Asset Pipeline suite of plugins
- Alvaro Sanchez - Rest security plugin
- Marco Vermeulen - SdkMan
Here is the contributors list for Grails core Git repository Here is the reference documentation
Grails application architecture
A classical layered architecture
If we are talking about the architecture of a Grails 3 application, we should express this in architectural design patterns. And the right place to find architectural design patterns is this book Patterns Of Enterprise Application Architecture written by Martin Fowler. His catalog of design patterns is available online. We will use a set of patterns from this book but other patterns are used inside the Grails integrated frameworks.
First of all, a Grails application is a classical three layered architecture composed from presentation, domain and data source layers.
In a Grails application, the layers are represented by:
- Presentation Layer - is a classical Model View Controller - MVC represented by Spring MVC framework. The Spring MVC framework is wrapped by Grails which has some specific elements. In Grails, the C are the Grails controllers, the V are the Grails GSP views (rendered from layouts, templates and tag libraries), and the M are the domain entities (the entities are part of the domain layer but are reused in this layer). Also, the Spring MVC framework is based on Servlet API, JSPs, tag libraries and is responsible for interaction with the user via HTTP 1 (or 2)
- Domain Layer - Is split between a Services Layer which are Spring singletons beans and a Domain Model of entities which are the mappers to the database
- Data Source Layer - represented by GORM framework and domain entities which are classical Active Record. Gorm offers access to Sql databases and is based on Hibernate which is based also on Java JDBC API and uses SQL for queries.
Because it is a technology stack, we have to deal with a lot of knowledge and abstraction:
|Layer||Presentation Layer||Domain Layer||Data Source Layer|
|Patterns||MVC||Service Layer & Domain Model||Active Record|
|Frameworks and libraries||Spring MVC||Spring Beans, DI, Transactions||GORM (Hibernate and NoSql)|
|Java technologies||Servlets, JSP, tag libraries||POJO||JDBC|
|Basic technologies||HTML and HTTP||-||SQL|
- The domain/persistence entities are used in the entire Grails application from presentation to the persistence with different roles; they are primary persistence objects having state and persistence methods (CRUD operations but also finders generated dynamically by the Grails framework) but you can choose to enrich them with other functionality because they are part of the domain layer
- Dependency injection (which is coming from Spring) is used for injecting services in other services and in controllers
- The services layer acts as a façade or as an API to the layer in front of it; typically, on this layer we will offer the ACID transactional support
- Controllers from the MVC are responsible just for managing the user interaction flow and will not contain any logic; the place for logic is in the services (and eventually in the domain entities)
New technologies inside Grails 3
Grails 3 is a rewrite of Grails 2 and now is based on Spring Boot and not just on Spring framework. The old build system (Gant scripts) are replaced with Gradle with is already used by Spring Boot. This migration has a downside - all the plugins have to be migrated to the new Grails version. The good thing is that the most important plugins were already been migrated by the Grails community. And a set of plugins are not needed anymore because they can be replaced with Gradle plugins and Spring starters.
You can access the reference documentation for SpringBoot.
Some advantages from having Spring Boot as your Grails 3 heart:
- All Spring Boot starters (starter is the SpringBoot plugin system) are available for your application
- In SpringBoot you can have both Java and Groovy source files
- Some new technologies like websockets and reactive (Reactor project) are available now to your Grails application via Spring Boot
In Grails 3, the old Gant scripts were replaced with Gradle build tool. You can access the Gradle main site. The Gradle user guide is also available. Gradle is the third generation build tool for Java after Ant and Maven and has inside all the accumulated experience from its predecessors.
We present here a diagram from a report published by ZeroTurnaround’s RebelLabs which provided a timeline of build tools for Java ecosystem from 1977 through 2013
As an example of its importance, Gradle was chosen by Google as the de facto build tool for Android projects. We try to enumerate here just a part of the advantages that come with Gradle:
- All Gradle plugins are now available for you and can now be used in a variety of aspects of building
- The main scripting language in Grails is (still) Groovy, the same scripting language used in Grails. In this way, it will be simple for you to improve your build system whenever you like.
- Gradle is now offering the possibility to create multi projects builds for Grails 3
Starting with Grails 3 the database persistence part of the framework named Gorm was extracted completely outside the framework by the Grails team and was redesigned to be a wrapper over both Sql and NoSql databases. Also, starting with Gorm 4, this persistence framework can be used outside of Grails applications (in other Spring Boot applications for example).
In the new Gorm with Hibernate integration (which was the default persistence mechanism in Grails 1 and 2), you can still have support to the main SQL databases on market: MySql, Oracle, Postgresql, MsSql Server, etc. Also the framework is now offering support for other persistence technologies like the NoSql databases: MongoDB, Neo4j, Cassandra, Redis. And the trend of Gorm is to use non-blocking drivers and to offer as reactive an approach as possible.
LogBack is the most modern logging framework (the successor of Log4J) and it comes to Grails 3 because was chosen as the logging framework for Spring Boot. You can access the LogBack main site.
Modularity aspects of Grails
Plugins were a main feature of Grails from the beginning of the framework. Here is the list of Grails 3 plugins. Even the framework itself in his core is a bunch of essential internal plugins. In fact, Grails is an aggregator for its plugins. If you look in a web profile of a Grails application you can see the default Grails plugins that are declared for this profile (will be different plugins for different profiles)
Here we try to enumerate some plugins and let you understand how many technologies can be accessible in such a simple way:
- internal plugins
- Hibernate plugin is the plugin with the GORM implementation for Hibernate 5 persistence framework
- external plugins
- Spring Security Core Plugin is the plugin responsible for the security of the Grails applications; it is based on Spring Security library and it has a lot of companion plugins for other aspects of security - for example Spring Security REST Plugin for REST API security
- Quartz plugin for Grails is the plugin responsible with scheduling jobs based on a well known Java library Quartz; you can use it with another plugin Quartz Monitor Grails Plugin responsible for monitoring the list of jobs
- Mail plugin is the plugin that can be used to send emails via a configurable SMTP server
- Elastic Search plugin will let you implement search for your site; your data is indexed using Elastic Search library
- Audit Logging plugin can be used for auditing your application activity
About plugin’s benefits:
- should be declared in configuration files and are resolved as dependencies in a Maven, Ivy, Gradle style
- expose Grails constructs like services, controllers, views, entities, et cetera
- come with configurations that must be added to main app configuration file
Profiles were introduced in Grails 3 and now we can create different types of applications, not just the main type that was available till now, based on a server side HTML rendered interface using technologies like Gsp (based on a MVC framework on the server side). Now we can create a Grails 3 application that is just exposing a web service API without a classical server side rendered Web interface. Also, we can create a rich client directly from the server side - using scaffolding in the same way we have done till now for the classical type.
This is in accord with the global trend of IT industry these days which is trying to break the monolith application into small pieces, introducing the concept of Miroservices. In these days, Java EE is creating a new Microprofile for microservices in addition to their Full Profile and Web Profile.
You can see very clear the evolution of software architecture in the last decades in a tweet from Benoit Hediard:
Another reason for this profiles movement is the need to expose just Web services and not a HTML based Web interface. And this is more valuable in the context of the mobile application and the mobile first approach in developing applications. That’s why a new set of server side rendering technologies were introduced in Grails 3 like Grails Views that are rendering JSON and XML from domain objects.
These are the profiles introduced in Grails 3:
- angular - A profile for creating applications using AngularJS
- rest-api - Profile for REST API applications
- base - The base profile extended by other profiles
- angular2 - A profile for creating Grails applications with Angular 2
- plugin - Profile for plugins designed to work across all profiles
- profile - A profile for creating new Grails profiles
- react - A profile for creating Grails applications with a React frontend
- rest-api-plugin - Profile for REST API plugins
- web - Profile for Web applications
- web-plugin - Profile for Plugins designed for Web applications
- webpack - A profile for creating applications with node-based frontends using webpack
Some details about the most important profiles that will be used in the application built in this book:
- web - is a profile for creating classical Grails applications with a server side MVC framework in the same way it was in Grails 1 and 2; the presentation web interface is rendered on the server side
- rest-api - is a profile for creating applications that are exposing REST APIs; don’t have a Web presentation and no MVC is needed
The Mobile Application - Rest API Profile
About this chapter content
First, we will install Ionic 2 and all the development tools for Android, iOs and Windows Phone. We will generate our client app using Ionic CLI, and we will describe the anatomy of an Ionic 2 application. We will improve and document our exposed REST API, and we will add security using JWS tokens. We will deploy our app to all the tree known mobile app stores.
Here are the primary resources for this application:
- the source code for the Ionic 2 client is stored in GitHub: https://github.com/colaru/mvp-application/tree/master/app-web/ionic-client
- the REST API documentation: https://app.swaggerhub.com/api/colaru/ItJobsBoard/1.0.0
- mobile app in GooglePlay Store: https://play.google.com/store
- mobile app in Apple AppStore: http://www.apple.com/itunes
- mobile app in Microsoft Store: https://www.microsoft.com/en-us/store/top-free/apps/mobile
Introduction to Ionic 2 and Hybrid Mobile Applications
There are a big number of smartphones and tablets on the market, each having a given operating system and is produced by a given manufacturer. We live in the years when the number of mobile phones overcomes the number of desktop and laptop computers, and the difference is still growing (Google is reporting that there are more searches from mobile now than from desktops).
There are some stores today where you can publish your mobile application based on its operating system. There are some signs that in a number of devices Android is the winner in the market (~70%), followed by iOS (~20%). Windows Phone has just a few percents but they choose to invest in mobile in the last time and your application can be also available to other Windows 10 devices like PC, tablet, Xbox due to UWP (Windows 10 is around 25% from desktop OS market). Here is the list of major mobile operating systems on the market:
|Android phones and tablets||Google Android||PlayStore||Android(Java)|
|iPhone and iPad||Apple iOs||AppStore||Objective-C or Swift|
|Microsoft phones and tablets||Windows Phone||WindowsStore||C#, Visual Basic|
Google is the owner of Android OS and the devices are manufactured by many others like Samsung, Motorola, etc. There is a reference device Google Pixel series manufactured by Google. Till now it was Nexus, but the manufacturer was not Google. The programming language is Java (Android is derived from Java), and the development tool is Android Studio (based on IntelliJ Idea now, in the past was Eclipse) which can run on Linux, Windows or Mac operation systems.
Apple is the owner of the iOs operating system and is also the manufacturer of the iPhones and iPads. The programming language in Objective C with the addition of a more scripting language named Swift. The development tool is named XCode, and you need a Mac OS system to develop your application.
Microsoft is the owner of Windows Phone operating system and is manufacturing itself some physical devices - based on acquired Nokia company. Starting with version 10, the Windows and Windows Phone are sharing the same store and is possible to publish a mobile app and will be available on mobile and desktop at the same time due to Universal Windows Platform - UWP. You can program in C# or other .Net language. The development tool is Microsoft Visio Studio available on Windows OS.
It is hard to develop applications for all the stores because you have to know a multitude of languages Android(Java) for Java, Objective-C or Swift for iOs, C# or Visual Basic for Windows. A solution for this (write once publish everywhere) is to create hybrid applications using tools like Ionic.
Install Ionic 2
You will get something similar with this:
I get 2.0.0 for Ionic and 6.5.0 for Cordova.
You have to install Android platform and iOS platform on your machine (we hope you have a Mac OS to be able to install both). This because you have to publish your application in store, you need the binary for each platform .apk for Android .ipa for iOS.
For Android, you can follow this Cordova Android Platform Guide. If you already have Java JDK installed you have to install Android Studio (you will be familiar with it if you are already using IntelliJ Idea) which is coming with:
- SDK Manager - will let you install the Android SDK (at a given level)
- ADV Manager - will let you configure the Android emulators
- Android Device Monitor- will let you see your devices logs
For iOS, you can follow this Cordova iOS Platform Guide. You have to install the XCode first which is coming with the SDK, iOs and iPad emulators and all you need to deploy your app in production.
For Windows 10 follow this Cordova Windows Platform Guide. You have to install at least Visual Studio Community Edition 2015/2017 which is free. You will get the Windows phone SDK, the emulator and all you need to deploy your application in production.
You can use a virtualization solution (VirtualBox for example) if you are on Mac or Linux for running the Windows OS - you can get images available for free for one month. If you want a Linux box you have OsBoxes.
Generate client app
Now you are prepared to start your first application using Ionic 2 and its Command-Line-Interface - CLI. We will generate a sidemenu starter application - we will have a side menu. There are two other alternatives blank and tabs. We will locate our client in app-web module near our static HTML client we made.
We used the –v2 flag to create a Ionic 2 project (otherwise, the old Ionic 1 project is generated). The confirmation:
Now build it and run it:
We will see the app as it looks on all three platforms:
Now, if we look at the structure of generated app:
We will see this folders structure:
This is a classical Ionic 2 application folders structure. We describe here the main folders and files:
- config.xml - is the main configuration file for an Ionic application; you describe your app metadata, required device access rights, preferences and used Cordova plugins.
- /plugins - is the place where all Cordova plugins are located
- /www - here are the application place after build
- /src - is where the Angular 2 application is located
Let see the structure of the app:
We will see:
We see that we have 2 pages. For each page, we have an entry in the pages folder. Let’s create other pages using Ionic CLI.
First, let’s create a new index page:
Then a page for showing the jobs:
And we will delete the default created pages (Page1 and Page2):
We will see:
Let’s create a service for communicating with the server:
The service will be created on providers folder and will be named jobs-data.ts:
We will add the code for listing the jobs from REST API:
We will inject this service in our page component and we will call the listJobs method:
And we will adapt the page template to show the jobs as cards:
And here is the code:
The result is here:
The jobs page on our web page:
The result is here:
The jobs page on our device:
First of all, the main configurations for the mobile application are in config.xml file. Lets change the name of the application and other metadata:
We will discuss two aspects of Cordova: plugins and platforms.
Cordova, it is a plugin-able system, and there is a list of plugins available on the market (mostly free). You can see the list of plugins already installed on your application:
You will see:
They are located on plugins folder:
You will see:
And are declared on config.xml file:
You will find the list of declared plugins:
Each time you want a plugin you have to declare it here in config.xml.
Cordova let you install platforms - various operating systems where you can publish your application. The ios platform was added the first time I generated the application. We can add Android in this way:
If you want to see a list of platforms, use this command:
And the response:
The platform content is stored in platforms folder:
You will see the installed platforms:
Now we can start to work on a given platform. We can use the iOs emulator to play our application:
Or we can run our application on an Android device connected by USB to our computer (it has to be set in developer mode):
If you want to see the list of available commands, run:
Ionic Native is a collection of the best free Cordova plugins already integrated into Ionic 2 - you still have to declare and install the plugin, but you have the API exposed in Angular 2 style. The Ionic Native script is already installed in any new generated Ionic 2 application. It is a replacement for ngCordova from Ionic 1. We will enumerate just a few plugins (part of Ionic Native) that can be used in your commercial application just for illustrating the possible native features that can be accessed via plugins:
|AdMob||Plugin for Google Ads, including AdMob / DFP (double-click for publisher) and mediations to other Ad networks.|
|App Rate||The AppRate plugin makes it easy to prompt the user to rate your app, either now, later, or never.|
|File||This plugin implements a File API allowing read/write access to files residing on the device.|
|Geolocation||This plugin provides information about the device’s location, such as latitude and longitude.|
|Google Analitycs||This plugin connects to Google’s native Universal Analytics SDK|
|InApp Purchase||A lightweight Cordova plugin for in app purchases on iOS/Android.|
|InAppBrowser||Launches in app Browser|
|Splashscreen||This plugin displays and hides a splash screen during application launch.|
|SMS||Send SMS from your application|
We will investigate 2 plugins here. First, we will change the default splash-screen (and the application icon) showing the Splashscreen plugin already used in the generated app. And we will introduce InAppBrowser plugin for displaying our external links in our application (not into a different window in the system browser).
So, the Splashscreen plugin is declared in config.xml file and is used in app.component.ts where the splash-screen is hidden after the application is started:
All that we will do is to replace the default splash-screen image and icon generated by Ionic. These images are stored in resources folder:
The icon is icon.png and the splash-screen is splash.png. From these 2 files we can generate all the resources files for our platforms (various devices with different screens resolutions) using the resources command (after we modified the images using a tool like Gimp or Photoshop):
With the result (also the config.xml will be changed to reflect the newly generated files):
Next we will add the InAppBrowser plugin entering a new line in config.xml:
Add the plugin declaration in the config file (we installed it and declare it at the same time - see the –save option):
We will change the method called when a job posted is tapped in jobs.ts:
See this call from jobs.html where the method is called:
In this subchapter, we will improve our REST API. We will first try to clarify what is a RET API; we will document our API using Swagger, we will add token based security for our REST API
From verbs to nouns
The way the applications can communicate in a distributed way is an old subject. First was the idea of RPC - Remote procedure calls - remote calls between programs running on different machines which are exposing procedures/methods using binary data for messages transportation.
The next evolution step were Web Services using HTTP protocol for communication and XML or JSON (text and not binary data) for messages. SOAP was a first success in the Web Services market was but is still have to be used - is based on XML messages and still has a procedural style of exposing an API. That’s way other types of Web Services emerged like REST.
REST - Representational State Transfer principles were enunciated first time by https://twitter.com/fielding in his 2000 Ph.D. dissertation Architectural Styles and the Design of Network-based Software Architectures
One of the interesting parts of SOAP is the WSDL - Web Services Description Language specification. WSDL specification is a contract describing the exposed API that can be used in many ways. Can be used to generate the client or the server. It can also be itself generated by the server side. It is the central point of a SOAP API.
In the case of REST there were some tries to define such an interface (WADL, RAML) but finally, we have a winner on the market. It is Open API that is a try to standardize a well-known schema model globally from Swagger. Will let you define your API in JSON or YAML. Swagger let you not just to specify your API but also to use this specification for documenting your API - you can easily generate a documentation of your API for your users, and they can test it in real-time.
Let’s document our REST API. There are some Grails 2 plugins for generating the Swager spec via annotations and show the spec in Swagger-UI, but none of them is working in Grails 3. Swaggydoc plugin has an update for Grails 3 but is not working - the project is no longer maintained.
The solution, in this case, is to use the tools that Swagger site is offering. They are offering an online Swagger editor for editing our Swagger specs in JSON or YMAL. We have the chance to generate clients or servers in a multitude of programming languages from Swagger specifications using Swagger Codegen. We also have an option to store a Swagger specification online and to view it on Swagger-UI on Swagger Hub. We created a hosted Swagger specification for the version 1.0.0 of our project:
Swagger YAML content:
REST Security on the server side
We will introduce security for our Ionic application based on Spring Security for Grails plugin. In this case, we use JWT cryptographic tokens - JSON Web Tokens instead of classical Java Web session based security used in the admin application. This is a full stateless style of offering security to application specific to B2C applications - the clients are not able to store a secret, and in this case, the token is often expired and it is transported via HTTPS.
The creator of the Rest Security plugin created a workshop to accommodate with REST security Creating applications with Grails, Angular, and Spring Security.
The simple way to implement REST security in our application is to create at the beginning your Angular(2) profile Web application with rest security enabled - –features security. This will generate your client and server already configured for security. In our case, the web-app is already generated without security. We have to do this by hand.
Now it is a good time for versioning our REST API - a good practice because the clients will become dependent of our API and we have to migrate to new versions of API without breaking the clients. For guidelines about how to version an API see the Semantic Versioning specification. We will create a first version 1.0.0 for our API, and we will specify two new URLs for our REST API:
We will expose two resources - jobs and featured jobs. We want the list of featured jobs to be seen by everybody, but we want the entire list of jobs to be visible just for authenticated users (it is not a really security case here but is enough to illustrate the security concepts):
We create two new controllers in JobController:
And the controllers:
Now we will protect these resources accordingly using JWT tokens security. For this, first we have to change the security core plugin with rest security plugin (all the core features are still part of this REST plugin):
We will change to:
If we restart the app we will have the confirmation of the installation for this REST plugin (and the core plugin is still there):
Now we have to configure the security filters for the newly added plugin. We have to add the stateless filters for our API path /api/** (we keep state-full filters for this path /*). Also because we will have *permitAll access to some of our API resources we will enable enableAnonymousAccess = true for our version 1.0 of our API and set stateless filters to it:
Now the security settings for filters chains will look like this:
Now when we make a call to /api/login with a valid user and password, we will get a response containing a valid JWT token. We can use this token to access resources under /api/v1.0/jobs path just if we are in the ROLE_CUSTOMER. And /api/v1.0/featuredJobs even if we don’t have an access token.
REST Security on the client side
On the client’s side, we have to introduce a new library named angular2-jwt responsible for JWT token management. First, we have to install it with NPM:
We have to change our index page page and added two forms, one for login and another for signup, each submitting the user credentials to the server (ngSubmit)=”login(loginCreds.value)” and (ngSubmit)=”signup(signupCreds.value)”. We show a div containing this two forms in case the user is not authenticated !auth.authenticated() and a div containing welcome info and a logout button in case of authenticated user auth.authenticated():
The new content:
Now the index page with some LAF improuvements will look like this:
And in the controller part we will implement the calls for user login (based on the introduced angular2-jwt plugin):
The LOGIN_URL is the endpoint provided by the Grails Security plugin for exchanging the user and password into a valid token. We define a method named login based on http service which is sending the user and password and parse the response with a authSuccess method to get the token and store it in the browser local storage. In the case of an error, an error message is shown in view page via the error variable. A logout method can be used - it removes the token from local storage.
The class JwtHelper is used to parse the token and get the username. Here is the content of a JWT token:
After a successful login a response is received containing a valid token and also a refresh token that can be used for accessing pages secured with role ROLE_ADMIN (we shorted the tokens for space reasons):
Now we can use two methods in our Jobs page for retrieving the jobs that will be shown. First is listJobs() if the user is authenticated and the second is listFeaturedJobs() if the user is not authenticated - AuthService.authenticated() the call is used for checking this.
Finally, the JobData provider has two different methods. One named listJobs that is using the authHttp provided by angular2-jwt (see the imports) - this call is injecting automatically the header Authorization:Bearer token… for the call taking the token from local storage. The second method listFeaturedJobs() is using the usual http service from Angular.
We can test that the /avi/v1.0/jobs is not accessible without a valid token:
We will get:
To the app store
Publishing to the app store is simple in the case of Google Play store because there are no so many reviews. But will be mode difficult with the Apple AppStore and Windows Store. You have to improve you application usability to be accepted in the store. You can use a professional template from Ionic Market an official Ionic market for starters, plugins, and themes. Now we will describe the steps that should de follow to publish the app in all three stores.
Google Play Store
The Android store is Google Play - your application is easily accepted (in hours) on this store. There are many free applications in this store, and their users are in general not paying for apps. Will cost you $25 per life for publishing in this store and Google takes 30% from revenue. The user receives 70% from revenue.
First, you have to create a Play Developer account, and there you have to create an application and edit your Store Listing. Title and Full Description are important for ASO - be aware that around 60% of users are coming from store searches. In Manage Releases you will upload your .apk files.
For creating an APK from your Ionic sources you have to use this script:
As you can see the apk is encrypted. You have to create a keystore using this command (keytool is in bin folder of your JDK installation):
You have to execute it:
You will find the APK file in your Ionic app folder: ionic-client/android-ItJobsBoard.apk. You have to upload it and publish the app to the store.
Apple App Store
The store is Apple Store - your application is verified in detail and takes around one week to be published. You can make more money from this store, and in general, there are more payable applications than free. You pay $99 per year for publishing on this store.
Build the iOs project:
First open the project in XCode pointing to the generated .xcodeproj file (from /plathorms/ios folder):
You can first test the application by running the application in the XCode provided emulator using Product/Run.
For publishing, you need to have an Apple Id. Then you have to go to your Apple developer account in the area named Certificates, Identifiers & Profiles. There you have to create an application id - in our case eu.itjobsboard.mobile.app associated with an application named ItJobsBoard. Then, you have to go to your iTunes Connect account where you have to request a new application using New App using the application id created in the previews step. There you have to complete App Information and other application data before submitting it for approval.
Also, you have to upload the binary file, and this can be done in two ways. The first option is to use Product/Archive option from XCode. Second is using a distinct application named Application Loader.
Windows App Store
The store for Windows applications is Windows Store and is not so rich in applications like the previous stores. You have to pay $40 for starting publishing in this store. The advantage of this store is that it is a unified store for all Windows 10 applications and you can publish your application to all Windows 10 devices.
For building your application you need a Windows 10 machine with Visual Studio 2015 or 2017 installed (you can get one for free usage for 1 month or you can buy one forever Windows 10 preinstalled with Visual Studio Community Edition). Then you have to get the project from GitHub on your Windows 10 machine (lets say you are doing this in a C:MVPS folder):
Now you will be able to build our project:
Now you can open in Visual Studio the Windows 10 project located in C:MVPS\mvp-application\app-web\ionic-client\platforms\windows and you can start publishing it to the Windows Store. You can create the deployment artifacts in Project/Store/Create App Packages and there you can choose to link to an existing application definition from your Windows Developer Center account or to create a new one. The package will be signed automatically and you have to upload it manually into the store using Project/Store/Upload App Packages.
You don’t have support in Ionic 2 for generating icons and splash screen resources like in iOs and Android using ionic resources command but you can generate all the icons and splash screens using Properties/Visual Assets option from Visual Studio. Also Windows 10 resources can be generated using this online tool.
To do list
There are a set of things we didn’t manage to implement in the sample application. We will try to implement these features in the near future, but can be a good exercise for the reader to implement them:
- Implement refresh token using angular2-jwt following this Ionic 2 sample
- Implement users signup on client and server side
- Implement a scenario where the customer can save jobs posts after login and the saves are kept on the server side after user logoff