0

I am in little bit confusion because of my less understanding about CouchDB. Let me explain in simple words. I am developing an iphone app for which my client may ask for android version. I am using CouchDB as data storage for this application.

We designed a backend from where admin can setup/update information. ALL updated information should be replicated to all iphone device. When I say replicate from server to device I does not mean replication from one iphone device to another. Means source of updated always will be server.

My client also wants that most of the functionality if possible should work offline. To make some of the functionality offline client asked me to use CouchDB and TouchDB(on iphone) which will be synch up automatically.

According to me CouchDB is not designed to serve this purpose but designed for replication which is required for distributed computing where source of data is not one server but multiple.

Using CouchDB/TouchDB I am facing lot of issues. One of the big issue is my logic and UI implementation are together built on my xcode. If tomorrow I want to develop Android application then again I have to implement same logic in android syntax. Change in logic needs update both versions. More frustrating if client wants to develop windows and BB version tomorrow.

To avoid this I can suggest my client we should use 3-tier architecture where we will built one middle ware and we will keep our logic there. Only work we need to develop at app level is fetch data from middle ware via WebService and present UI.

But before suggesting to my client I want to confirm my idea from expertise. I might be wrong as I do not well knowledge about CouchDB and maybe CouchDb is only designed for offline/online setup.

Please waiting to here from expertise.

SangamAngre
  • 809
  • 8
  • 25
  • I would suggest doing what fits your skills and your client requirements. You could move the sync logic to a third tier, but it's difficult to tell if that makes the client logic easier. It seems like you're just moving the problem and increasing the number of failure points. – WiredPrairie Mar 08 '13 at 12:04
  • "It seems like you're just moving the problem and increasing the number of failure points." how? – SangamAngre Mar 08 '13 at 12:08
  • keeping logic at one place which would be applicable for all (iphone/android/windows/BB) doesn't good idea. 3 tier is world accepted approach. Isn't it? – SangamAngre Mar 08 '13 at 12:10
  • You had 2 tiers (phone, DB). Now 3? That would increase the number of failure points. Have you even tried TouchDB to see if it meets your needs? It's available for Android and iOS. Are you really going to need to develop for 4 phones? – WiredPrairie Mar 08 '13 at 13:01
  • Lets take ur example now. 2 tier for iPhone and Db. 2 tier for Android and DB, 2 tier for BB and DB ...... Now what you think? How many point of failure you will face here? This is not only about point of failure just think about change in logic (not change in design, design change will lead to app modification). One change in logic leads to modification of every language, isn't it? – SangamAngre Mar 11 '13 at 07:03
  • and yes am going to develop for 3 versions of app. iPhone, Android and BlackBerry for now. Maybe in future client going add Windows version also. – SangamAngre Mar 11 '13 at 07:09

1 Answers1

3

I'm working on something similar right now, so I can share what I've found.

We're using BigCouch (a fork of CouchDB managed by Cloudant that provides a cluster of Couch machines) to store our data and then using TouchDB for iOS to replicate data down to mobile devices.

We've been able to get TouchDB working with BigCouch, but it hasn't been without a few bumps in the road. TouchDB takes advantage of the existing replication functionality built into CouchDB and handles it well.

From my experience TouchDB also works very well in offline mode. The replication will pick up where it left off when the device went offline. You can also configure Touch to do pushes, pulls - or both, so that's nice.

The real issue is when you want to move to Android. The TouchDB Java port is in a sorry state right now. It exists, but it's not ready for production. In fact I saw on Twitter just this week that they're trying to hire someone to take over the project.

Even if the Java port of TouchDB was ready for production, you're right, you'd have to re-write the code for Android. Then again this would be the case no matter what technology you use.

ryan1234
  • 7,237
  • 6
  • 25
  • 36
  • SO use of 3 tier architecture isn't it useful here? It will also keep my maintenance cost low and change in logic lead to change at middle ware and not at application level, right? – SangamAngre Mar 11 '13 at 06:56