2.0
No due date
0% complete
The 2.0 release will most likely break API compatibility in regards to 1.x
and use Swift.
Overall plan
-
Swift with modules?
- If not we must change the class prefix to something which will not conflict with Core Data.
- New class prefix:
-
CEDE
(pronounced more or less the same way as the current prexif), -
CDRC
, -
CDCR
, -
CDTZ
, or -
RSTR
?
-
- If we go Objective-C may…
The 2.0 release will most likely break API compatibility in regards to 1.x
and use Swift.
Overall plan
- Swift with modules?
- If not we must change the class prefix to something which will not conflict with Core Data.
- New class prefix:
CEDE
(pronounced more or less the same way as the current prexif),CDRC
,CDCR
,CDTZ
, orRSTR
?
- If we go Objective-C maybe provide optional type aliases?
- Modernize codebase (10.9 and up)
- Make it easier to use.
- Change
CDEvents
(i.e. the watcher) to be mutable instead. Really awkward to use right now due to its massive init-methods and lack of way to change it. - Use the builder pattern?
- Change
- Only provide block based callbacks (i.e. remove the delegate things)
- Possibly provide a
1.x
compatibility shim for the delegate pattern. Possibly not though.
- Possibly provide a
- Make use of GCD so that we do not block either the FSEvents’ or our users’ threads.
- Make the classes work for XPC.
- First of all, investigate if this is really suitable as this might not be what XPC services were really designed for. The CDEvents service would need to run for as long as the app and that isn’t really what XPC services where made for AFAIK.
- Provide an
CDEventsXPCService
for easy integration.
- Prettify the code.
- The mega-init methods are not very nice.
- The naming of certain things are a bit weird.
- Remove any explicit exceptions, unless they’re actually a good thing in that specific case (probably not).
- Keep it thread-safe.
- Add unit tests.
- Utilize constant integration (Travic-CI).