1. Funambol C++ APIs

2. Overview

Looking backward

Current status

Looking forward

Testing the APIs

Q&A

3. Once upon a time Looking backward (1)

Funambol needed a client to show its server technology and a Java prototype has born

Supporting Windows platforms required clients for Outlook written in C++

The clients have been built on top of a common set of API, to share the protocol implementation.

4. The API portability Looking backward (2) The API had been designed to be portable sincethebeginning. Client Sync APIs OS and native data access 5. The unexpected along the way Looking backward (3)

... and along came the idea to sync emails and to push them

... and along came (and fortunately went away) Palm OS

... and along came SyncEvolution and the Posix support

... and along came the iPhone and the Mac

... and along came Symbian

6. Bottom line.... Looking backward (4)

The original design did not accommodate all what was added along the way

Each platform/feature introduced new constrains

If you see something strange in the APIs don't worry. Everything made sense at some point in time :)

7. Funambol C++ APIs overviewCurrent Status (1)

Funambol C++ APIs

• DS engine (to synchronize data)

• DM partial support (just the storage tree)

• Push technology (to receive push notifications)

Supported platforms

• Windows and Windows mobile

• Posix (but mostly Linux)

• iPhone and Mac

• Symbian (>= 9.1)

8. The how and the what Current status (2)

The Sync Engine is data agnostic, any data can be transported/synchronized (the how)

Each client provides access to data, relying on its knowledge of the data and of the underlying system (the what)

9. The how (1) Current status (3) SyncML Server (choose your favorite open source one) Sync Engine Sync Source Back End 10. The how (2) Current status (4) Sync Engine Sync Source Server Authentication OK What changed? Changes Client changes Server changes .. Black magic. . Apply changes Result Result 11. The what Current status (5)

Typical data exchanged during synchronization

Contacts

Events/Tasks

Notes

Emails

Files

12. Push service Current status (6)

Server to client push is implemented by an API module

Heartbeat Notifications Notifications Push Server Client Push module 13. Portability Current status (7)

Different patterns for portability

• One interface, different implementations

• ifdefs in the code

• Object factories

We do a case by case choice based on what makes more sense

14. Next easy steps Looking forward (1)

Better modularization

• no monolithic API but components that can be enabled/disabled

• improved platform abstraction layer

New components

• Updater to check for new versions

15. Next steps (longer term) Looking forward (2)

Data model pushed into the API

• There is no common model for most PIM data today.

Use of standard containers

• STL? QT? Wrapping around them?

Unified build system

• Cmake could be one solution.

Improved large object support

• We need an option to avoid assembling/disassembling LO in memory

16. Data model into the API Looking forward (3) PIMItem ContactItem EventItem TaskItem Standard format parsers and formatters PIMSyncSource BackEnd Interface (client code) 17. Use of standard containers Looking forward (4)

STL would be perfect if it were available on Symbian :(

QT would be perfect if it were available on iPhone :(

What about the wrapping route?

18. The wrapping route Looking forward (5) With STL support With QT support And if no good containers are available, we can revert to the ones we have today (safety net) Template Funambol::list { std::list stlList; void append( item) { stlList.append(item); } } Template Funambol::list { QList qtList; append( item) { qtList.append(item); } } 19. One drawback of portability Testing the API (1)

One code base, multiple platforms

• change here, you break there!

• You cannot test all the platforms...

We test on the platform we are developing for and...

• rely on automatic tests for other platforms

• rely on different levels of testing

20. Testing frameworks Testing the API (2)

Unit testing

• we are still learning the approach..

• • design interface, write the test, code

• we have a large code base without tests

• • it is painful to make it testable

21. Unit testing on existing code Testing the API (3)

Adding test code is tedious, but sometimes also very hard

How do we test big methods that (for example) require communications with the server?

How do we test classes with a very simple public interface but a lot of private code?

If someone has experiences to report....

22. Integration tests Testing the API (4)

Require a sync source and possibly a server

• • The APIs provide a File Sync source that can be used for this

• • Complex tests simulating synchronization are part of the API testing framework. It would be nice to have a higher definition language to specify a test.

23. Our continuum environment Testing the API (5)

We build the API every night as part of our continuum environment

We build all different variants

We run tests on windows and linux

On linux we use valgrind to automatically report memory leaks

24. How to contribute

There are several ways to contribute

• help us to extend the APIs

• use the APIs in your own client

• port the APIs to any platform

• help us to make the APIs more unit testable

25. The End (Q&A?)