Added compatibility support for android 2.1 recurrence rule

[k3b]

hi in order to make it run on my old android 2.2 i made these changes

My changes
Added compatibility support for android 2.1 via local CalendarContract.java.
Added recurrence rule processing

[danielegobbetti]

Hi @k3b thanks for the contribution!

I have two question:

1. Do you mind putting the author / license statement in the CalendarContract.java file?
2. Would it be possible to use / adapt the original source code ( I guess it's https://android.googlesource.com/platform/frameworks/base.git/+/android-4.3_r2/core/java/android/provider/CalendarContract.java but I may be wrong) instead of a disassembled version? I think it would be safer from a legal point of view, but I have no idea.

Again,
thanks a lot!

[k3b]

hi daniel,

in the last days i already have taken the original android-4.0 version of CalendarContract.java and removed all staff that is not compatibel with android 2.1

actually we only need the strings from it that define calendar content provider names columns and intent-extra-parameters.

next week i will checkin in a bugfix and the new a4.0 based CalendarContract.java

[k3b]

currently i am implementing the opposite direction to export android-calendar-event to ics file

the project currently has 14 classes and i will add some junit-integration-tests.

would you mind if we rename the app to ACal2MailAdapter because it is much more than an importer?
i made the changes to transfer between ms-outlook-calendar-events and android-calendar-events via email

the two activities should be named Ics2CalendarActivity (former MainActiviy) and Calendar2IcsActivity

which namespaces should we use? both de.k3b.* and org.dgtale.* together?

unfortunatle i startet a big refactoring with lots of renaming
before i red your reply.

so i will not check in until it works again.

[k3b]

so finally i succeeded to branch my repositor to isolate the export changes from the main-import branch. In the new branch i added gpl header to all files and renamed classes and namespaces

[danielegobbetti]

Hello again @k3b wonderful! Thanks a lot!!! I'll merge over the weekend :)

I'm thinking of adding a compatibility layer via reflection to only use the local CalendarContract if it's not available at system level. What do you think?

[k3b]

i am not shure what you exacly mean by "via reflection" and i am not shure if the "reflection api" is really neccessary.

old android 2.1 and new android 4.0 (and newer) only differs in one android import so in my opinion the easiest implementation would be (pseudocode based on the export branch)

if (androidImplements("Android.*.CalendarContract")
cursorAsEventDto = ACalendarCursorAsEventDto_Andorid4(...)
else
cursorAsEventDto = ACalendarCursorAsEventDto_Andorid2(...)

where both ACalendarCursorAsEventDto_Andorid* are identical except the one import statement.

from architecture it should be easy but i am not shure if this is neccessary...

[CharString]

@k3b Why the forked build on F-Droid?
This co-op looks promising.

And Gabriele calls his build alpha, while you don't. Heavily refactored alpha code that still needs some unittest after the fact is alpha too, isn't it?

As an enduser I'd like to know: Is there any chance of dataloss using these alpha builds?

[danielegobbetti]

@CharString I was hoping to be able to merge the contributions earlier this month but unfortunately real life kicked in, hence I think @k3b did the right thing with his fork. His app is also more feature-rich according to the description :)
I'd still prefer using the original lib on newer android versions even though it's only a matter of constants. I have some partial code on my laptop but nothing really working.

[k3b]

@CharString i dont think that you can loose data if you use the adapter. when testing the original code i had some memory-leak issues that i hope i have fixed by closing the adapter when done.

there are still some bluetooth memory issues but i am afraid this is a bluetooth bug in my android2.2

[k3b]

@danielegobbetti in order to put the adapter into f-droiod-store https://f-droid.org/wiki/page/de.k3b.android.calendar.ics.adapter i had to change packagename and namespace and the build is now based on gradle with maven-dependencies instead of local libs/*.jar, which the f-droid folks donot like.

the "master"-branch of my https://f-droid.org/wiki/page/de.k3b.android.calendar.ics.adapter fork should still be compatible with your version. i try to backport import-issues there.

I have just added "Seperate android2 api from android4 api" ( see
k3b#5 )