Dev:Libactivator

libactivator is a library used to have a centralized system of activation methods for all of our jailbroken extensions. To accomplish this, the hooks of the activation methods are in one centralized MobileSubstrate plugin, that uses small bundles and preference panes to select the activation method for each plugin.

libactivator works by connecting an event (LAEvent) to one or multiple actions (LAListener). Developers can create new events or actions to extend the functionality of a device.

= Implementing a LAListener = There are three steps to follow: adding a plist, implementing the code, and allowing users to change activation methods. Optionally, you can also add a method to register your plugin for a certain event on installation, which allows you to implement libactivator without confusing prior users.

Adding a plist
Create a file in the directory  named   with the following contents:

Another plist key is requires-event.

You can put a 29x29 pixels  and   in the same directory.

Implementing the Code
Implementing the code can be done in two different methods, depending on your plugin. If you have an object that is always in memory, you can use method one, otherwise, use method two.

Method One: Add the Code
First,  and have your class implement the LAListener protocol.

To register for events, you must add a piece of code to your init method, replacing the parts as needed:

Then, you must also implement two simple delegate methods: In the first method, you should first check if your plugin is already active. If it is active, you should deactivate your plugin and return. Otherwise, just activate your plugin. In addition, in the activator:recieveEvent: method, you must call [event setHandled:YES] if you wish to disable the default OS action for that activation event. If you do not set handled then receive event may be called twice for the same event. In the second method you should simply deactivate your plugin.

The implementation of these methods is left completely up to the programmer. The LAEvent objects can be used to discover more information about the event, such as the type, if you wish to perform a different action based on the type of event. Do not use that information to disable certain types of events for your plugin!

Method Two: New Object
The second method of implementing libactivator is to insert a new class in your code, one instance of which is always initialized, and informs your main classes when an activation event has occurred (so your main plugin can activate). A sample class is provided below with placeholder comments where additional code would be needed:

Allowing Users to Change Activation Methods
The simplest method to allow users to change activation methods is if you use PreferenceLoader and a simple plist format. Then, you can just paste in this code to create a cell that when tapped will allow users to select an activation method (again replacing the package id with the correct one):

A more complex method is to integrate the settings pane directly into your app's navigation controller:

Libactivator 1.1 introduces a global preferences pane and makes neither of these methods required

Default Activation Methods
To implement default activation methods, call  before registering your listener:

Only supported in libactivator 1.1+

= Implementing a LAEvent = There are 2 steps to follow: implementing the hooks and implementing the datasource. A single class can provide multiple event sources in different groups.

Implementing the Hooks
Taking advantage of libactivator's available source code, we take this function: Then, we find an appropriate method to hook and send the event to the shared activator class so an action can take place.

Implementing the DataSource
Here's an example:

= Packaging =

The more sensible approach these days is to just include the toggles in your main item package, not have a dependency on libactivator, and then if users want to use it they just have to install the supporting tools that make it work (ie activator, at their own discretion). The additional packages are better reserved for 3rd-party items where including it in the main package is not always possible.

= Example Projects =