I've hit a roadblock in trying to figure out the best way to create an ICS file that will have recurring events (and single instance events). My main issue is with recurring events, because a lot of times the recurring events could have a break in between them. Given various articles I have read about ICS file size limitations, Google only accepting 1,111 events in total for a file, what are my options for formatting the event data to accurately represent the events while maximizing the events I can fit into the file?
So far I've come up with:
Option 1: A single VEVENT for each group of recurring events that have no lapse in recurrence.
Option 2: Separate VEVENTS for every single instance of recurring events.
Option 2 seems like the most accurate representation of events, however, that would use up data quickly.
Are these basically my two options?
If your lapse only involve a small number of instances skipped, then EXDATE may work for you. You could generate the next x years of EXDATES perhaps.
https://www.rfc-editor.org/rfc/rfc2445#section-4.8.5.1
Unfortunately for you EXRULE is deprecated and applications support for that may not be there.
Related
My application (php/laravel, but irrelevant here) holds calendar entries for its users (comparable to a car logbook), and some users want to sync those events to their calendar app of choice. I started looking into the ics standard (RFC 5545 etc.) and created an endpoint that generates those files.
Problem: The files are getting huge. Some users have their entire driving history with hundreds and thousands of entries in the application, generating and transfering those MBs of ICS files will take ages (using php, anyways), let alone doing that everytime the calendar app tries to sync.
Question(s): What is the preferred way of dealing with huge ICS documents? HTTP headers and caching is one thing, but how do other people solve this problem? Just send events of the last year? Is there a (pagination?) spec that I haven't found yet?
This is historical data, so it is not going to change. You could offer batches by time period and cache the historical batches. Last years, or anything before the last 4 weeks, never gets updated for example. They do a one-off import of each historical batch into a separate 'driving history' calendar. No more subscribing? Or maybe they can only subscribe for the last month say?
One cannot import & subscribe into the same calendar, so it does mean they would have at least 2 calendars - 1 historical calendar used for imports, and 1 'current' that will update with yesterday's ride. Of course there is then manual effort for anyone who wants to always have the old data as when events fall off the 'current' calendar, at some point they'd have to go import the latest 'old' events.
My question seems similar to Access and scheduling of FHIR Questionnaire resource but I have something different to get understanding
As per my understanding with fhir supports many complex data types to support scheduling events. I came across many such types including Timing, Period, Schedule, CarePlan and CarePlanActivityDetailComponent So I can manage to store my frequency settings somehow with above types but I can't understand how will actual scheduler work?
Does fhir supports to schedule events and provide event notifications based on scheduler settings (like weekly every Monday 10 AM)? If yes, is there any simple reference example where we can see usage for scheduling?
FHIR is a data exchange standard. Schedule allows you to share a particular Practitioner or Location's schedule (what time slots they have available). You can then create Appointment instances to occupy those slots. You can use Subscription to receive notifications when data changes. You can also schedule events (therapy, patient communications, medications, etc.) to occur at a particular frequency (using the ServiceRequest, CommunicationRequest and MedicationRequest resources respectively). But FHIR is not a general timing service for sending system-level events.
PS(for beginner) : Read first three comments for better understanding
I'm in the middle of building a simple iPhone calendar app, & I really do need only simple functionality - add event, update event, delete event, with the only complexity being the events need to have the option of being recurring or single. I have managed the add & delete event bit easily enough, but I'm finding it impossible to do the other bits, namely -
add an event with recurrences (ie, up to a certain date, every x days, etc)
edit an existing event, so that it recurrs or stops recurring
edit a specific recurrence of a recurring event / or all recurrences
I think I can manage the other stuff, but the GData documentation seems almost non-existent (if anyone can point me to some meaningful objective-c docs for the GData stuff, I'd be a really happy bunny - at the moment I'm gradually trawling through all its code to try & figure out how to use it)
Any code samples for the above would be very much appreciated!
Many thanks.
add event with recurrences:
Recurrences are expressed in iCalendar format. You have to fortunately know only fields DTSTART, DTEND, EXDATE, RDATE, RRULE. Also notice, that alarms are placed in the root of xml event entry. (You cannot use when and recurrence tag together). Google calendar web app does not mark RDATE, EXDATE, but understands them and other applications can mark them.
edit recurring event:
If you are able to post normal and recurring event it should be no problem to update it. I tested update to google from normal to recurring and back without no problem.
edit a specific recurrence of a recurring event
Exceptions from recurrence are expressed as new events (confirmed or canceled) which have link (in tag) originalEvent to the recurring event. Be aware that modification of a field in a recurring event can automatically change the field in the events exceptions (e.g. title). If you remove the originalEvent while updating to google, google silently ignores it.
I'm working on an App that needs to remember events selected by the user from their calendar and I've run into a problem with recurring events.
For non-recurring events I can just store the eventIdentifier and fetch the event from the Event Store when I need it.
But recurring events all share the same eventIdentifier. When I go back to the Event Store to fetch the event (based on the eventIdentifier) I get the very first event in the recurrence chain ... not the Nth recurrence of the event that the user selected.
I can't persist the user selected events by archiving the entire EKEvent object since EventKit doesn't support NSCoding.
I'm considering storing the eventIdentifier and Start & End dates so that I can fetch the correct event from the Event Store ... but that seems pretty kludgy and might make tracking changes the user makes in their calendar between launches of my App tricky.
Any thoughts or suggestions?
The event identifier alone is not enough even for non recurring events. Indeed, it can change when the user moves the event to a different calendar. For recurring events, it may change upon detaching an occurrence or splitting the recurrence.Therefore, it is common practice to search for events using a subset of information (say title, start and due date). You should not rely on event identifiers.
Unfortunately, the framework does not provide us with the raw data of an event, it just provides all of the occurrences of the events in a specified interval. Therefore, there is no such thing (using the framework) as the possibility of retrieving a single recurring event and then expanding its recurrence to get its n-th occurrence: you need to manually post-process the retrieved events in order to find the ones you are interested to.
The problem here is that the APIs provided are not meant for sync purposes. Many developers have complained and still complain about this by filing a bug/feature request using Radar. Until now, Apple answer about is that the APIs fulfill a different purpose, since sync is automatic. However, this is true when syncing through iTunes, but not programmatically.
Does anyone know how sites that have a real-time feed of a lot of data work? I am referring to something like a stock site, where they can tell you in real time (well, 20 minute delay mostly, but still real-time - 20 minutes as I understand it).
They have thousands of data pieces delivered to them every second, I would imagine: MSFT 25.00 +.23 VOL 12000 ???? for each stock that had a change during some interval.
So, is there just a constant feed of small pushes going on? Or do you think a site will pull from the place that has the real data and say "give me all changes since 12:23:45 CST to now" type query?
I ask this because at work we might have a situation where we need to have at our application's fingertips real time information like this, and it won't make sense to hit our third party provider over and over and over again every second...
Generally there is a server/client protocol defined between the 2 parties. In the company I work for the connection is maintained at all times.
Here is info on real time data feeds to go with your stock example
NYSE,NASDAQ
It is common for data providers to also have FTP sites with (delayed) batched data. One that comes to mind is the NWS EMWIN
Sites like Twitter feed data to certain approved sites in real-time via XMPP (Wiki link).
In the broadest terms, a push model is going to be the best way of achieving "real time" transfer, particularly if you're talking about a large amount of data.
However you do always have a problem when using a purely push model of how to recover from missed data.
Depending on the nature of your data that may not be a problem (thinking of video delivery as an analogue, where the amount of data is huge but there is sufficient redundancy for it to recover from missing data). And if you have any control over the data you may be able to build some redundancy in. For example, on every change event you can provide absolute values rather than changes, or previous value and new value.
I've done this making an attempt to retrieve the stock quote from the source, and falling back to a timestamped on-disk cache of the quote when the main source fails or times out.