Let's Build Some Drupal Apps

Why We Should Build Drupal Apps

A Drupal app takes the functionality from a group of modules or features, wraps it up in a meaningful and extremely user-friendly fashion, and then makes sure it plays well with other apps. Since it can be powered by modules and features, a Drupal app includes all the right roles and permissions, as well as content types, taxonomies, views, settings and blocks, resulting in a one-click installation and an enhanced user experience. Sweet, huh? See The Value of Drupal Apps if you need more convincing that apps are the way to go.

Let's walk through, step by step, how to build an app.

Requirements

• You will need the apps module to run apps on your Drupal website.
• You will need to have some experience building modules and using features.
• You will need to have a well-defined problem, audience, and solution.

Key Concepts

Before we start, let's review a few key concepts.

Feature: A feature is a Drupal module that provides a collection of Drupal entities, which, taken together, satisfy a certain use case. A feature module differs from a standard Drupal module in several ways:

• A feature is built to target one or more use cases - concrete, task-specific functionality - not to address a general problem space.
• The bulk of a feature's work is to provide exported configuration, either in the form of exportables or scripted configuration of components.
• A feature provides no API of its own. All custom code and hooks it implements are targeted at addressing user experience and use cases.

App: An app is:

• An installable package that solves a concrete task 
• A piece of packaged functionality that delivers a polished user-friendly solution for a specific need in a specific niche or market
• A bundle of functionality (modules, features, and themes), along with some simple additional code, that publishes the existence of the app to the rest of the app infrastructure (all the other functional pieces on your web application)

An app differs from a module or feature in several ways:

• The app includes additional polish: end-user UI, configuration UI, sample content, and documentation.
• Modules and features are usually meant to be used by developers and provide building blocks for larger functionality. Apps, on the other hand, are meant to be used by the end-user (that is, someone who is setting up a Drupal website). 
• Apps are larger blocks of completed functionality.

Product: A collection of apps might be seen as a full product, just as a collection of modules and features might be seen as a distribution. Unlike a distribution or product, one app solves only one specific problem.

Plan Your Work, Work Your Plan

Plan your app:

1. Define the problem.
2. Define the audience.
3. Define the solution.
4. Contact the OpenPublic team to discuss inclusion of your app, making it visible to the world.

Build your app:

1. Identify contributed modules to use. 
2. Identify components you need to build. 
3. Identify what can be contributed back to drupal.org. 
4. Build the app's main module. (Details below.)

Package your app:

1. Prepare the app for distribution.
2. Build the configuration page.
3. Build default content.
4. Test your app.  

Getting Started

Make sure you checked every item in the checklist:

• Does it solve a specific, discrete problem?
• Does it solve a problem for a specific audience?
• Does it solve the problem completely?
• Can you describe it in a minute or less?

Now you can go ahead and build a module with the "custom" pieces and any dependencies. While you are building your main app module, bear in mind that: it must be kit compliant (http://dgo.to/kit), it should be based on features, and it must implement the hook_apps_app_info.

Build checklist:

• Did you seek out existing modules?
• Did you contribute back new modules to drupal.org?
• Is it kit compliant?
• Does it address the defined use cases?  

Now that you have your app's components built, it's time to package up the assets. Here's how:

1. Gather assets:
   1. Screen shots
   2. Icon
   3. Description
   4. Contributor information
2. Build a directory for all of the parts and add everything to it.
3. Create the manifest.app file.
4. Implement hook_apps_app_info.

Samples

Sample manifest.app file:

name = Test App
description = Test App is used to show how apps work
machine_name = test_app
version = 1.0
downloadable = test_app 1.0
author = Your Company Name
author_url = http://www.your-company-website.com
screenshots[] = screenshot.jpg
screenshots[] = screenshot2.jpg
logo = logo.png
dependencies[views] = views 3.0-beta3
dependencies[ctools] = ctools 1.0-alpha4
libraries[arc] = arc
downloadables[arc] = http://github.com/semsol/arc2/zipball/v2.0.0
downloadables[views 3.0-beta3] = http://ftp.drupal.org/files/projects/views-7.x-3.0-beta3.tar.gz
downloadables[ctools 1.0-alpha4] = http://ftp.drupal.org/files/projects/ctools-7.x-1.0-alpha4.tar.gz
downloadables[test_app 1.0] = http://ftp.drupal.org/files/projects/test_app-7.x-1.0.tar.gz

Sample hook_apps_app_info: 

In order to provide a more integrated experience to the app console, your app should implement hook_apps_app_info. This module allows you to describe certain aspects of your apps functionality to the app console. This hook is to return an array with the following information:

function test_app_apps_app_info() {
  return array(
    'demo content description' => 'This tells what the App demo content will do.
      It is placed on the configure form along with the mechanism for enabling/
      disabling the demo content.'
    'demo content module' => 'The preferred way for an app to provide demo content
      is to have a module that, when enabled, will add demo content, and when disabled
      will remove demo content. This module should be a submodule of the App but it
      is not required. If it is not a submodule of the main App module it should be
      part of the manifest dependent modules.
    'demo content enabled' => 'If demo content is provided as part of an existing 
      module, then this will be the function call that should return TRUE if demo
      content is currently enabled, FALSE otherwise.
    'demo content enable' => 'If demo content is provided as part of an existing 
      module, then this will be the function call that will enable/install the demo
      content and should return TRUE if it was successful.
    'demo content disable' => 'If demo content is provided as part of an existing 
      module, then this will be the function call that will disable/uninstall the 
      demo content and should return TRUE if it was successful.
    'configure form' => 'This should be a function that will return a Form API (FAPI)
      array that will be rendered in the Apps\' App Console configure form.
    'post install callback' => 'This will be a function that will be called after the
      App is enabled initially or if the app has been uninstalled.'

Voilá, your app is ready. Well, almost. Time to put some finishing touches that will help people know about your grand contribution to the Drupal applications.

Finishing Touches

Publicize your app:

1. Put it somewhere:
   Drupal.org or some other location.
   Create a project on d.o for it and add all of your content.
   Tag on d.o for distributions, apps, etc.
    
2. Submit the app.

More Details

• You should really read Karen Borchert's How to Build an App.
• Check out this apps presentation from Drupalcamp Atlanta.