This application allows the creation of rules to automatically dismiss alerts. Currently, alerts rules can be defined in two files:

./custom.alerts.js
./alerts.js

alerts.js contains alerts necessary for operation of the application, and is source controlled.  custom.alerts.js is optional.  It has an identical format, and its rules take precedent over alerts.js.

Alert rules are designed to be localizable, so that if you can determine the localizable key values used within iOS, the rule will apply regardless of device language.  Currently-supported keys can be found in:
Resources/IOS/Strings/*.json

Each "rule" is a JSON dictionary with following keys:
   titles:   A list of alert titles to match (if specified, one entry in the list must exactly match)
   messages: A list of alert bodies to match (if specified, one entry in the list must exactly match)
   auto:     A list of responses to try, in-order, to dismiss the matched alert
   other:    A list of known responses to the alert that will NOT be tried. (for reference only)

   tag:     Intended as a way to address and enable/disable a specific rule, but not yet used. subject to change
   sources: Names of ios processes known to generate the alert.  Original intention was more accurate rule-matching, but due to race-condition issues this field is not currently used.

One of "titles" or "messages" must be supplied to match an alert.  If both are supplied, the actual alert must have both a matching title and message.  The alert can only be dismissed if it contains a button identified by "auto".

Each entry in "titles", "messages", "auto", and "tag" is itself a list of strings.  

For lists of length >= 2, this list identifies a localized IOS string entry, using the files in Resources/IOS/Strings/*.json

The first entry identifies a named collection of strings (usually based on a framework name)
The last entry is the named-string key used by IOS within that collection to retrieve a specific string.
Intermediate entries (for length >=3), are a search path through sub-components within the initial named collection.

The example below dismisses "Broadcast Failed" alerts:
{
    "tag": "BROADCAST_FAILED",
    "sources": ["replayd"],
    "titles": [
        [ "ReplayKit", "BROADCAST_STATUSBAR_TAPPED_ALERT_TITLE" ]
    ],
    "messages": [
        [ "ReplayKit", "BROADCAST_FAILED_ALERT_MESSAGE_FORMAT" ]
    ],
    "auto": [
        [ "ReplayKit", "BROADCAST_FAILED_ALERT_OK_BUTTON" ]
    ],
    "other": [
        [ "ReplayKit", "BROADCAST_FAILED_ALERT_GO_TO_APP_BUTTON" ]
    ]
},
(note: "tag", "sources", and "other" have no effect)

To confirm precisely what the alert is going to match based on device language, a utility has been added:

 ./main exportLocalizedAlertRules

This will write rules for each language into 

./LocalizedAlertRules

Using this tool we can compare, for example, the US-English and Spanish strings for the rule defined above:

ENGLISH:
  {
    "tag": "BROADCAST_FAILED",
    "sources": [
      "replayd"
    ],
    "titles": [
      [
        "Screen Broadcasting"
      ]
    ],
    "messages": [
      [
        "Live Broadcast to %@ has stopped due to: %@"
      ]
    ],
    "auto": [
      [
        "OK"
      ]
    ],
    "other": [
      [
        "Go to Application"
      ]
    ]
  },

SPANISH:
  {
    "tag": "BROADCAST_FAILED",
    "sources": [
      "replayd"
    ],
    "titles": [
      [
        "Retransmisión de pantalla"
      ]
    ],
    "messages": [
      [
        "La emisión en vivo a %@ se ha detenido por el siguiente motivo: %@",
        "La retransmisión en directo a %@ se ha detenido por el siguiente motivo: %@"
      ]
    ],
    "auto": [
      [
        "OK"
      ]
    ],
    "other": [
      [
        "Ir a la aplicación"
      ]
    ]
  },

Note that Apple can and does change the localizations for various keys with new iOS releases.  We see in the example above that BROADCAST_FAILED_ALERT_MESSAGE_FORMAT has two Spanish localizations:
    1. "La emisión en vivo a %@ se ha detenido por el siguiente motivo: %@",
    2. "La retransmisión en directo a %@ se ha detenido por el siguiente motivo: %@"
If the actual alert matches either of these strings, it will apply.

NON-LOCALIZED ALERTS
If you only need to add ad-hoc alert handling for devices in your own language, you can create non-localized rules as well.  Just enter your string-matching patterns as single-string lists. Here is an example that ONLY dismisses BROADCAST_FAILED messages for English and Spanish:

  {
    "titles": [
      [ "Retransmisión de pantalla" ],
      [ "Screen Broadcasting" ]
    ],
    "messages": [
      [ "La emisión en vivo a %@ se ha detenido por el siguiente motivo: %@" ],
      [ "La retransmisión en directo a %@ se ha detenido por el siguiente motivo: %@" ],
      [ "Live Broadcast to %@ has stopped due to: %@" ]
    ],
    "auto": [
      [ "OK" ]
    ]
  }
( Please note, this format is not quite the same as the one dumped by the exportLocalizedAlertRules command. Each string must appear within its own array. )
	
If a string-entry has only a single element, it is treated as a literal string, rather than attempting to localize it. 

WILDCARDS:
The pattern matching system is build around the handling of native iOS NSString objects.  As such, if you want a "wildcard" to match any amount of text in a given position, use "%@". This will turn into a regex pattern: 
    /.*/

For example, in one example above, the system would match:
    /^Live Broadcast to .* has stopped due to: .*$/

More complicated regular expressions are not currently supported.
