I'm facing some difficulties in choosing the best CouchDB/PouchDB iOS SDK. We have a CouchDB server that can not be upgraded or modified at the moment. This Is a problem for Couchbase Lit SDK last relaese because it uses Sync Gateway as its own server (no longer compatible with CouchDB).
So I studied a bit of CDTDatastore, the Cloudant SDK. Unfortunately is quite 'obsolete' at code level, in the sense that there are more than 100 warnings that I really don't like because are almost referring to object block capture (strong reference cycle) and deallocation of objects in the finalize responder thet is deprecated since years :-)
So I though, just because I'm nearly mad, to try to implement myself the replication protocol, but really, I know it is quite hard, just because, if I correctly understood, I need to implement a CouchDB instance on the iOS device.
So I have two related questions:
Can you suggest me a SDK/Framework/Library to use to simply handling data locally and than manage replication into a CouchDB server? I'd like to be able to choose if use Objective-C or Swift if it is possible;
Is there a way to create a very simple class that implement the replication protocol using only HTTP requests? Or implementing a CouchDB instance is a must?
So... shortly speaking... what is your preferred solution in situations like this?
I use React Native which stopped me from using Couchbase Light (they abandoned project for RN) but their module seemed to work fine in iOS at least some time ago.
It's compatible with CouchDB replication AFAIK.
For RN space I use PDB-localstorage in conjunction with CouchDB.
Related
I've been trying to connect Freeboard to visualize context information from OCB, however came across difficulties that prevent me from receiving any data from there. My thinking is that there is a problem with connecting Freeboard to OCB, because in OCB's subscription list there are no any new entries, and datasource in Freeboard shows that it has never been updated.
OCB is turned on as a docker container. Freeboards run in docker host.
I tried setting the ip as ip that I extracted from docker by:
sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' orion1
It gave me 172.17.0.3, but on that it didn't work either. I guess it shouldn't have anyways, because I can communicate with OCB by localhost:1026 as long as I do it via cUrl or Insomnia. I can push new entities, update and so on.
The accumulation server that has not been working (link here) is ok right now. But the thing is, I add subscription by myself and can't run the acc server on localhost (loopback interface), but rather on other avaliable interface, then add ip of that interface to subscription payload that i send to OCB. Maybe there is a conflict with Freeboard somewhere.
The issue here was connected to lack of CORS support. The easy solution for this is just enabling CORS functionality while launching Orion Context Broker as described here.
I have conducted quite an (actually unnecessary) research on this topic and came up with over-the-top solution for the problem which is described in this github post. There is a proxy server approach for solving the issue. I wanted to propose adding CORS support to Orion Context Broker, and was kindly surprised when found out about it being already implemented.
There are posts like this, this and this which was very helpful in solving the case.
However, I have a two requests. I guess #fgalan is a go to person right now, regarding back-end and documentation of OCB and peripheral software.
Can there be a stronger emphasis put on CORS and ACCESS-CONTROL-ALLOW-ORIGIN soulution? The reasoning behind it is that it gives a seamless connection between OCB and any front-endy application or site (i.e. Freeboard) running in internet Browser. It shouldn't be so hidden that I came across the solution for my problems just by accident while looking for something else. I guess putting it in some walkthrough documentation on I don't know some other visible place. The problem is that I spent two weeks trying to solve it and after all went for the over-the-top and unnecessary solution while the easy and accessible was just under my nose. Good thing is that I have a good connection on stack and git so it was resolved. There are probably people that gave up on Freeboard after any slip with it. And it's a shame, because for now there is no better opensource piece of software for visualization than Freeboard. And the problem is not only with Freeboard, as I said it concerns many more front-end applications and solutions. As we go with FIWARE's way of thinking, those things should be resolved differently.
The FIWARE datasource plugin for Freeboard is not worth a dime at the moment. As #fgalan pointed out in comment it was developed for v1 version of Orion Context Broker API and has not been updated. Therefore it's way more complicated than it's suppose to be. As documentation of OCB fairly point out, v1 approach is not really RESTfull like. After conducting a short code review of OCB plugin for Freeboard I can say that's not worth using. As far as I understand it should still be working, because OCB allows for v1 request to be conducted (but it doesn't work for me anyway), those request are deprecated. In my opinion new post regarding topic should appear (not sure who should I contact about it), because this is a bit misleading. What's the point of using piece of software that's deprecated and spreading bad habits regarding interacting with OCB?
Solution for this is in my opinion simple. Just use JSON datasource in Freeboard. I understand motivation behind creating individual datasource plugin for Freeboard in 2015, when there was not RESTfull v2 version of OCB API, but there is one now, so why not use it? I used ever since got rid of difficulties with CORS and it works pretty well in my opinion. Freeboard as I said earlier provides great opportunities while being easy in setup and maintenance. It should not be abandoned so easily.
By using GET request for JSON payload in Freeboard, now we have whole access to query for context from OCB. It doesn't need any POST methods as long as we use Freeboard as it supposed to be used (by querying for data to visualize). Throw in
?options=keyValues
to the request's URL and we've gotten ourselves a really smart and compact way of visualizing data coming from the Broker.
That's just the way I thing it should be resolved. Last update on this topic coming in 2015 is just not enough in my opinion, especially if there were better methods developed on accessing context data from OCB.
Does anyone know of an elasticsearch client library for iOS? Would be a bonus if it was written in swift as well.
The elastic search 'clients' section shows multiple libraries for a number of platforms but nothing for iOS, I feel like someone must have done this?
Cheers
I doubt that anyone has - last time I checked there were none and for good reasons. Keep in mind that in order to allow an IOS client (or Android for that matter) to use a client library to connect to Elasticsearch you'd have to open up your cluster for either an http or node access - which would allow anyone to do anything to your cluster.
Maybe you could proxy it to prevent deletions and insertions but even so it would open up your cluster's data and open you up to DoS attacks.
Generally a better idea is to create your own REST API that incorporates some type of authentication and authorization and does not open up your cluster to the world.
If you still feel strongly about moving forward you can always just hit the http interface of the REST API for ES. Or take a look at this project someone was working on a few years ago at least to give you a head start:
https://github.com/tallpsmith/ElasticSearchIOSHead
Some recent discussions on this topic:
http://elasticsearch-users.115913.n3.nabble.com/Objective-C-client-for-ElasticSearch-iphone-ipad-etc-td3911216.html
Running Elasticsearch server on a mobile device (android / iphone / ios)
This may be what you're looking for. ElasticSwift. Seems to be in active development but haven't looked deep into how far they've gone.
This is another iOS Swift client that was made back in 2018: Appbase-Swift. It's a lightweight ElasticSearch/appbase.io client. Doesn't seem like it's been updated in awhile though.
We tried a lot for elastic and finally concluded that it on most of the challenging side. another thing is a bit bulky to use on mobile, as per my understanding no room for the optimization. We can only use HTTP Web Service call for the same service. Also, the flavor of the offline search can not be implemented in the mobile elastic till date...
Obviously there are multiple steps and phases of implementing such a thing.
I was thinking I would eventually have a webserver that takes http json requests from the ios app, and then queries the cassandra backend and sends results back. I could load balance and all that fancy stuff still, and also provide a logical layer on server side, and keep the client app lightweight.
I'm not sure i understand how cassandra clients fit though. It seems like the cassandra objective c client could eliminate the need for the above approach.
I saw another question and answer but it wasnt clear, perhaps because it varys on the need.
An iPhone app should not directly connect to a Cassandra backend or any other DB store.
First of all, talking to a database often requires adapting a very specific binary protocol (for Cassandra in particular, binary CQL or Thrift). Writing an adapter that would let your Objective-C app communicate in this binary protocol is a major piece of work, and could easily cost more than the rest of your app in effort. If you hide the DB behind a web-server, however, you will be able to select from a variety of existing adapters available in different server-side languages, meaning that you don't need to redo all that low-level work. You'll only be responsible for a relatively small piece of server-side code that would translate your REST queries and forward them to one of the Cassandra adapters (which expose easy-to-use interfaces).
Secondly, if you wanted to connect to a remote database from the phone, your database server would have to open its ports to the internet at large, which is a very bad security practice, even if you use SSL and user credentials. Again, if you hide behind a web server, you will be putting in a layer of technology that has evolved for decades to remain secure on the public internet.
Finally, having your phone talk to Cassandra directly is a poor architectural pattern. When you write apps that communicate on the internet, you want them to know as little as possible about each other, only how to talk to each other (preferably in a standard protocol). That way you can replace or upgrade individual components while keeping everything else the same. This may not sound like a lot, but is actually the main reason why phones, or web browsers, don't directly talk to databases. (If this setup were a good idea in principle, the first two problems could be easily solved given enough engineering effort.)
The approach you first suggested with JSON and the web server is the only correct way to go.
Use something like RESTful API, there are many reasons for that.
if your servers ip addresses change you have to update all client, if you add more nodes you will need to update all clients, if you decide to upgrade your cassandra and some functions change your clients will break and you need to update all clients.
I am about to start an iOS two-player game.
Its a card game, and is played turn by turn.
After going through a lot of articles and blog posts,
I have decided to go with these:
node.JS on the backend to respond to API calls.
MongoDB as the database.
and Apples Notification service to push data to other devices.
I am comfortable with JavaScript and I am willing to learn node and mongoDB both and I have some time before the project can start.
I have worked with PHP and Java in the past.
Considering the entire scenario, shall I go ahead with what I have thought or there are things I should consider.
You can also consider google app engine using a java or a python backend as the server side. The most obvious advantage is that you wont have to worry about infrastructure hassles as GAE is a managed service. GAE has a high replication datastore similar to mongo and you can code the backend in java which you already know.
I have a software architecture problem.
I have to design an IOS application which will communicate with a Linux application to get the state of a sensor, and to publish an actuator command. The two applications run in a Local network with an Ad-Hoc WiFi connection between the IOS device and the Linux computer.
So I have to synchronize two values between two applications (as described in figure 1). In a Linux/Linux system, I resolve this kind of problem thanks to any publisher / subscriber middleware. But how can I solve this problem in an IOS / Linux world ?
Actually the Linux application embed an asynchronous TCP Server, and the IOS application is an asynchronous TCP client. Both applications communicate through the TCP Socket. I think that this method is a low level method, and I would like to migrate the communication layer to a much higher level Service based communication framework.
After some bibliographic research I found three ways to resolve my problem :
The REST Way :
I can create a RESTful Web Service which modelize the sensor state, and which is able to send command to the actuator. An implementation of a RESTful web service client exists for IOS, that is "RESTKit", and I think I can use Apache/Axis2 on the server side.
The RPC Way :
I can create on my Linux computer a RPC service provider thanks to the libmaia. On the IOS side, I can use xmlrpc (https://github.com/eczarny/xmlrpc). My two programs will communicate thanks to the service described in the figure below.
The ZeroConf way :
I didn't get into detail of this methods, but I suppose I can use Bonjour on the IOS side, and AVAHI on the linux side. And then create custom service like in RPC on both side.
Discussion about these methods :
The REST way doesn't seem to be the good way because : "The REST interface is designed to be efficient for large-grain hypermedia data transfer" (from the Chapter 5 of the Fielding dissertation). My data are very fined grain data, because my command is just a float, and my sensor state too.
I think there is no big difference between the ZeroConf way and the RPC Way. ZeroConf provide "only" the service discovering mechanism, and I don't need this kind of mechanism because my application is a rigid application. Both sides knows which services exists.
So my question are :
Does XML RPC based method are the good choice to solve my problem of variable synchronization between an iPhone and a Computer ?
Does it exist other methods ?
I actually recommend you use "tcp socket + protobuf" for your application.
Socket is very efficient in pushing messages to your ios app and protobuf can save your time to deliver a message instead of character bytes. Your other high level proposal actually introduces more complications...
I can provide no answers; just some things to consider in no particular order.
I am also assuming that your model is that the iOS device polls the server to synchronize state.
It is probably best to stay away from directly using Berkeley sockets on the iOS device. iOS used to have issues with low level sockets not connecting after a period of inactivity. At the very least I would use NSStream or CFStream objects for transport or, if possible, I'd use NSURL, NSURLConnection, NSURLRequest. NSURLConnection's asynchronous data loading capability fits well with iOS' gui update loop.
I think you will have to implement some form of data definition language independent of your implementation method (RES, XML RPC, CORBA, roll your own, etc.)
The data you send and receive over the wire would probably be XML or JSON. If you use XML you would have to write your own XML document handler as iOS implements the NSXMLParser class but not the NSXMLDocument class. I would refer JSON as the JSON parser will return an NSArray or NSDictionary hierarchy of NSObjects containing the unserialized data.
I have worked on a GSOAP implementation that used CFStreams for transport. Each request and response was handled by a request specific class to create request specific objects. Each new request required a new class definition for the returned data. Interactivity was maintained by firing the requests through an NSOperationQueue. Lots of shim here. The primary advantage of this method was that the interface was defined in a wsdl schema (all requests, responses, and data structures were defined in one place.
I have not looked at CORBA on iOS - you would have to tie in C++ libraries to your code and change the transport to use CFStreams Again, lots of shim but the advantage of having the protocol defined in the idl file. Also you would have a single connection to the server instead of making and breaking TCP connections for each request.
My $.02
XML RPC and what you refer to as "RESTful Web Service" will both get the job done. If you can use JSON instead of XML as the payload format, that would simplify things somewhat on the iOS side.
Zeroconf (aka bonjour) can be used in combination with either approach. In your case it would allow the client to locate the server dynamically, as an alternative to hard-coding an URL or other address in the client. Zeroconf doesn't play any role in actual application-level data transfer.
You probably want to avoid having the linux app call the iOS app, since that will complicate the iOS app a lot, plus it will be hard on the battery.
You seem to have cherry picked some existing technologies and seem to be trying to make them fit the problem.
I would like to migrate the communication layer to a much higher level Service based communication framework
Why?
You should be seeking the method which meets your requirements in terms of available resources (should you assume that the client can maintain a consistent connection? how secure does it need to be?) However besides functionality, availability and security, the biggest concern should be how to implement this with the least amount of effort.
I'd be leaning towards the REST aproach because:
I do a lot of web development so that's where my skills lie
it has minimal dependencies
there is well supported code implementing the protocol stack at both ends
it's trivial to replace either end of the connection to test out the implementation
it's trivial to monitor the communications (if they're not encrypted) to test the implementaiton
adding encryption / authentication does not change the data exchange
Regards your citation, no HTTP is probably not the most sensible for SCADA - but then neither is iOS.