1

I am working on an app that reminds users of actions based on the preferences that they set. They can set a start date and an end date (the end date is optional). Then they can set the frequency:

  • Daily
  • Weekely
  • Every 1-9 Days
  • Every 1-9 Weeks
  • On certain days of the month
  • Specific Dates

Now, I need to be able to retrieve a list of the upcoming and past reminders to show in a UITableView. And if the user ignores the notification (do not check off the reminder in the app) then I need to be able to keep track of this as well for mathematical computation later on.

First I had the idea for the UITableView to just look at the reminders set and figure out what notifications would fire on any given day.

This would take a lot of computation with dates, and would not allow me to know if a user ignored the reminder.

My next (and current) idea is to store a database table (like below) and enter in a month in the future of reminders. And any rows that are not set to responded to mean that they ignored it. This would also make the UITableView very simple to do.

Are there any better ways of doing this? How far in advance should I create the database rows? If they change the reminder, I am going to have to probably call DELETE on the rows and re-enter them; will this be ok to have really high number in terms of id's?

reminderLogs
-------------
id
reminderID
actionReceived
timestampShould
timestampTaken
comments
coneybeare
  • 33,113
  • 21
  • 131
  • 183
Flipper
  • 2,589
  • 3
  • 24
  • 32

2 Answers2

1

This sound like a good place to use Core Data. It can be a pain in the asterisks to set up, especially when you're unfamiliar with it, but once you do, you'll have a persistent store of data that that's (relatively) easy to query. You can also change attributes of stored objects without deleting and re-creating them, so it's easy to add or modify records in the DB as the user adds or modifies tasks. If you need to display a list or run any computations on the stored data, the right query will pull up everything you need to know.

There are numerous Core Data tutorials on the Web, but you might as well start with Apple's example.

Husker Jeff
  • 857
  • 1
  • 5
  • 6
  • I thought about Core Data, but I want to eventually make the app on Android and WP7, so wouldn't it be easier to stay with just sqlite? – Flipper Jul 13 '12 at 03:06
1

First off, +1 to Husker Jeff and his suggestion of using Core Data. It should be your method of persistence for building your notification rules.

I am currently working on a server side component responsible for recurring notifications. Looking at your description of types of recurring events, UILocalNotification is not flexible enough to use just the repeatInterval property.

I would strongly reccomend reading the following:

  1. Martin Fowler's Pattern for recurring events.
  2. IceCube, a reccuring events library developed in Ruby for dealing with recurring events and temporal expressions. It should give you a good idea for how to implement your Object Graph.
  3. Stack Overflow topic on building an iCal friendly DB schema.

I would suggest relying on UILocalNotification's repeatInterval where possible. You will probably want to delegate things like the weeklyRule and dailyRule to UILocalNotification's repeat interval.

For rules like every nth day, and every nth week, you'll probably need to create your own temporal expressions and rules for them.

Community
  • 1
  • 1
Travis
  • 5,021
  • 2
  • 28
  • 37