inovex/andsync

This project solely contains the documentation and the issue tracker of the AndSync framework.

AndSync

This project solely contains the documentation and the issue tracker of the AndSync framework.

Head for the Wiki for documentation and the Issue Tracker to file new bugs or feature requests.

The following three projects build the AndSync framework:

• andsync-client - The client-side library to use in your Android project.
• andsync-server - The server of AndSync used to synchronize the data to.
• andsync-common - A shared library for the above projects.

andsync's Issues

Make call collector constants configurable

The user should be able to configure the maximum time limit calls are collected or maximum limit of collected calls, but sensible defaults should be kept.

See TODOs in andsync-client: de.inovex.andsync.manager.CallCollector (head of file)

Fix GCM registration process

If a client is already registered for GCM, he again requests a registration, to make sure the AndSync server gets informed about his registration. It should insteada just send its already existing GCM registration id to the server, to make sure the server hasn't lost it.

see: andsync-client: de.inovex.andsync.manager.PushManager:59

Right order when transferring calls

The calls could have a timestamp when they originally were made to the CallCollector, so they could be ordered on the server.

Cache should store a version number

The cache should store a version number, so if AndSync changes the cache can be invalidated (since there might be changes in the way the cache is managed).

Evaluate background work

Evaluate how the framework could work well in background (e.g. using Android services)

Clear cache more often

The cache on the client should be deleted if any minor exception occur to make sure, that the cache won't contain inconsistent data.

Complete LazyList implementation

The LazyList implementation is missing some optional method implementation (removeAll and retainAll) and some mandatory implementations (containsAll and subList). These should respectively must be implemented.

Test behavior with weak connectivity

The behavior of the framework in situations with weak connectivity and see how it behaves.

Return the right objects on a last modified call

If you make a call with a timestamp all objects last modified after that timestamp should be returned. This currently only works, if it is the object of the class requested. If an object referenced by such an object is modified, it won't be returned.

Example:

class A has a field B.

The client requests all objects of class A modified after timestamp X. An object a1 references b1, which has been modified after X. So this object a1 (and all objects it references like b1) should be returned to the requesting client. If it won't it might never know about the changes is objects, that are only used referenced and never requested directly. The server should in such case resolve all references and return objects where any referenced object has changed after X.

Return sorted list

The framework should be able to sort the returned list. To not destroy the lazy loading of the returned list the objects need to be sorted in cache directly.

Bundle HTTP delete calls

HTTP delete calls are collected right now, but not bundled into one (i.e. after enough are collected one HTTP call for each deletion is sent out). They should be bundled into one DELETE call, containing multiple IDs, as it's done with PUT, POST and GET (by ID).

ProGuard/DexGuard testing

ProGuard and DexGuard might have heavy impact on the library. For sure you need to exclude the classes you want to store (so their variable names are preserved and can be loaded again). But you might also need to keep several enums from the library, since they are used by their names. Also I am not sure if the used libraries (Lucene, GCM, etc.) will work after ProGuard.

Someone with good ProGuard experiences would need to test the library and modify the corresponding wiki page.

Security

... would be a nice thing to have!

Delete non top-level objects

If you delete object A, that holds the last reference to object B (of another type), this object B will never be deleted. The framework does not know, if that object still might be used (because the objects of the type of object B are accessed directly from some other point), so it cannot delete it.

A mechanism would be needed (perhaps regular cronjobs on the server side) where the user of the framework configures what objects are the top level objects. So orphaned objects could be deleted.

Reuse Lucene documents

Use a pool for Lucene Documents (org.apache.lucene.document.Document). The documents can be reused after storing them in the database.

Remove CacheStorage

Currently two separated Storages are used for Cache and REST. Since a lot of cache calls are anyway done in the REST Storage, the Cache Storage should be removed completely and everything should be done in one Storage. So the framework won't need to encode every object two times (what is currently done).

Push messages won't result in update of data

If a client receives a push message he tries to send out a request immediately. If a request to the server is already running, while another request comes in, the new call won't be made but the result from the first call will be returned to both requests as soon as the server responded.

Meaning a user might change something in short intervals. Another client gets the first Push message and start a call. Meanwhile the push message for the next changed objects are delivered. But no new calls are made, since the first call is still running. The first call finishes and the result will be returned. But the result might not contain all the new objects, since the request was done when the first push message was arrived.

The calls should be queued, so no two calls are made at the same time, but any incoming push message will queue a call to be done after the current one is finished. It is only necessary to queue one call. If a call is already queued to be executed after the current finished, no new call need to be queued when new push messages arrives.