1 / 37

Wireless Synchronization of Mobile Devices

Wireless Synchronization of Mobile Devices . By Eugene Kovshilovsky. Motivation. Need for multiple people to have the same information Ex. Birthdays, Business contacts Ease of synchronization Not tied to one location New technology not widely developed yet. Why Synchronization?.

Jimmy
Download Presentation

Wireless Synchronization of Mobile Devices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wireless Synchronization of Mobile Devices By Eugene Kovshilovsky

  2. Motivation • Need for multiple people to have the same information • Ex. Birthdays, Business contacts • Ease of synchronization • Not tied to one location • New technology not widely developed yet

  3. Why Synchronization? • Local databases and operations on them are coming commonplace • Having your data always updated is (becoming) a competitive advantage • Cooperation of networked parties/applications sets a direct demand for a seamless solution • Handsets are not ”always on” • Constant connections are expensive • Network coverage is not universal • User experience can be unsatisfactory

  4. What development technology may be used? • SyncML is founded by key industry players • open technology for universal data synchronization • Pocket PC’s have Visual Basic and C++ libraries built in for easy development. • JSP/J2EE is widely used to design web sites • Most Cell phones are Java enabled supporting J2ME and MIDP development

  5. SyncML

  6. SyncML (Part 2)

  7. Why SyncML was chosen? • Open technology benefits all • Application developers • Operators and service providers • Handset manufacturers • Customers • Expandable • Transport independent • Can be used over HTTP, GPRS • Secure • Wide enough industry backing • True interoperability (Can run on any platform) • Sufficient device volumes

  8. Is SyncML good for development? • SyncML is the protocol of choice for data synchronization • SyncML serves as a key enabler in development of interactive networked applications • Market demand for SyncML Device • Management exists. You must start implementation ramp-up now in order not to miss the train.

  9. What is SyncML? • Data Synchronization Protocol • based on the XML technology • supports a variety of transport protocols • (e.g. WSP/WAP, HTTP, OBEX) • leverages existing open standards for object types and can support arbitrary networked data • addresses the resource limitations of mobile devices

  10. Communication between Client and Server

  11. Tools Used For Pocket PC Application Development • Microsoft eMbedded VC++ 4.0 w/ SP4 • Used for core DLL development • Microsoft eMbedded Visual Basic 3.0 • Included in Microsoft eMbedded Tools 3.0 • Used for GUI development • Microsoft Pocket PC 2003 SDK • Microsoft Pocket PC 2002 SDK • Microsoft eVB Run-time library • Built into Pocket PC 2002 but needed on Pocket PC 2003 if Visual Basic .NET is not used

  12. My Pocket PC 2003 SyncML API

  13. Sync Client API Architecture • Built up of two main modules: • Data synchronization • Device management

  14. Three Main Modules • Device Manager Layer • Responsible for device and application configuration management • Hides the complexity of the synchronization process providing few simple methods to deal with • But It’s Still in development

  15. Three Main Modules (Part 2) • Sync Manager Layer • Responsible for everything regarding the SyncML protocol and the data synchronization process. • Sync Source • An application module used to interact with the application data sources • Application specific and transparent to the synchronization engine. • Transfer Process Between The Two • The collection of items that are exchanged between client and server. • The client feeds a Sync Source with the items changed on the client side • While the Sync Manager feeds it with the items received by the server

  16. SyncManager • The SyncSource represents the collection of items that are exchanged between client and server. • The client feeds a SyncSource with the items changed on the client side, while the SyncManager feeds it with the items received by the server.

  17. Sync Process • The client application tells the SyncManager to prepare sync of the server database (new SyncSource) • This starts a new synchronization session • The SyncManager negotiates with the server which type of synchronization should be performed (one-way, two-way, slow, etc).

  18. Sync Process (Part 2) • Then the client can feed the sync source with the relevant items (usually using setAlltems() in case of a slow sync and the other setXXXItems() methods in case of one of fast sync). • When both SyncSource and the SyncManager are ready • sync() is called.

  19. Sync Process • If the sync process was successfully terminated • The client can read the items received from the server calling the getXXXItems() methods of the SyncSource object. • In the case the client creates its own LUID for new items, it can set the LUID-GUID mapping back to the Sync Source so that at the end of the synchronization process the mapping is sent to the server.

  20. Sync Process • LUID (locally unique identifier) • A 64-bit value that is guaranteed to be unique on the operating system that generated it until the system is restarted • GUID (globally unique identifier) • unique 128-bit number generated in SyncML server to uniquely identify a tuple.

  21. Interaction Diagram

  22. Classes Structure

  23. Class Structure (Part 2)

  24. What do those Classes Do? • SyncManagerFactory • This is the factory for SyncManager objects. Use its getSyncManager() method to get a new configured instance of SyncManager. • SyncSource • The class that represents a synchronization data source. • Must be filled with the client-side items before passing it to the SyncManager in order to synchronize it. • After the SyncManager has finished a sync(), the SyncSource object will contain the server-side items. • Items are stored as arrays of SyncItem objects.

  25. What do those Classes Do? (Part 2) • SyncItem • An item is represented by a SyncItem, who associates an identifying key with the item content. • Config • This class represents the entire SyncManager configuration. It groups utility methods to easily access configuration properties. • SyncSourceConfig • Similar to Config but for SyncSources.

  26. Code Snippet SyncManagerFactory factory = SyncManagerFactory(); SyncManager* syncManager = factory.getSyncManager(APPLICATION_URI); SyncSource source = SyncSource(SOURCE_NAME); if (syncManager == NULL) { error(); goto finally; } ret = syncManager->prepareSync(source); if (ret != 0) { // error handling ... } switch (source.getSyncMode()) { case SYNC_SLOW: 7 setAllItems(source); // fill the allItems source property break; case SYNC_TWO_WAY: setModifiedItems(source); // set the client-side modified items break; default: break; } if (syncManager->sync(source) != 0) { error(); goto finally; } // Now source contains server-side modifications // ... Do whatever appropriate ... setMappings(source); // set LUID-GUID mapping if (syncManager->endSync(source) != 0) { error(); goto finally; }

  27. Sync Manager Functions • SyncManager() Constructor • int prepareSync(SyncSource& source) • Initializes a new synchronization session for the specified sync source. It returns 0 in case of success, an error code in case of error • int sync(SyncSource& source) • Synchronizes the specified source with the server. Source should be filled with the client-side modified items. At the end of the process source will be fed with the items sent by the server. It returns 0 in case of success or an error code in case of error • int endSync(SyncSource& source) • Ends the synchronization of the specified source. If source contains LUIG-GUID mapping this is sent to the server. It returns 0 in case of success or an error code in case of error

  28. Sync Source Functions • SyncSource(char* name) • Constructs a SyncSource with the given name. • The name is used to retrieve the source configuration from the <appURI>/spds/sources/ configuration context. • char* getName(char* name, int dim) • Returns the source name. If sourceName is <> NULL the returned value is sourceName. Otherwise, the returned value is the internal buffer pointer. Note that this will be released at object automatic destruction. • setType(char* type) • Sets the items data mime type • char * getType(char *type) • Returns the items data mime type. If type is NULL, the pointer to the internal buffer is returned, otherwise the value is copied in the given buffer, which is also returned to the caller. • setPreferredSyncMode(SyncMode syncMode) • Sets the synchronization mode required for the SyncSource. It can be one of the values of the enumeration type SyncMode.

  29. Sync Source Functions (Part 2) • getPreferredSyncMode() • Returns the default synchronization mode. • SyncMode getSyncMode() • Returns the synchronization mode for the SyncSource. It may be different from the one set with setPreferredSyncMode() as the result of the negotiation with the server. • setSyncMode(SyncMode syncMode) • Sets the synchronization mode for the SyncSource. • long getLastSync() • Returns the timestamp in milliseconds of the last synchronization. The reference time of the timestamp is platform specific. • setLastSync(long timestamp) • Sets the timestamp in millisencods of the last synchronization. The reference time of the timestamp is platform specific. • setLastAnchor(char* last) • Sets the last anchor associated to the source • char* getLastAnchor(char* last) • Gets the last anchor associated to the source. If last is NULL the internal buffer address is returned, otherwise the value is copied in the given buffer and the buffer address is returned.

  30. Sync Source Functions (Part 3) • setNextAnchor(char* next) • Sets the next anchor associated to the source char* getNextAnchor(char* next) Gets the next anchor associated to the source. If next is NULL the internal buffer address is returned, otherwise the value is copied in the given buffer and the buffer address is returned. • setAllSyncItems(SyncItem* items[], int n) • Sets all the items stored in the data source. For performance reasons, this should only be set when required (for example in case of slow or refresh sync). The items are passed to the SyncSource as an array of SyncItem objects. • setDeletedSyncItems(SyncItem* items[], int n) • Sets the items deleted after the last synchronization. The items are passed to the SyncSource as an array of SyncItem objects. • setNewSyncItems(SyncItem* items[], int n) • Sets the items created after the last synchronization. The items are passed to the SyncSource as an array of SyncItem objects.

  31. Sync Source Functions (Part 4) • setUpdatedSyncItems(SyncItem* items[], int n) • Sets the items updated after the last synchronization. The items are passed to the SyncSource as an array of SyncItem objects. • setLUIDGUIDMapping(SyncMap* mappings[], int n) • Sets the LUID-GUID mapping of the last synchronization. • SyncMap** getLUIDGUIDMapping() • Returns the LUID-GUID mappings. • int getMapSize() • How many mappings. • SyncItem** getAllSyncItems() • Returns the all items buffer. • int getAllSyncItemsCount() • How many items in the all items buffer.

  32. Sync Source Functions (Part 5) • SyncItem** getNewSyncItems() • Returns the new items buffer. • int getNewSyncItemsCount() • How many items in the new items buffer. • SyncItem** getDeletedSyncItems() • Returns the deleted items buffer. • int getDeletedSyncItemsCount() • How many items in the deleted items buffer. • SyncItem** getUpdatedSyncItems() • Returns the updated items buffer. • int getUpdatedSyncItemsCount() • How many items in the updated items buffer.

  33. Difficulties Faced w/ Pocket PC • Compatibility of Pocket PC 2002 and 2003 • Can be resolved if development can be done on Microsoft Visual Studio .NET (2003) • Emulation does not function properly • Complicated to configure • Cannot copy all files needed into emulation

  34. Why was J2ME development was stopped? • MIDP 2.0 is required for writing client • Phones that support MIDP 2.0 already had SyncML client built in. • Phones that only support MIDP 1.0 can not access needed Contact and Calendar information properly. • Emulator and Mobile Phone crash

  35. SyncML Server • An open source syncML server can be obtained from Funambol.com. • Can be connected to any SQL database or used standalone with file system. • Can be modified to fit your needs. • Supports contacts, calendar, briefcase out the box. • Can be Installed on either JBOSS or Tomcat • Not very simple for developers not familiar with those web servers.

  36. Sync Server

  37. More Information can be found as • http://www.funambol.com • http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html • www-106.ibm.com/developerworks/xml/library/wi-syncml2/

More Related