Вопрос о дизайне: Как Вы разработали бы систему повторяющегося события? [закрытый]
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
7 ответов
Я должен был сделать это прежде, когда я управлял концом базы данных проекта. Я запросил, чтобы каждое событие было сохранено как отдельные события. Это позволяет Вам удалять всего одно возникновение, или Вы могли переместить промежуток. Намного легче удалить кратные числа, чем попытаться изменить отдельное проявление и превратить его в два. Мы тогда смогли сделать другую таблицу, которая просто имела recurrenceID, который содержал информацию повторения.
Я запустил путем реализации некоторого временного выражения как обрисованный в общих чертах Martin Fowler . Это заботится о выяснении, когда запланированный объект должен на самом деле произойти. Это - очень изящный способ сделать его. То, с чем я закончил, было просто сборкой на том, что находится в статье.
следующая проблема выясняла как в мире для хранения выражений. Другая проблема - при чтении вслух выражения как те вписываются не так динамический пользовательский интерфейс? Был разговор просто сериализирующий выражения в BLOB, но будет трудно обойти дерево выражений для знания то, что было предназначено им.
решение (в моем случае) состоит в том, чтобы сохранить параметры, которые соответствуют ограниченному количеству случаев, которые Пользовательский интерфейс будет поддерживать, и оттуда, использовать ту информацию для генерации Временных Выражений на лету (мог сериализировать, когда создано для оптимизации). Так, класс Расписания заканчивает тем, что имел несколько параметров, любят смещение, дату начала, дата окончания, день недели, и так далее... и от которого можно генерировать Временные Выражения, чтобы сделать тяжелую работу.
Что касается наличия экземпляров задач, существует 'сервис', который генерирует задачи в течение дней N. Так как это - интеграция с существующей системой, и все экземпляры необходимы, это имеет смысл. Однако API как это может легко использоваться для проектирования повторений, не храня все экземпляры.
@Joe Van Dyk спросил: "Вы могли посмотреть в будущем и видеть, когда предстоящие события были бы?"
, Если бы Вы хотели к , видят/отображают следующее n происшествия события, которое они имели бы или к a) быть вычисленными заранее и сохраненными где-нибудь или к b) быть вычисленными на лету и отображенными. Это было бы тем же для любой вечерней платформы.
недостаток с a) - то, что необходимо поместить предел на него где-нибудь, и после этого необходимо использовать b). Легче только для использования b) для начала.
для системы планирования не нужна эта информация, она просто должна знать, когда следующий событие.
При сохранении события я сохранил бы расписание к хранилищу (давайте назовем его" Расписания ", и я вычислил бы, когда событие должно было стрелять в следующий раз и сохранить это также, например, в" События ". Тогда я посмотрел бы в" События " и фигура, когда следующее событие должно было произойти и заснуть до тех пор.
, Когда приложение "просыпается", оно вычислило бы, когда событие должно произойти снова, сохранить это в" События " снова и затем выполнить событие.
Повторение.
, Если событие создается при сне, сон прерван и повторно вычислен.
, Если приложение запускается или восстанавливается с события сна или подобное, проверьте" События " для переданных событий и действуйте соответственно (в зависимости от того, что Вы хотите сделать с пропущенными событиями).
Что-то вроде этого было бы гибко и не возьмет ненужные циклы ЦП.
Первое, что пришло на ум (после пересмотра пары вещей при вводе/взглядах):
Определяют минимальное необходимое разрешение повторения; это то, как часто выполнение приложения. Возможно, это ежедневно, возможно, каждые пять минут.
Для каждого повторяющегося события, сохраните новое время выполнения, интервал выполнения и других положительных героев как время истечения срока, если это желательно.
Каждый раз выполнение приложения, это проверяет все события, выдерживая сравнение (сегодня/теперь + recurrenceResolution) к (recentRunTime + runInterval) и если они совпадают, запускают событие.
Когда я записал календарное приложение для меня бормотание несколько лет назад, я в основном просто украл механизм планирования из крона и использовал это для повторяющихся событий. например, Что-то происходящее во вторую субботу каждого месяца кроме января включало бы инструкцию, "повторяют =* 2-12 8-14 6" (каждый год, месяцы 2-12, 2-е недельные выполнения от 8-го до 14-го, и 6 в течение субботы, потому что я использовал нумерацию на основе 0 в течение дней недели).
, В то время как это делает довольно легким определить, имеет ли событие место в какую-либо данную дату, это не способно к обработке "каждый дни N" повторение и также скорее менее, чем интуитивно для пользователей, которые не являются здравым смыслом Unix.
Для контакта с уникальными данными для экземпляров одиночных соревнований и удаления/перепланирования я просто отслеживал то, как далеко события были вычислены для и сохранили получающиеся события в базе данных, где они могли тогда быть изменены, переместились или удалили, не влияя на исходную информацию о повторяющемся событии. Когда новое повторяющееся событие было добавлено, все экземпляры были сразу вычислены до существующей "последней расчетной" даты.
я не предъявляю претензии, что это - лучший способ сделать это, но это путь и тот, который работает вполне хорошо в рамках ограничений, которые я упомянул ранее.
Если у Вас есть простое повторяющееся событие, такой как ежедневно, еженедельно или пара дней неделя, что случилось с использованием buildt в функциональности планировщика/крона/в? Создание приложения исполняемого файла/консоли и настроенный, когда выполнить его? Никакой сложный календарь, событие или тайм-менеджмент.
:)
//W