Building Native Apps - Part 2

Building Native Apps - Part 2

FFW Marketing
Thought byFFW Marketing
Website Administrator
June 17, 2015

Building native mobile apps with Ionic Framework and Drupal back-end: Starting a new Ionic Project

Planning app structure

Today, we continue the process of building our first Android app with Ionic Framework and Drupal 7 back-end. If you missed yesterday’s post, you might want to start there. I decided to demonstrate the process using a simple application that will receive data from a blog-type website with RESTful services.

Now, let’s plan our app. In the first stage we will make a hybrid app with two tabs. The first tab will show all blog posts filtered by the newest first, and the second tab will show the list of categories and articles in each category. Then, when a user taps on an article, they will see the full article content and comments. It looks simple enough, so let’s get started.

Start Ionic project from scratch

Ionic comes with three boilerplates to start a new app: blank, tabs and side menu. We decided to make our application using tabs, so we should use the tabs boilerplate. To start, run command “ionic start ApplicationName tabs” (you should replace ApplicationName with the name of your own app) in NodeJS prompt from the folder where you would like to store your projects. This command will install Cordova and Ionic with all dependencies and base files for your project, with prebuilt tabs in it.

Next, enter to the folder with your app name (the same ApplicationName that you entered in the previous prompt command) and run “npm install” to download all build tools dependencies. Let’s see what we get from scratch: run “ionic serve” and it will start a local server and open the project in your web browser. You can resize the window to show the app as in a mobile view, or, if you are using Google Chrome, you can utilize Chrome Dev Tools to emulate a device.

So, now we have the application with four tabs and some dummy content. You can explore that design to really see how the default site is set up. Notice how it changes if you switch between iOS and Android devices; the founders of Ionic did this because each platform has its own design recommendations, and if you follow them, your applications have a better chance of being approved for that platform’s marketplace.

Files structure

Next, take a look at the folders and files we get in our project folder:

  • hooks folder - here you can determine callback functions for Apache Cordova to add actions to the build process
  • plugins folder - for Cordova plugins, which extend support of some mobile API’s
  • scss folder - with default Ionic styles of apps. We will use this to customize our app
  • www folder - here are all the AngularJS app files, and our main working directory. Inside this folder we have the js folder, to keep all application files - in our case this includes apps, controllers and services; and the lib folder, for ionic core - this includes Angular with a few additional modules
  • templates folder - to keep assets of each app view
  • index.html file - which is the starting point of the app

Tabs definition

Our framework uses Angular UI Router to handle all application routes. We’ll change the default one in the config method of our app, in the app.js file, to define the routes that we need.

  • gist link - seems to be missing - verify where this link should go?

Here we define an abstract tabs route, which means that this element will have only a template without its own path. We define the following states:

  • Tab - Routes are children of tabs
  • Categories - will show list of all non-empty categories
  • Category - page that displays all articles related to that category
  • Articles - tab that shows a list of all posts, sorted by newest first
  • Article details - full post content of an article

Article detail pages and category articles contain the same content. They will each show full article content with comments; we define them twice to ensure smooth navigation for each path, from all articles to article details and from categories to article details, but we define one template for them. So, we will see the same result but the path to it will be different, depending on how we navigated to the article page.

Finally, we define the default path for our app, which will be the first view that users will see after it launches. Also, we define controllers for each route, which will keep all logic for pages.

Controllers creation

We should create empty controllers for now to avoid application errors; we’ll write the controller functionality later.

gist link

We set $stateParams provider for Category and Article details controllers that will catch ids of the source that we need; this is very easy to do with UI Router. Also, we passed Categories and Articles entities that will be an Angular service, helping us load data from the remote Drupal REST server and giving us the ability to use it in our views.

Services formation

We don’t have any RESTful services to grab data from, so as we do with controllers we will define clear services. In the next part we will configure REST on our Drupal website.

gist link

In general, we created Categories and Articles factories that have all get methods, that give us an ability to get all categories or articles, or only one by its ID. We post the ID parameter to the factory from controllers with the help of the UI Router. Endpoint variables are empty for now. This service will only make a request to our server and return promises; all logic and data transformation will located in controllers.

Adding templates

Finally, we will create templates for all application pages inside our templates folder: article-detail.html, category.html, tab-articles.html, tab-categories.html and tabs.html. Ionic comes with Ionicons - this is the icon pack for apps, so I set icons for our tabs.

gist link

gist link

gist link

gist link

gist link

Now you can check that it works in browser - just run “ionic serve”.

We get a starter point to show blog data.

You can clone and try all this code from my github repository, and to get code just from this part, checkout to the part1 branch by running “git checkout -f part1”.

Check back in tomorrow for the next part of the series when we look at Framework and Drupal back end configuration.


Fill out the form to learn how FFW can support your needs.

Read next:


Building Native Apps - Part 6


Building Native Apps - Part 5


Building Native Apps - Part 4


Building Native Apps - Part 3