Older
-
issue 5
(Compiles fine, but at runtime would fail calling GData callb...) Status changed by dan.bourque
-
-
-
-
-
issue 2
(All calendars should contribute to the shared sections, spli...) Status changed by dan.bourque
-
-
issue 2
(All calendars should contribute to the shared sections, spli...) Status changed by dan.bourque
-
-
issue 5
(Compiles fine, but at runtime would fail calling GData callb...) Status changed by dan.bourque
-
-
issue 5
(Compiles fine, but at runtime would fail calling GData callb...) reported by dan.bourque
-
-
-
r91
(Use the calendar's ACLLink to determine if we've got real ed...) committed by dan.bourque
- Use the calendar's ACLLink to determine if we've got real edit capabilities.
Use the calendar's ACLLink to determine if we've got real edit capabilities.
-
r90
(Fixed indentation problems by replacing tabs with spaces.) committed by dan.bourque
- Fixed indentation problems by replacing tabs with spaces.
Fixed indentation problems by replacing tabs with spaces.
-
r89
(Updated the GData APIs to the latest version.) committed by dan.bourque
- Updated the GData APIs to the latest version.
Updated the GData APIs to the latest version.
-
-
-
GettingStarted (Setting up the XCode project for your development environmen...) Wiki page commented on by klimb.com
-
-
r88
(Small aesthetic tweaks to the cell renderer.) committed by dan.bourque
- Small aesthetic tweaks to the cell renderer.
Small aesthetic tweaks to the cell renderer.
-
r87
(Updated the string representations of times and dates.) committed by dan.bourque
- Updated the string representations of times and dates.
Updated the string representations of times and dates.
-
-
r86
(Instead of using a NSDictionary, we just use a reference to ...) committed by dan.bourque
- Instead of using a NSDictionary, we just use a reference to the containing calendar. Instead of a
boolean to indicate whether it's a newly created item, we rely on the editingEvent's nil state. And
finally, remove the calendarName field since we can get the calendar's name ourselves from the
provided calendar (used in setting our view's title).
Instead of using a NSDictionary, we just use a reference to the containing calendar. Instead of a
boolean to indicate whether it's a newly created item, we rely on the editingEvent's nil state. And
finally, remove the calendarName field since we can get the calendar's name ourselves from the
provided calendar (used in setting our view's title).
-
r85
(Instead of using a NSDictionary, we just use a reference to ...) committed by dan.bourque
- Instead of using a NSDictionary, we just use a reference to the containing calendar. Instead of a
boolean to indicate whether it's a newly created item, we rely on the editingEvent's nil state. And
finally, remove the calendarName field since we can get the calendar's name ourselves from the
provided calendar (used in setting our view's title).
Instead of using a NSDictionary, we just use a reference to the containing calendar. Instead of a
boolean to indicate whether it's a newly created item, we rely on the editingEvent's nil state. And
finally, remove the calendarName field since we can get the calendar's name ourselves from the
provided calendar (used in setting our view's title).
-
r84
(In updateCalendarEvent, use the specified event's editLink. ...) committed by dan.bourque
- In updateCalendarEvent, use the specified event's editLink. We don't need its containing calendar.
Also, refactored some code for legibility.
In updateCalendarEvent, use the specified event's editLink. We don't need its containing calendar.
Also, refactored some code for legibility.
-
r83
(Simplified the updateCalendarEvent method; it doesn't need i...) committed by dan.bourque
- Simplified the updateCalendarEvent method; it doesn't need its containing calendar.
Simplified the updateCalendarEvent method; it doesn't need its containing calendar.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
r70
(Simplified the whole edit/commit cycle by sending the calend...) committed by dan.bourque
- Simplified the whole edit/commit cycle by sending the calendar event as the editing event directly,
instead of using a dictionary to pass values. Also, the EditingViewController now invokes GData
APIs from the RootViewController, for consistency.
Simplified the whole edit/commit cycle by sending the calendar event as the editing event directly,
instead of using a dictionary to pass values. Also, the EditingViewController now invokes GData
APIs from the RootViewController, for consistency.
-
r69
(Simplified the whole edit/commit cycle by sending the calend...) committed by dan.bourque
- Simplified the whole edit/commit cycle by sending the calendar event as the editing event directly,
instead of using a dictionary to pass values. Also, the EditingViewController now invokes GData
APIs from the RootViewController, for consistency.
Simplified the whole edit/commit cycle by sending the calendar event as the editing event directly,
instead of using a dictionary to pass values. Also, the EditingViewController now invokes GData
APIs from the RootViewController, for consistency.
-
r68
(Instead of setting the GData Calendar service to automatical...) committed by dan.bourque
- Instead of setting the GData Calendar service to automatically follow next links, I do it myself
after each batch of returned entries. This gives the app a chance to process user input, and
incrementally show the tables as they grow.
Instead of setting the GData Calendar service to automatically follow next links, I do it myself
after each batch of returned entries. This gives the app a chance to process user input, and
incrementally show the tables as they grow.
-
r67
(Instead of setting the GData Calendar service to automatical...) committed by dan.bourque
- Instead of setting the GData Calendar service to automatically follow next links, I do it myself
after each batch of returned entries. This gives the app a chance to process user input, and
incrementally show the tables as they grow.
Instead of setting the GData Calendar service to automatically follow next links, I do it myself
after each batch of returned entries. This gives the app a chance to process user input, and
incrementally show the tables as they grow.
-
-
r65
(When creating a new entry in a calendar, set its time/date t...) committed by dan.bourque
- When creating a new entry in a calendar, set its time/date to right now.
When creating a new entry in a calendar, set its time/date to right now.
-
r64
(I determine whether the user has the ability to add/remove e...) committed by dan.bourque
- I determine whether the user has the ability to add/remove events by the existence of its ACL link.
For each calendar, I add a KEY_EDITABLE key in its dictionary if it has one. This allows me to
quickly test if it's editable elsewhere in my code.
I determine whether the user has the ability to add/remove events by the existence of its ACL link.
For each calendar, I add a KEY_EDITABLE key in its dictionary if it has one. This allows me to
quickly test if it's editable elsewhere in my code.
-
r63
(I determine whether the user has the ability to add/remove e...) committed by dan.bourque
- I determine whether the user has the ability to add/remove events by the existence of its ACL link.
For each calendar, I add a KEY_EDITABLE key in its dictionary if it has one. This allows me to
quickly test if it's editable elsewhere in my code.
I determine whether the user has the ability to add/remove events by the existence of its ACL link.
For each calendar, I add a KEY_EDITABLE key in its dictionary if it has one. This allows me to
quickly test if it's editable elsewhere in my code.
-
-
-
-
-
-
|
