Apps is a module that can be looked at as a subsequent step in the evolution of features. It appears friendlier and more acceptable as a tool you can use for adding new capacities to the site. One can fulfill such additions without any damage to usability and, as it is, Apps module as an everyday tool is bound to be intelligible both for a power Drupal developer and a standard user. It's definitely easy and fun: with use of this module (Install app) your clients will, from now on, be able to ship the new functional just with one klick.
Apps is likely to remind a standard user of chrome web store whereof one can select the required CommerceBox-related "add-on" (its standard version). Note that apps is made up of two parts - the server side and the client side. The client side displays the list of all applications that can be installed and additionally informs a user of the newest updates. The server side is provided by the appServer module. It is into getting the JSON object that contains data on every app (names, ratings, versions etc.) of the client side. Let us investigate the above in detail.
Server Side Set Up
As discussed, appServer module is in charge of the server side and with it, you can get the apps adjusted via UI. It also creates a Server Type taxonomy dictionary as well as two content types, App Release and App. Below, we are going to give you an idea of what they are for.
The server in the Server Type dictionary of taxonomy having been installed, there can be created a term which will be accepted for a kind of server to be indicated on the client side.
The app proper is formed with use of the App Release like node, and it is set up through filling in the fields, such like Name (required), Changelog, Logo, Screenshot, Manifest, Server type. While the fields Name (required), Changelog, Logo, Screenshot are quite explicit and save explanations, the most important events happen in Manifest. To have it compiled, we suggest you may look through the OAS (Open App Standarts).
To be going on with we have to penetrate into the mechanics of apps creation: besides the modules to be downloaded and installed (known as Dependencies in the manifest), we have to also indicate the custom module (known as downloadable and machine_name in the manifest), which will enlist all Dependencies designated in the manifest. In fact, this is the only one module to become activated and when installing the app on the client site, yet inasmuch as it contains dependencies on other modules, the rest of the modules will get activated automatically.
Let us have a try of the following example to analyze the manifect:
name = Test content description = Creates test content machine_name = app_test_content version = 1.0 downloadable = app_test_content 1.0 author = internetdevels author_url = //internetdevels.com dependencies[test_content] = test_content 7.0 downloadables[test_content 7.0] = http://example.com/commercebox_test_content.tar.gz downloadables[app_test_content 1.0] = http://example.com/drupal_app/app_test_content.tar.gz libraries[test_libery] = test_libery 7.0 downloadables[app_test_content 1.0] = http://example.com/drupal_app/app_test_content.tar.gz
whereof:
name: our app's name;
description: app's description;
machine_name: our custom module machine name (downloadable). The module folder will be searched up by this name as well as .module file;
version: the app's version number, which will be displayed on the "Details" page;
downloadable: the key in the module array that is in charge of the correct download of the module described in the machine_name;
author: app's author name;
author_url: reference to the author page;
dependencies[key]: the downloadable modules data array, key - module's machine name, the value being the key to the downloadable array;
libraries[key]: downloadable libraries' data array, key — the library name, the value being the key to the downloadable array;
downloadables[key]: the downloadable elements array, key - the key defined in the dependencies, libraries, downloadable, the value being a link to the downloadable archive.
It's worth noting that, like in the instance of 7.x-1.0-beta7 version of the module, when writing out dependencies[test_content] = test_content 7.0 in the manifest you come to omit putting in the gap between the name and the version, that will through up an error message due to failing of the module search; once a space has been put in place, though, it gets the whole thing going.
As it is, we have completed the server adjustment. You may have noticed that there is another content type created by the above module - App - which takes care of the banner wherein the recommended app will be displayed. We have particularly focused on the Machine Name field in it. Here we state the machine name which we indicated in the manifest, and there in the releases field the node's name should be indicated, the one which was created in the App Release. The app that we have created will, thereafter, pop up in the taxonomy term (in the Featured App field) to be designated as the recommended one.
Well, the server is complete now. Access the /app/query/%tid page in which %tid is your taxonomy term number. If everything's done right, you are to have displayed the page containing the JSON array of your app, and thus you can proceed to setting up the client side for further processing of the above.
Setting up the client side
The client side setting comes down to writing out hook_apps_servers_info:
function test_apps_servers_info() {
$info = drupal_parse_info_file(drupal_get_path('module', 'test') . '/test.info');
return array(
'first' => array(
'title' => 'Test app',
'description' => 'Let’s test app',
'manifest' => 'http://example.com/app/query/3', // ссылка на ранее созданый вами сервер.
),
);
}The above described engine has been implemented on the basis of CommerceBox distribution package. Those who are keen on accessing the inside of the apps are free to download and install them, so as to 'put a face on a name' and get a better idea of them.