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.
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.
Related
I live in an area where net access is mobile or nothing. While I can occasionally get access by tethering a mobile to that network, it isn't often connected, and when it isn't connected, no local device will function on its own, no matter which protocol it uses. Why isn't there any kind of server/cloud resiliency built in where devices can communicate in a peer fashion like Apple's Bonjour (Rendezvous? I can't remember)? If I have an Echo device, I should be able to switch it on through an Alexa interface. I'm OK without speech processing which requires interpretation of commands through an AWS or Google or Apple or whatever cloud, but being able to locally control a switch seems as though the interface could be smart enough to route locally. I guess I may have just answered my question. It seems as though routes could be internally stored so as to not to definitely require a server. Can you imagine shipping a colony to Mars and all the IoT devices stop working? If you ask me, they should not require a branch variation or special programming in order to function.
From the experience of having sat down and built a few, there are a some key reasons why viable IoT gadget products for the general market typically end up having to have a cloud-mediated mode, no matter what was envisioned when the design effort originally commenced:
General consumers (at least think) they want the option to control things when outside the home
Often even at home, a mobile phone may be on the mobile network not wifi, meaning that even if the user is physically inside their home, in network terms, they are not.
Firmware updates, dynamic content, etc are easier when they don't have to be relayed through a mobile phone or PC, especially a mobile that might sometimes have to jump networks partway through the process.
Ironically, having once set out to build an IoT product that could work entirely offline, the further the project progressed, the more and more difficulties that approach presented for general users, and the more the cloud path that was added as an option, started to look preferable in terms of how things should work all the time so that it could become the exclusive focus of development efforts.
My conclusion is that it's very hard to build an offline IoT gadget. Not only the developer, but also the users and marketing people need to understand and accept what sorts of difficulties and limitations that can mean.
So where does it happen? In the situations where the "users" are the "developers" - eg. open source. If you look around a bit, you'll find plenty of gadgets either built form scratch, or more commonly reverse engineered so they can run a custom firmware. Want a local RESTful API? Done! Want could relay via MQTT over SSL to your own broker? Done!
When you control the code, you control the mode.
But with products for the general market, most customers want things to work, not a lengthy technical explanation of why the details of their network setup mean they cannot.
i need some advice.
I am developing an iPhone application (later for Android also) using some social network users. I need to store some data in a database online.
Better to use MySQL with XML or directly use SQLite?
I want performance and stability, and if all goes as I think I might have to handle 500,000 users or more.
I studied a lot about databases, but I would not even take care of his administration, because I'm alone.
Most web services do not support SQLite, but MySQL only.
Can anyone give me some advice with justified?
Thank you to entire community.
Bye, Eros.
Is the database going to run on the device (iPhone/Android) or in the server? In the device both iPhone and Android have good support for running SQLite as an embedded database. If you are thinking server side it doesn't really matter in terms of compatibility since most likely you will add a application layer that is easy to make compatible.
I want to make an iPhone app and an application (server) which runs on a PC with Windows. Is there any easy way to do this on the client side (the iPhone), like a library or something?
Looking on Google I found cocoaasyncsocket and xmppframework, but the last commits were done some time ago and before I start my project I want to know if there are other (better) possibilities out there
One option would be to run a web server on the PC, with a set of REST-based services. This approach gives you lots of options for implementation on the server-side, and you'll have lots of possible frameworks to choose from on the client-side as well. One framework you could use on the iPhone is ASIHTTPRequest.
There are lots of advantages to using a web-based approach. There are HTTP frameworks built for almost every device and platform, so if you ever want to interact with the server from the web, an Android device, etc., there will be many tools to help you do that. There are also lots of great tools out there for debugging HTTP interactions.
You could also use a SOAP-based API, but in my opinion SOAP tends to be more complicated than its worth.
Based on a college-project I'm trying to realize a relatively simple game (Poker) where an iPad acts as Server and multiple iPod-Touchs connect to it as Clients.
Gamekit seems to drop out, since those old ipod-touch-devices don't have bluetooth-support.
Are there already some Frameworks out there simplifying the process, or do I have to fall back on TCP-Streaming-Sockets and implement it myself?
For your task I suggest you have a look at ThoMoNetworking or AsyncSocket.
ThoMoNet is a very simple setup that is specifically developed for fast and easy prototyping and easy to set up. Is will automatically create a bi-partite graph between all instances of you application it finds in the local network. So If you keep your iPad as the server and the iPhones as clients this will come down to less than 10 lines of code to set up.
AsyncSocket is a commonly used framework with ports to PC as well but requires more code to write. On the other hand it will allow you to do more fancy things, should you need them.
Distributed objects are not yet available on iPhone OS, so excluding GameKit you may try using Bonjour networking. Otherwise, you may try using web services with some of the available libraries. If Bonjour and web services are not a choice/possibility, then you have to revert to old plain sockets.
For example, how would I write a program like senuti? Are there any libraries I can use for this? It would be ideal if I could do this in Python or .Net, but I'm open to other things as well.
There are three things you can do:
Add some code to your iPhone application which acts as some kind of server (http, SMB, etc). Then your mac/windows full client application can connect to this server over wifi. This is safe and reliable, but unfortunately the app will have to be running on the iPhone at the time of sync.
Sync to the "cloud". EG: Have your iPhone app save some data to a web server on the internet (you could use amazon EC2, windows Azure, or even just a PHP script running on a cheap hosting account), and then have your windows/mac client also connect to this web server to retrieve the data. This is the most user-friendly, but it requires you to pay for the hosting of the web server, and will be unsuitable for large amounts of data
Violate the EULA and try to reverse engineer the way iTunes communicates with the iPhone.
This is how senuti works, but I wouldn't recommend it, as they're constantly having to play catchup with apple changing the format underneath them, and they are probably exposed to some kind of legal action, if apple ever bothered to sue them.
i believe Version 3.0 will resolve this as it allows you to program apps to the USB interface. check out some of the documentation for that in the External Accessory framework.
it would still require the app to be open, so essentially would mean two syncs (or more if you have multiple apps)
There is no legal / official way of doing this. Creating a program that would sync with an iPhone would violate the EULA you agree to when using the iPhone and iTunes.
Not only is it illegal, but it's also impossible to do this reliably. Apple could break the method at any time without any notice, and it would pretty much be a cat-and-mouse game.
I only know of one application that something of the kind, and it is the iToner application which synchronizes ringtones.