@maccesar/titools 5.2.5 → 5.4.0

package/skills/alloy-guides/references/CONCEPTS.md

@@ -1,171 +1,36 @@
-# Alloy Concepts
+# Alloy concepts and project structure
 
-## Overview
+Alloy is Titanium's MVC framework. A screen normally has an XML view for structure, a TSS file for style and a JavaScript controller for behavior. Alloy compiles them into ordinary Titanium JavaScript before the native build; the underlying Titanium API remains available.
 
-This guide covers the important concepts related to the Alloy framework, including the model-view-controller framework, convention-over-configuration design, widgets, and built-in support from Backbone.js and Underscore.js.
+Install Alloy separately with `npm install -g alloy`. Use Alloy for applications with several screens, shared styles, reusable controllers/widgets or persistent models. Classic is plain Titanium JavaScript and suits prototypes or small tools. `alloy new` converts an existing Classic project in place.
 
-## Model-View-Controller
+## Files and ownership
 
-Alloy uses the model-view-controller (MVC) pattern, which separates the application into three different components:
+| Path | Purpose |
+| --- | --- |
+| `app/views/index.xml` | Initial XML hierarchy |
+| `app/styles/app.tss` | Styles shared across the app |
+| `app/styles/index.tss` | Styles for `index.xml` |
+| `app/controllers/index.js` | Initial controller behavior |
+| `app/models/` | Backbone model definitions and collections |
+| `app/widgets/` | Reusable components |
+| `app/lib/` | Plain CommonJS modules |
+| `app/assets/` | Images and `semantic.colors.json` |
+| `app/platform/` | Files copied into the native project |
+| `app/themes/` | Build-time themes |
+| `app/alloy.js` | Initializer, before the first controller |
+| `app/config.json` | Application settings and compiler configuration |
+| `plugins/ti.alloy/` | Compiler hook installed by `alloy new` |
+| `tiapp.xml` | App identity, SDK, native configuration and deployment targets |
+| `Resources/` | Generated output; never edit it |
+| `build/` | Generated native project and compiled output |
 
-* **Models** provide the business logic, containing the rules, data and state of the application
+Assets are referenced relative to `app/assets`: `app/assets/images/logo.png` becomes `images/logo.png`. Use `app/assets/android` and `app/assets/iphone` for platform-specific assets; only the matching assets enter the package. Native files under `app/platform` are copied without processing.
 
-* **Views** provide the GUI components to the user, either presenting data or allowing the user to interact with the model data
+Commit source, assets, `tiapp.xml` and `DefaultIcon.png`. Do not commit `build/`, generated `Resources/`, or top-level `platform/` and `i18n/` in an Alloy project. `alloy new` writes their ignore rules. Keep keystores and signing credentials out of the repository.
 
-* **Controllers** provide the glue between the model and view components in the form of application logic
+The Classic template's initial `Resources/app.js` can remain after conversion; subsequent Alloy builds replace generated output. Do not change it to implement an Alloy screen.
 
-For example, in a calendar application, the models include events, reminders, invitations, and contacts. The views present the calendar data and reminders to the user or allow the user to add events. For reminders, the controller checks the model data and launches a 'reminder' view to the user. For adding events, the controller opens an 'add event' view, then adds the event into the model data once the user entered the data.
+For app identity, native permissions and signing, use `ti-guides`. For the view/controller/style relationship, read [XML views](./VIEWS_XML.md), [styles](./VIEWS_STYLES.md) and [controllers](./CONTROLLERS.md).
 
-An advantage of MVC is the ability to reuse code by separating the functionality. For example, you can have specific views for different devices, while keeping the controller code relatively the same and the model data unchanged.
-
-### Alloy: MVC with Backbone
-
-Backbone.js is a lightweight MVC framework, originally designed for web applications. Alloy models are built on top of Backbone.js, taking advantage of Backbone's rich Model and Collection APIs. You define models using a Javascript file that exports a special JSON object, which uses Backbone's extend functionality to customize models and collections.
-
-Alloy views are built from Titanium UI components. You define views using XML markup and style them using Alloy _Titanium Style Sheets (.tss)_, which abstracts the creation of these components without using Titanium API calls. Alloy generates the code to create your views.
-
-Alloy controllers generally have a one-to-one relationship with Alloy views. Controllers directly use the Titanium SDK API without an abstraction layer. The controller has access to all of the view components.
-
-Also, Alloy provides built-in support for Underscore.js, which provides a set of utility functions, such as array and iterative helpers.
-
-## Alloy and the Titanium SDK
-
-Alloy uses Titanium SDK to abstracts the creation of UI components through the use of XML markup and style sheets. If Alloy has not implemented a feature of the Titanium SDK or if the feature is not UI related, you can always use the Titanium SDK API in the Alloy controller code or create a CommonJS module to implement a feature. The table below lists what Alloy directly abstracts from the Titanium SDK.
-
-For assets, such as images, any references to the `Resources` folder in the Titanium SDK documentation should be replaced with the `app/assets` folder to use it for Alloy. For example, the Icons and Splash Screens guide tells you to place files in either the `Resources/android` or `Resources/iphone` folder. For Alloy, the files should be placed in either the `app/assets/android` or `app/assets/iphone` folder.
-
-### Titanium SDK to Alloy Mapping
-
-| Titanium SDK Component                                                                  | Alloy Component                                                                                                                                               |
-| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Titanium.UI.\* Objects** (and others: `Ti.Android.Menu`, `Ti.Facebook.LoginButton`, `Ti.Map`, `Ti.Media.VideoPlayer`) | **XML element**. Remove the namespace. For some elements, you may need to assign the `ns` attribute. Some objects are implicitly assigned namespaces by Alloy. |
-| `Titanium.UI.createButton();`                                                           | `<Button />` creates a button                                                                                                                                 |
-|                                                                                         | **TSS element**. Remove the namespace.                                                                                                                        |
-|                                                                                         | `"Button":{ /* Button attributes */ }`                                                                                                                        |
-| **Titanium Object properties**                                                          | **XML attribute** if the property can be expressed as a string, number or Titanium SDK constant.                                                              |
-| `Titanium.UI.createButton({text: "Foobar", top: 0, width: Ti.UI.SIZE});`                | `<Button title="Foobar" top="0" width="Ti.UI.SIZE"/>`                                                                                                         |
-|                                                                                         | **TSS attribute** if the property can be directly expressed as a string, number, Titanium SDK constant, dictionary or array. Indirectly, you can assign a method or value to the `Alloy.Globals` or `Alloy.CFG` namespace and reference it in the TSS file. |
-|                                                                                         | `"Button":{ title: "Foobar", top: 0, width: Ti.UI.SIZE }`                                                                                                     |
-| **Titanium Object properties (proxy)**                                                  | Some properties that take Titanium objects can be expressed inline using XML tags (Property Mapping). See [VIEWS_XML.md](./VIEWS_XML.md#property-mapping).     |
-| **Titanium Object methods**                                                             | Use in the controller code. You need to define the `id` attribute of the object in the XML markup, so the object can be referenced in the controller.         |
-| `const button = Titanium.UI.createButton(); button.setTitle('Push Me!');`               | `// Need to give the object an ID: <Button id="button" />` then `$.button.setTitle('Push Me!');`                                                              |
-| **Titanium Object events**                                                              | XML attribute to bind a callback in the associated controller. Capitalize the first character of the event name and append 'on' to the beginning of the name. |
-| `const button = Titanium.UI.createButton(); button.addEventListener('click', doClick);` | `<Button onClick="doClick"/>` (doClick needs to be declared in the associated controller)                                                                     |
-
-## Convention over Configuration
-
-To simplify development, Alloy uses a directory structure and naming conventions to organize the application rather than configuration files. Alloy expects to find files in specific locations. Any folder or file not adhering to the below naming conventions is ignored by Alloy. For example, at generation time, Alloy will look for the mandatory files `app/views/index.xml` and `app/controllers/index.js`, then the optional corresponding file `app/styles/index.tss`. Alloy requires these files to create the initial view-controller `Resources/<platform>/alloy/controllers/index.js`.
-
-The following is a list of directories and files that can be found in an Alloy project:
-
-| Directory/File    | Description                                                                                                                                                                                                                                                                                 |
-| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `app`             | Contains the models, views, controllers and assets of the application. All work should be done here.                                                                                                                                                                                        |
-| `app/alloy.jmk`   | Build configuration file. See Build Configuration File (alloy.jmk).                                                                                                                                                                                                                         |
-| `app/alloy.js`    | Initializer file used to preconfigure components or override Alloy methods before the main controller is executed.                                                                                                                                                                          |
-| `app/config.json` | Project configuration file. See Project Configuration File (config.json).                                                                                                                                                                                                                   |
-| `app/assets`      | Contains image assets and other files that need to be copied into the `Resources` directory. Reference these files in the code without the 'app/assets' path (and without the platform-specific folder if it is inside one).                                                                 |
-| `app/controllers` | Contains controllers in the format `filename.js` to a corresponding view file `app/views/filename.xml`.                                                                                                                                                                                     |
-| `app/i18n`        | Since Alloy 1.8.0 and Titanium 5.2.0 Language Strings are sourced from `app/i18n` and Alloy will generate the `i18n` folder in the project root.                                                                                                                                            |
-| `app/lib`         | Contains application-specific library code, typically in the CommonJS format.                                                                                                                                                                                                               |
-| `app/migrations`  | Contains database migration files in the format `<DATETIME>_filename.js`. See Migrations for more information.                                                                                                                                                                              |
-| `app/models`      | Contains model files in the format `filename.js`.                                                                                                                                                                                                                                           |
-| `app/platform`    | Since Alloy 1.8.0 platform resources are sourced from `app/platform` and Alloy will generate the `platform` folder in the project root.                                                                                                                                                     |
-| `app/specs`       | Like the `app/lib` folder except it is only used if the deploy type is **not** production (since Alloy 1.2.0).                                                                                                                                                                              |
-| `app/styles`      | Contains view styling in the format `filename.tss`, which is applied to a corresponding view file `app/views/filename.xml`.                                                                                                                                                                 |
-| `app/themes`      | Contains themes to customize the assets and styles of the entire GUI.                                                                                                                                                                                                                       |
-| `app/views`       | Contains views in the format `filename.xml` with the optional corresponding files `app/controllers/filename.js` and `app/styles/filename.tss`.                                                                                                                                              |
-| `app/widgets`     | Contains widget files. Each widget will have its own `app`-like directory structure.                                                                                                                                                                                                        |
-| `i18n`            | Since Alloy 1.8.0 and Titanium 5.2.0 Language Strings are sourced from `app/i18n` and Alloy will generate the `i18n` folder in the project root. Before Alloy 1.8.0, the `i18n` folder was managed in the project root directly.                                                            |
-| `Resources`       | Contains the Titanium files generated by the Alloy interface from the `app` directory. All files will be overwritten each time the application is built. Since Alloy 1.3.0, Alloy creates a separate Titanium project for each platform you build for in the `Resources/<platform>` folder. |
-
-**Notes:** the `lib`, `migrations`, `themes` and `widgets` folders are not automatically generated when creating a new project. The `migrations` and `widgets` folder will be generated by the Alloy command-line interface if any of those components are generated. The `lib` and `themes` folders will need to be manually created.
-
-The `alloy.jmk` file is not automatically generated when creating a new project. Use the command-line interface to generate this file.
-
-### Platform-Specific Resources
-
-Controllers, views and styles can have platform-specific resources. Just add a folder named `android` or `ios` under the component folder and add your platform-specific files for Android or iOS into the folder, respectively.
-
-For example, an iOS-specific view and an Android-specific controller would look like this:
-
-```
-app/
-├── controllers/
-│   ├── android/
-│   │   └── index.js
-│   └── index.js
-└── views/
-    ├── ios/
-    │   └── index.xml
-    └── index.xml
-```
-
-Alternatively, you can use special conditional code and attributes inside the controllers, views and styles to apply platform-specific code and components.
-
-Also, the `assets` folder is laid out the same way as the `Resources` folder in a Titanium project for platform-specific files and density-specific images.
-
-## Widgets
-
-Widgets are self-contained components that can be easily dropped into Alloy-powered Titanium projects. They were conceived as a way to reuse code in multiple applications or to be used multiple times in the same application. Widgets have their own models, views, controllers, styles and assets and are laid out the same as the `app` directory in the Alloy project.
-
-* For information on using widgets in a project, see Importing Widgets.
-* For information on creating widgets, see Creating Widgets.
-* To search publicly available widgets, visit gitTio.
-
-## Builtins
-
-Alloy comes with additional utilities used to simplify certain functions, such as animations, string manipulation, and display unit conversion. These utilities are referred to as 'builtins.' To use these utilities, the controller needs to call `require` with 'alloy' as the root directory. For example, to use an animation function to shake the current view by pressing the 'shake' button:
-
-```javascript
-const animation = require('alloy/animation');
-$.shake.addEventListener('click', e => {
-  animation.shake($.view);
-});
-```
-
-## Compilation Process
-
-This section provides a brief overview of how the Alloy command-line interface converts the files in the `app` folder to a Titanium project in the `Resources/<platform>` folder for each platform you build your project for. Before Alloy 1.3.0, Alloy creates only one Titanium project in the `Resources` folder.
-
-### Cleanup
-
-The `Resources` folder is cleaned of any previous built files.
-
-### Build Configuration
-
-If the build configuration file, `alloy.jmk`, exists, it is loaded. The 'pre:load' task executes at this point if it is defined.
-
-### Alloy Framework, Assets, and Lib
-
-Alloy framework files, which include the Backbone.js and Underscore.js libraries, sync adapters and base controller class, are copied to the `Resources/<platform>/alloy` folder. The Alloy base library, `alloy.js`, is copied to the `Resources` folder. These files are necessary to run any Alloy project.
-
-The project configuration file, `config.json`, is processed and copied to `Resources/<platform>/alloy/CFG.js`.
-
-The files in the `assets` and `lib` folders, as well as the files in the theme's assets folder, are copied to the `Resources` folder.
-
-The 'pre:compile' task executes at this point if it is defined.
-
-### Model-View-Controller and Widget Generation
-
-The model files are processed. The compiler creates a JavaScript file per model and copies them to the `Resources/<platform>/alloy/models` folder.
-
-The widget files are processed. The compiler creates a folder per widget that contains JavaScript files per view-controller and copies them to the `Resources/<platform>/alloy/widgets` folder.
-
-The style, view, and controller files, as well as the files in the theme's style folder and the `app.tss` global style file, are processed. The compiler creates a JavaScript file per view-controller and copies them to the `Resources/<platform>/alloy/controllers` folder.
-
-### Main Application
-
-Alloy creates a skeleton `app.js` file from a template. The contents of this file require some Alloy modules and calls the main view-controller `index.js`. If an initializer file, `alloy.js`, exists, the entire contents of the file are copied into the `app.js` file right before the call to initiate the main view-controller.
-
-Before the file is written to the `Resources` directory, the 'compile:app.js' task executes if one is defined in the build configuration file.
-
-### Code Optimization
-
-The generated code is processed through UglifyJS to optimize the code for speed and compactness. The code is optionally beautified.
-
-If the code is compiled for a specific platform, all conditional code that should not be executed for that platform is removed. For example, if the application contains code sections specifically for iOS but the application is compiled for an Android platform, all of the iOS conditional code is removed.
-
-Required Alloy builtin libraries are copied to the `Resources/<platform>/alloy` folder and optimized in the same process as described before.
-
-Then, the 'post:compile' task executes if it is defined in the build configuration file.
+Sources: [Alloy](https://titaniumsdk.com/docs/alloy.md), [project structure](https://titaniumsdk.com/docs/build/project-structure.md), [first app](https://titaniumsdk.com/docs/build/first-app.md).

package/skills/alloy-guides/references/CONTROLLERS.md

@@ -1,279 +1,81 @@
-# Alloy Controllers
+# Alloy controllers
 
-## Overview
+A controller runs when `Alloy.createController()` constructs it. XML elements with IDs are available as `$.<id>`. The top-level element uses the controller filename as its ID unless XML supplies another ID: `$.index` is therefore not guaranteed when the root has an explicit ID.
 
-This topic covers how to write controller code as well as other JavaScript files excluding models. Some traditional Titanium development is required, since Alloy controllers make direct calls to the Titanium SDK API to manipulate UI objects and access non-UI APIs.
+## Arguments and events
 
-## Controllers
-
-In Alloy, controllers contain the application logic used to control the UI and communicate with the model. The following code contains the presentation logic (`index.js`) associated with the view (`index.xml`).
-
-**app/controllers/index.js**
+Read arguments at the top of the controller, including arguments received through `<Require>`:
 
 ```javascript
-function doClick(e) {
-    alert($.label.text);
-}
-
-$.index.open();
-```
-
-**app/views/index.xml**
-
-```xml
-<Alloy>
-    <Window class="container">
-        <Label id="label" onClick="doClick">Hello, World</Label>
-    </Window>
-</Alloy>
-```
-
-All UI elements which have an `id` attribute in a view are automatically defined and available as a property prefixed by the special variable `$` in the controller. The `$` is a reference to the controller. For example, the `$.label` prefix in the controller is used to access the `Ti.UI.Label` object instance in the view. This reference is used to directly access properties or methods of this object. For example, calling `$.label.hide()` hides the label from the view or you can change the label text with `$.label.text`.
-
-To access external controllers and views, use the `Alloy.createController` and `Controller.getView` methods, respectively.
-
-If the top-level UI object does not have an ID defined, reference it using the name of the controller prefixed by the `$`. Since the Window object in the view does not contain an ID, the controller uses `$.index` to grab the top-level UI object from the view. However, if an `id` attribute was defined, for example, `<Window id='window'>`, the controller needs to use `$.window` to gain access to the Window object; `$.index` will be undefined and the application will throw an error when calling `$.index.open()`.
-
-### Events
-
-Controllers extend `BackBone.Events` and as such can dispatch events.
-
-For example, our index view could also require another controller to deliver the label and listen to an event:
-
-**app/views/index.xml**
-
-```xml
-<Alloy>
-    <Window class="container">
-        <Require id="label" src="label" onNotify="doSomething" />
-    </Window>
-</Alloy>
+// app/controllers/detail.js
+const noteId = $.args.id;
+$.title.text = `Note ${noteId}`;
 ```
 
-The view of the required label-controller would listen to the `click` event of the label itself:
-
-**app/views/label.xml**
-
-```xml
-<Alloy>
-    <Label id="label" onClick="passClick">Hello, World</Label>
-</Alloy>
-```
-
-And that label-controller would in turn fire the notify event on itself so the index controller will receive it:
-
-**app/controllers/label.js**
+Use a named top-level function for an XML event handler:
 
 ```javascript
-function passClick(e) {
-    $.trigger('notify');
+function doGo() {
+    $.greeting.text = 'Going';
 }
 ```
 
-### Inheritance
-
-Controllers can inherit from other controllers by assigning them as a base (parent) controller: `exports.baseController = 'baseControllerName'`. As in the CommonJS model, the controller inherits any exported functions from the base controller. These functions can also be overwritten.
+The view binds it with `onClick="doGo"`. See [XML views](./VIEWS_XML.md) for a complete screen.
 
-For example, the animal view-controller defines a label object with a speak method:
+## Creating and opening
 
-**app/controllers/animal.js**
+A controller is not a Window. Construct it, then open its top-level Window:
 
 ```javascript
-exports.speak = () => {
-    alert("Yelp!");
-};
-```
-
-**app/views/animal.xml**
-
-```xml
-<Alloy>
-    <Label id="animalLabel">Animal</Label>
-</Alloy>
+const detail = Alloy.createController('detail', { id: 42 });
+detail.getView().open();
 ```
 
-Then, the following code inherits from the animal view-controller and overrides the speak method and label text property to customize it for a dog controller.
-
-**app/controllers/dog.js**
+`getView()` returns the first top-level element. Alternatively, let the controller export the operation:
 
 ```javascript
-exports.baseController = "animal";
-$.animalLabel.text = "Dog";
-exports.speak = () => {
-    alert("Bark!");
+// app/controllers/detail.js
+exports.open = () => {
+    $.detail.open();
 };
 ```
 
-### Conditional Code
-
-Alloy introduces a set of special variables that act like compiler directives. Using these compiler constants optimizes the code at generation/compilation and any non-reachable code is removed.
+The caller uses `detail.open()`. Do not also open the Window at controller top level: the two approaches would open it twice. Anything on `exports` is exposed on the returned controller.
 
-The following are the constants defined by Alloy for use in the controller code:
+## Cleaning up
 
-* `OS_ANDROID` : true if the current compiler target is Android
-* `OS_IOS` : true if the current compiler target is iOS
-* `ENV_DEV` : true if the current compiler target is built for development (running in the simulator or emulator)
-* `ENV_TEST` : true if the current compiler target is built for testing on a device
-* `ENV_PRODUCTION` : true if the current compiler target is built for production (running after a packaged installation)
-* `DIST_ADHOC` (since Alloy 1.4.0) : true if the current compiler target is built for iOS Ad Hoc distribution, for example, if you set the `-T dist-adhoc` option when building with the Titanium CLI. Note that `ENV_PRODUCTION` will be true too since this deployment is only for production builds.
-* `DIST_STORE` (since Alloy 1.4.0) : true if the current compiler target is built for deployment to the Google Play Store or iTunes App Store, for example, if you set the `-T dist-store` option when building with the Titanium CLI. Note that `ENV_PRODUCTION` will be true too since this deployment is only for production builds.
+Alloy does not automatically dispose of controllers. External listeners, timers and geolocation subscriptions can outlive the Window. Remove listeners using the same function reference, clear timers and stop subscriptions when their owner closes. `$.destroy()` removes generated model/view bindings; it does not remove your external listeners.
 
-For example, since iOS devices do not include a back button, the application can conditionally add one to a window controller:
+After completing location setup and authorization through `ti-howtos`, this illustrates listener ownership:
 
 ```javascript
-if (OS_IOS) {
-  const closeButton = Ti.UI.createButton({
-        title: 'Close'
-    });
-
-    closeButton.addEventListener('click', () => {
-        $.window.close();
-    });
-
-    $.window.leftNavButton = closeButton;
+function onLocation(event) {
+    Ti.API.info(event);
 }
-```
-
-### Passing Arguments
-
-When initializing an external controller, you can pass arguments to customize it, for instance, `const controller = Alloy.createController('controller', {args1: 'foo'})`. In the external controller, the special variable `$.args` is used to receive the arguments. Before Alloy 1.6, you needed to use `arguments[0]`. For example, suppose you want to add multiple TableViewRow objects to a TableView object.
 
-For the TableViewRow object, called 'row', the view contains only the object, and the controller contains only a few lines of code to parse the arguments:
-
-**app/views/row.xml**
-
-```xml
-<Alloy>
-    <TableViewRow id="rowView"/>
-</Alloy>
+Ti.Geolocation.addEventListener('location', onLocation);
+$.index.addEventListener('close', () => {
+    Ti.Geolocation.removeEventListener('location', onLocation);
+    $.destroy();
+});
 ```
 
-**app/controllers/row.js (Alloy 1.6+)**
+Here `index.xml` must own a Window addressed as `$.index`. A child controller without that lifecycle needs cleanup coordinated by its owner. Keep each controller's cleanup separate from any shared model still used by another screen.
 
-```
-$.rowView.title = $.args.title || '';
-$.rowView.url = $.args.url || '';
-```
+## Shared code
 
-**app/controllers/row.js (Alloy <1.6)**
+`app/lib/` contains CommonJS modules:
 
 ```javascript
-const args = arguments[0] || {};
+const format = require('/format');
 ```
 
-In a separate controller containing the TableView object, called 'tableView', the code is cycling through an array of data and creating new instances of 'row' to supply it to 'tableView.'
-
-**app/controllers/index.js**
+The slash resolves against the application root, not the filesystem. Modules are available to controllers and widgets. Initialize shared state in `app/alloy.js`, before the first controller:
 
 ```javascript
-const data = [];
-for (let i=0; i<source.length; i++) {
-    const arg = {
-        title: source[i].postTitle,
-        url: source[i].postLink
-    };
-    data.push(Alloy.createController('row', arg).getView());
-}
-$.tableView.setData(data);
+Alloy.Globals.apiRoot = 'https://example.com/api';
 ```
 
-As seen in the example above, the controller is passing different arguments to the 'row' controller, creating unique instances of 'row'.
-
-### Global Namespace
-
-Controllers can store and access global variables using the `Alloy.Globals` namespace. For example, you can store an instance of a parent window in Globals and access it in another window.
-
-Store the parent window:
-
-```
-$.index.open();
-Alloy.Globals.parent = $.index;
-```
-
-Access the parent window in another controller:
-
-```javascript
-const parent = Alloy.Globals.parent;
-parent.close();
-```
-
-Other non-controller JavaScript code can access the Globals variable but need to require the Alloy module. See [Extending Alloy](#extending-alloy-underscorejs-and-backbonejs) below.
-
-## Initializer File (alloy.js)
-
-The initializer file `app/alloy.js` can be used to execute some code near the beginning of the application's lifecycle. The contents of this file will be executed right before the initial `index.js` controller is loaded, allowing you to execute code before any UI components are loaded and to override built-in Alloy functions before they are executed. The code in this file also has access to the `Alloy` namespace.
-
-For instance, the default `isTablet` method returns true if it is identified as an iPad, an Android device in the large or extra large group, or if either dimension exceeds 400 dp for Mobile Web application. To override that behavior, you can add the following code to `alloy.js`.
-
-```
-Alloy.isTablet = () => {
-    return !(Math.min(Ti.Platform.displayCaps.platformHeight, Ti.Platform.displayCaps.platformWidth) < 600);
-}
-```
-
-## Library Code and CommonJS Modules
-
-Some JavaScript code might not be suitable as controller code, since it does not have an associated view, or you want to separate it from the MVC framework for easier reusability. Create a folder called `lib` in the `app` directory of your Alloy project. Add your CommonJS modules or JavaScript code using the CommonJS format into the `lib` folder. These files are copied to the `Resources` folder, when compiling your Alloy project.
-
-To use the library or CommonJS module, require it with the library name or module name without the 'app/lib' path and '.js' extension:
-
-```javascript
-const lib = require('library_name');
-lib.foo();
-```
-
-> **⚠️ ⚠️ Warning**
-> Titanium and Alloy do not support the Node.js concept of "folders as modules". That is, requiring a folder name does not automatically load the `index.js` or `index.json` file inside the folder, or use the `package.json` file to locate the main entry point. You need to explicitly require the file that serves as the main entry point to the library.
-
-### Specs Folder
-
-Starting with Alloy 1.2.0, you can add the `specs` folder to your project. Like the `lib` folder, use the `specs` folder to add files to your project, except the files are only used when the deployment type is **not** production.
-
-Create a folder called `specs` in the `app` directory of your Alloy project. Add your files to the specs folder. These files are copied to the `Resources` folder, when compiling your Alloy project if the deployment type is **not** production.
-
-Use the `ENV_PROD` variable to check if the application is running as a production target or not, before using the files in the `specs` folder.
-
-```
-if (!ENV_PROD) {
-    // Executes the fooFunction from the foo module
-  require('specs/foo').fooFuntion();
-}
-```
-
-### Platform-Specific Library Folders
-
-Starting with Alloy 1.5.0, you can also create platform-specific subfolders in the `lib` directory. Just add a folder named **android** or **ios** under the component folder and add your platform-specific files for Android or iOS into the folder, respectively. Do not include the platform-specific folder name when referencing the file.
-
-```
-app/
-├──lib
-│  ├──ios
-│  │   └── library_name.js
-│  └── library_name.js
-├──models
-├──styles
-└──views
-   └── index.xml
-```
-
-### Extending Alloy, Underscore.js and Backbone.js
-
-To access the Alloy API methods, such as `createController` and `createModel`, as well as Underscore.js and Backbone.js in CommonJS modules and JavaScript files in `app/lib`, you need to load those modules in to the library:
-
-```javascript
-const Alloy = require('alloy'), _ = require("alloy/underscore")._, Backbone = require("alloy/backbone");
-
-// Alloy extended
-Alloy.createController('foo').getView().open();
-
-// Underscore extended
-const even = _.find([1, 2, 3, 4, 5, 6], num => num % 2 === 0);
-Ti.API.info(even);
-
-// Backbone extended
-const Book = Backbone.Model.extend();
-const book = new Book({title: 'Ulysses', author: 'James Joyce'});
-Ti.API.info(JSON.stringify(book));
-```
+For compiler constants, use [configuration](../../alloy-howtos/references/config_files.md#compile-time-constants).
 
-Currently, these modules are automatically available in the global scope and these APIs can be used without loading the modules. Referencing these modules without loading them first with the `require` method is discouraged and this behavior may be deprecated in the future. To ensure compatibility with future releases, always use the `require` method to load and use these modules.
+Source: [controllers](https://titaniumsdk.com/docs/alloy/controllers.md).