Skip to content


February 9, 2014

It has been a long while since I posted, I thought I should drop a message to let you know what is happening.

Not much active development is happening in Cloudpipes anymore and I am experimenting with some other projects here:

But most of my development work is halted due to a new addition to the family who is demanding a massive amount of attention! That and lots of work at my job, so development may be very slow.

Cloudpipes eXTenDeD is released!

July 31, 2013

Finally after a long wait, I am satisfied enough with my code to release the full version of Cloudpipes!

You can get it here.

It wont cost you much, just to show some support to the developer, that is me!

Cloudpipes Plugins!

July 30, 2013

Its been a while since I posted, but I have been at work!

Release two plugins for Cloudpipes that extend its capabilities vastly.

One is PhoneBackup

Its a cool tool that can backup your SMS, Contacts and Call Logs. The good thing is that it backs it up as a CSV file. That way you can just open it and see all your contacts. What is every way more cooler, is that you can edit the CSV file and restore the edited data back to the phone. It is really useful, do have a look at it.

The other plugin is a Tasker Plugin 

You need Tasker and Cloudpipes both to use it. It allows you a greater control over when you want to run your pipes. Users of tasker will already know what to do with it!

Apart from that I am pretty much ready to roll out Cloudpipes eXTenDeD now finally. I believe it is really stable and no body will have any issues with it!

Whats happening

February 24, 2013

It has been a while since my last update. Mainly it goes busy since I went on holiday and then bought a car (my first!). So I didnt get a lot of time to work on Cloudpipes. 

However, I did have many improvements in the pipeline. Main focus is making it bullet proof stable so it does not crash anymore and also on better performance. These things are still in the works but things are moving along nicely.

There are some feature requests in the pipeline too, for e.g. customisable backup location. If there are more feature requests I will try to entertain them if I have enough time.


December 18, 2012

Its been a while I have posted now, just got busy is sooo many things!

I thought I would have released Cloudpipes eXTenDeD last month, but I wanted to make sure I had all the bug reports cleared before. Some of them were weird Out of memory bugs. Also, some requests started flowing in, and it seemed a good idea to me to add those features in before I released the new version.

Some people asked for landscape mode which is a very reasonable request. Thank God, I got that working…well almost…

Many other bug fixes here and there and some more memory optimizations (better listviews)…

Another issue I was having was on large transfer lists being stored in memory. Looks like I need to add a way to auto-purge if the list becomes too long (which by the way is quite hard to guess when to purge it actually)

I also plan to improve the swipe behaviour, which is pretty bad on the pipes screen right now.

I hope to release it with these updated features in the coming weeks.

In the meantime I have been toying with other ideas too. I did some work on a SMS and Contacts backup solution, which I may post soon. I am also toying with the idea of PC Syncing with contacts or other data too…too many ideas…too less time!

Cloudpipes eXTenDeD

November 12, 2012

The paid version of Cloudpipes has pretty much been finalized.

It will contain the following features:

  • Migration to Dropbox API ver 1 (okay thats not a big deal!)
  • Disable pipes
  • Flatten files into a single directory
  • Recursive directory copy can be disabled now
  • Shortcuts on launcher to run a pipe
  • Backup/Restore you pipe settings
  • Infinite pipes

The pricing has yet to be finalized.


October 25, 2012

It has been a while since I posted. I have been quite busy with other things in life (health, family etc that also require attention!). But I have still been working on Cloudpipes in the background, improving things, adding features and getting a clearer idea of its future.

Since the last update on the blog I have added numerous UI improvements to make the app look better. I added a slight background, better looking boxes, shadows, overlays, better dialogs, progressbars, swipey tabs. In the features I added Revision checking, One Way Sync, pipe backup function, a plugin framework, and developer logs sending feature. Loads of bug fixes as always, tried to improve error resilience and reporting. Learning and progressing everyday.

There have been many feature requests, some are possible. Some are not possible due to lack of time, or due to the way the app is now built. There are now a couple of more planned features that will come to the new paid version (I’m hungry sometimes!). I hope to churn out an unlimited version in the next month or so. Lets see how it goes!

Revision checking

July 30, 2012

After a laborious weekend involving lots of coding, I (think I) have finally managed to get some decent revision checking built in to Cloudpipes. Not seeing many errors now on it, but will need to test it a bit.

I must say it involved a lot of redesign and state-checking and was not so easy. I will soon add an update for 1-way sync too but first the basics. I havent sent out an update in a while now.

Revision checking and syncing can be acheived by keeping and saving a sync table at the client side which remembers what was last synced and the last revisions used. I use the last modified date for revisions for a number of reasons. Mainly because it can be expanded upon later on but also it gives a good idea of when the file was modified relative to the last sync.

The table format is simple, it contains {file_path, local_last_modified_date, remote_last_modified_date}. On starting processing a pipe, it loads the last sync table first, then generates a new sync table based on the file dates (fetches remote dates from Dropbox), then it compares these two tables to see whether it needs to upload the files or not depending on if they were locally or remotely modified.

Thanks to the guys at the Dropbox forums for ideas.

Syncing Strategy

July 25, 2012

I have been thinking about how to implement a 1-way sync with Dropbox for Cloudpipes.
So far it seems that it cannot be done without retaining state at the client side.
If Dropbox would be returning some kind of hash that could be computed and compared the the client side, there would not be any need for keeping metadata state at the client, but it seems we have no other option.
The two parameters that can be used for syncing are the rev and the last modified date.

Now consider the case for a downstream 1-way sync:

  1. On first run, we will have to download everything, and also store the ‘rev’ for each file.
  2. Create and save a sync_table with {rev, filename}.
  3. On the next run, fetch the metadata first. Create a new table: remote_table with {new_rev, filename}
  4. Compare each files rev vs new_rev and if it has changed, download the new file. If not, just return a successful transfer.
  5. For all successful transfers, generate a new sync_table.

Now let us consider the case for upstream 1-way sync which is more complicated:

  1. On first run, upload everything.
  2. Create and save a sync_table with {local_modified_date, filename} or {filehash, filename}
  3. On the next run, generate a new table: local_table with {new_local_mod_date, filename} or {new_filehash, filename}
  4. Compare each local_modified_date with new_local_mod_date (or hash) and if they are different perform an upload. If not, just return a successful transfer.
  5. For all successful transfers, generate a new sync_table.

In theory this should work, but we need to work out error conditions in cases of no connectivity etc.

ClientProtocolException – Not any more

July 22, 2012

During my tests with the Android emulator I came across this error quite frequently and repeatedly:

Caused by: org.apache.http.client.NonRepeatableRequestException: Cannot retry request with a non-repeatable request entity

I dont know why it happens, but if the request fails once, the Http library usually retries the request if it can. Since I was uploading files using streams (since they are too large), the Http library cannot retry the request (for whatever reason it fails). However, I stopped getting this error until I saw something similar in the crash logs I get from the market. I knew what was going on so I have added my own retry logic, which attempts to re-upload the stream 5 times, then if it fails it aborts.

Apart from this update there are a few other changes. Interesting one is the ‘Start at boot’ feature that allows the app to be started at boot if the phone is restarted for any reason, so you do not lose your scheduled pipes.

There are many other minor things I need to update as well, hope I get time soon for a quick update.