<commit_before>/*
 * USER: mslm
 * DATE: 3/27/17
 */

package com.gedder.gedderalarm.model;


/**
 * The engine goes through the following pipeline:
 *
 * <ol>
 *     <li>Get as input (Origin, Destination, Arrival Time, Prep Time, Upper Bound Time).</li>
 *     <li>Generate a URL to query Google Maps API with the above parameters in some fashion.</li>
 *     <li>Query Google Maps API using the URL.</li>
 *     <li>Store the response JSON for analysis.</li>
 *     <li>Analyze the response JSON and take action.</li>
 * </ol>
 *
 * After analyzing the response JSON, it may do nothing. That is only if there is no delay and no
 * significant change in the duration of the total trip. In short, it will do nothing if the user
 * won't be late given the current alarm settings.
 *
 * If the engine's analysis implies lateness under the current settings, it adjusts the alarm for
 * which it's working under the hood. This may mean that the alarm will trigger immediately, or
 * that the alarm is set for a time earlier than originally planned. Note that as this feature
 * is unpredictable (since delays are unpredictable), there may be several occasions where the
 * engine self-adjusts backwards.
 *
 * The engine may adjust the alarm forward, but never past the <b>upper bound</b>, as per the user's
 * wish.
 *
 * No matter what action it takes, the engine will set itself up to flow through the pipeline again
 * for some time in the future, if that time is not past the planned alarm time. It'll then re-
 * analyze the response from Google Maps API, determining if there is <em>then</em> any delay,
 * and again take appropriate action.
 *
 * Each time the engine sets itself up for a future flow through the pipeline, it checks how close
 * it is to the currently planned alarm time. The closer it gets, the more often it queries for
 * updates on traffic and possible delays.
 *
 * In this way, the engine ensures it's awake and aware of any delays at all times, and it becomes
 * increasingly active near the planned alarm time, when delays are the most fateful to lateness.
 */
public final class GedderEngine {
    private static final String TAG = GedderEngine.class.getSimpleName();

    private GedderEngine() {}
}
<commit_msg>Rewording of the GedderEngine javadoc.<commit_after>/*
 * USER: mslm
 * DATE: 3/27/17
 */

package com.gedder.gedderalarm.model;


/**
 * The engine goes through the following pipeline:
 *
 * <ol>
 *     <li>Get or reuse as input (Origin, Destination, Arrival Time, Prep Time, Upper Bound Time)
 *     to query Google Maps API.</li>
 *     <li>Generate a URL to query Google Maps API with the above parameters in whatever
 *     fashion befits the URL requirements or the engine's requirement for certain information.</li>
 *     <li>Query Google Maps API using the generated URL.</li>
 *     <li>Store the response JSON for analysis.</li>
 *     <li>Analyze the response JSON.</li>
 *     <li>Decide on what to do.</li>
 * </ol>
 *
 * After analyzing the response JSON, it'll determine what action to take. It may do one of the
 * following:
 *
 * <ul>
 *     <li>Reschedule itself to flow through the pipeline for some default set time in the
 *     future.</li>
 *     <li>Reschedule itself to flow through the pipeline for some adjusted time in the future.</li>
 *     <li>Trigger the alarm.</li>
 * </ul>
 *
 * In the first case, the engine sees no reason for concern, and just carries on rescheduling
 * itself for future analysis at some default rate.
 *
 * In the second case, the engine picks up a possible delay, but it is not urgent enough that
 * the user needs to wake up right now. It'll reschedule itself for future analysis, but at a
 * tighter bound (how much tighter depends on the severity of the delay relative to the "wish"
 * alarm time).
 *
 * In the last case, the engine makes the decision to wake the user up right now: it caught a delay
 * significant enough that if the user doesn't take action now, they'll be late to their
 * destination.
 *
 * Each time the engine sets itself up for a future flow through the pipeline, it checks how close
 * it is to the currently planned alarm time, or the new predicted alarm time in case of a delay.
 * The closer it gets, the more often it queries for updates on traffic and possible delays. This
 * carries on until the engine cannot make any more room for future analyses, and must trigger the
 * alarm earlier than expected, because the delay isn't going away.
 *
 * To sum, the engine can either reschedule itself for a default rate of analysis, or a tighter
 * rate, or trigger the alarm, all depending on information it has previously received and analyzed.
 *
 * In this way, the engine ensures it's awake and aware of any delays at all times, and it becomes
 * increasingly active when there's a concern, i.e. when delays are present.
 */
public final class GedderEngine {
    private static final String TAG = GedderEngine.class.getSimpleName();

    private GedderEngine() {}
}

{'fraction_non_alphanumeric': 0.07118576284743051, 'fraction_numerical': 0.001999600079984003, 'mean_word_length': 3.5349048050770624, 'pattern_counts': {'":': 0, '<': 41, '<?xml version=': 0, '>': 41, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2891727', 'n_tokens_mistral': 1354, 'n_tokens_neox': 1291, 'n_words': 743}