npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

alloyxl

v1.0.4

Published

A Titanium Alloy JavaScript library that enhances Alloy.

Downloads

15

Readme

AlloyXL

Better controller management and workflow for Appcelerator Titanium Alloy MVC framework.

Why?

I build a lot of apps where I use Alloy MVC. In developing apps I end up requiring some additional functionality when it comes to using controllers for example:

  • cleaning up after a controller / view is closed
  • knowing when a view is opened / closed and acting on it
  • accessing controllers globally across the app
  • analytics / logging

The Old Way

So previously I’d end up writing code to clean up a view / controller within say, a close function associated with hitting back or close button, like this:

function doClose() {
    $.getView().close();
    $.destroy();
    $.off();
}

This is fine when you handle the event of closing a controller / view — but if you’re using say, a Navigation Window or TabGroup and you’re using the default behavoir of the back button, then this code wouldn’t run. You’d have to associate code with the “close” event on the Window.

(All of this led to lots of templated code in controllers, repeative code and could end up with some views being closed outside of the code I was writing and so the clean up wouldn’t happen.)

A New Way - Using AlloyXL

The idea behind AlloyXL was to tackle this at the source, by overriding the Alloy.createController method, I could do all this at source, ensuring that every controller is created in the same way, without changing any other code.

The main things I wanted to achieve with AlloyXL were:-

  • Providing open / close events on Window views
  • Cleaning up memory after a controller is closed
  • Reduce code throughout the app
  • Allow access to controllers globally like Alloy.Collections

Quick Start

Wherever you want to initialise the API interface, put this (ideally this should go in your alloy.js file):-

require("alloyXL");

(note you don’t have to assign it to a variable)

If you want to set some options you can do:-

require("alloyXL").options({
    debug: false, // turns off debug messages in ENV_DEV
    touchTimeout: 250 // disables a view when clicked for X ms to prevent double taps (default 750)
});

Once done, AlloyXL will automatically override the Alloy.createController method adding the following:

  • open and close events for Windows / Navigation Windows and TabGroups
  • a “once” event handler
  • global access to the controller from Alloy.Controllers.name_of_controller
  • model / collection, event and pointer clean up on close
  • debug messages on open, close, cleanup and postlayout (if debug = true -- the default)

So, you can do something like this:

(where the view we’re in is a Navigation Window or TabGroup and “subview” is a Window)

$.getView().openWindow(Alloy.createController("subview").on("open", function(){
    Alloy.Controllers.subview.getView().setBackgroundColor("#F00");
}).getView());

In this example, without creating any local pointers to the controller or view, we’re responding to the open event on the window, and setting the background color of the view to red.

You can also combine this with Alloy event chaning:

$.getView().openWindow(Alloy.createController("subview").on("open", function(){
    Alloy.Controllers.subview.getView().setBackgroundColor("red");
}).on("anotherEvent", function(){
    // handle the anotherEvent here -- you have to fire this yourself
}).once("oneTime", function(){
    // this event will only ever fire once -- you have to fire this yourself
}).getView());

Because AlloyXL is intercepting and overriding the Alloy.createController method, it’s able to do all this at the source, ensuring that everything is cleaned up afterwards!

Same name controllers conflicts

The Alloy.Controllers object stores the last instance to a controller — so normally, if you’re creating controllers with different names it’s all fine — however if you create two instances to a controller at once, only the last one is in Alloy.Controllers.

If you have two controllers having the same names but located in different folders (app/controllers/registration/index.js and app/controllers/home/index.js for example), this will cause a conflict within AlloyXL.

However, you can avoid this issue by either using different and unique names for all of your controllers or by using a unique ID on the top parent <NavigationWindow>, <Window> or <View> within your controllers and use it as the controller name within AlloyXL:

File: app/views/registration/index.xml

<Alloy>
    <View id="myUniqueID">
    </View>
</Alloy>
// Now access the controller using
Alloy.Controllers.myUniqueID;
// instead of
Alloy.Controllers.index;

Global event handlers

AlloyXL introduces a global event handler at Alloy.App — in order to use this you can trigger an event from anywhere the app and then handle this using the Alloy.App object.

So:

Alloy.App.trigger("logout");

Could be used to logout of the app anywhere and could be picked up by:

Alloy.App.on("logout", function(){
	// do your log out here
});

You could even pass callbacks or other functions around events so you could handle say the logging out of a user (or an invalid API token), sending them back to a login screen.

Taking the advantage of overriding controllers

By applying the above, you can easily override a controller already instantiated within Alloy.Controllers, no matter what.

This is very useful for <NavigationWindow> if you want to re-use the same “ID” or controller name across your project. Here is a simple example:

File: app/views/login.xml Login screen

<Alloy>
    <NavigationWindow id="navigationWindow">
    ...
    </NavigationWindow>
</Alloy>

File: app/views/home.xml Home screen once connected

<Alloy>
    <NavigationWindow id="navigationWindow">
    ...
    </NavigationWindow>
</Alloy>

File: app/views/welcome.xml Welcome window displayed no matter if you’re logged in or not

<Alloy>
    <Window>
    ...
    </Window>
</Alloy>
// This will work no matter if the controller used is login or home.
Alloy.Controllers.navigationWindow.getView().openWindow(
    Alloy.createController("welcome").getView()
);

License