I'm really intrigued by the meteor.js framework. However, I'm not certain whether or not I can take advantage of the framework's real-time capabilities via the objective-C's native objects such as NSURLConnection. I have some specific questions referencing this question on how meteorjs works: How does the Meteor JavaScript framework work?
Let's start with web sockets:
The client/server messaging is done via websockets using something
like socks.js or socket.io.
Is there an objective-C library or framework for utilizing websockets in native apps that would be able to communicate with a Meteor server?
Second, is the mongoDB client:
The client side connection to mongodb is really cool. It replicates
the mongo-server driver into the client. Unfortunately, last I
checked, they were still working on securing this database connection.
This seems like the most intriguing part of meteor. However, does this mean there is no standard way to communicate to the meteor server other than executing strings of javascript in a hidden UIWebView?
For anyone interested in this, I've been working on an objective ddp client library here. I've only just started and there is no documentation yet, but everything works well. The project is here: https://github.com/boundsj/ObjectiveDDP
The specs for the ddp client are here: https://github.com/boundsj/ObjectiveDDP/blob/master/Specs/ObjectiveDDPSpec.mm
I'm also building a library for meteor auth so ios clients can authenticate with a meteor server using the password package. It's all put together and working in this sample todo app (also part of the same repo): https://github.com/boundsj/ObjectiveDDP/tree/master/Example
not a full answers but hopefully a few pointers to get you started.
Meteor uses a protocol called DDP - Distributed Data Protocol. The blog post introducing it is here: http://meteor.com/blog/2012/03/21/introducing-ddp
There is an Objective-C client library on github here: https://github.com/alansikora/objective-c_ddp-client Although I can't vouch for it and it has no real documentation, the code is short and should be reasonably understandable by someone who already writes Objective-C.
Other than that I would suggest digging in and see if you can uncover any techniques for iOS clients. It's early days for Meteor and were all learning how to use it.
Related
I'm responsible for a project that is producing the server backend for an iOS application.
I would like to formally define the service interface for the clients to call so both the IOS, Android and server teams can practice contract-first development.
In the dark past we would have used WSDL and generated RPC-style client and server interop boilerplate from that. However this isn't the norm for IOS projects. We've also looked at Apache Thrift, but there is no code generator for Swift and the Objective-C generator seems to produce code that relies on deprecated IOS APIs.
Which brings us to REST, which works well as a way to move object state around. It seems less good for the kind of conversation that says "Hey server, do X with these parameters and return me a result." We just end up creating server-side controllers for particular actions, and those "define" the service's calling convention by being sticklers for getting the right parameters. Contract-last.
Is there a standard way to do contract-first web service development for iOS clients, or am I just going to have to treat documentation as the spec?
tl;dr: No.
I'm not aware of a 'standard' way of doing things, but many
client/server apps today do use some incarnation of a RESTful
interface. JSON is the usual format.
There are some well documented 3rd party utilities that can handle
this for you client side (like [RESTKit][1] in the case of REST), or
you can roll your own implementation based on apple's provided
NSURLSession or a networking library like [AFNetworking][2]
If needed, iOS can also handle socket-based communication. (3rd party
libs exist for this as well.)
[1]: https://github.com/RestKit/RestKit [2]:
http://nshipster.com/afnetworking-2/
I am working on a chat service with some unique features in it, and thinking about a server to dispatch messages and do all the IM-related stuff. First-priority client is going to be for iOS, built with Swift.
Is it feasible to create server, based on NodeJS Express, or may be Loopback? I have had a look at multiple choices, including ready solutions, like QuickBlox, Parse.
As for creating it from scratch, I think about NodeJS or Erlang.
At what stage should I make a decision so that not to waste too much time on reconfiguring everything for scaling and rapidity and convenience of development?
With technologies like Socket.io, Node.js, and Express, you could make a chat application fairly quickly.
Sockets are typically the best solution and the most common route to implementing a chat system, as they provide two way communication between the client and the server.
You could use practically any backend for a socket server, but it may end up being quicker to use Node.js and socket.io depending on your comfortability level with JavaScript.
All you would need is a socket compatible server and a client side library that connects to a socket server - there are plenty of JavaScript libs out there, including a socket.io-client.
Check out socket.io's chat demo on their site for a quick look at how it works:
http://socket.io/demos/chat/
They even provide a first party iOS Swift client:
https://github.com/socketio/socket.io-client-swift
Personally I recommend you to checkout SailsJS, a great framework for building API & chat server at the same time. It adopts socket.io internally so every route in a Sails app is compatible with socket.io (in other words, you can decide to call an API request via Socket anytime you wish!)
I've built a complete, working iOS App having chat feature. Its backend was completely developed using SailsJS. It saved me hundreds of hours. Sails documentation also mentions about scaling for production. Please have a look at http://sailsjs.org
Im new to iOS and new to SWIFT with no previous experience with Obj-C. But, Im not new to Ruby. I have a web based app on heroku and am beginning to learn SWIFT so I can build an iOS counterpart. I need to wrap my head around the bigger picture before I can get started and I can not figure out how these apps connect to databases.
Can an iOS app connect to an S3 database...and share that database with a website? Is there documentation on this process that I have over looked.
Connecting an iOS app to a public database would really be a bad idea - all server logic should be implemented on the client, and you would also need to hardcode database user name and password in your app.
A better way is to create a server app exposing a set of REST APIs and being responsible of dealing with the database. This way you can better control at server side what the app client is able to do on the database.
If you have an order entry app, for instance, you can create APIs to:
login
register
create an order
modify an order
add a contact
delete a contact
etc...
Some of the advantages are that:
in case you need to update the logic (but not the API interface), you just need to update the server, whereas in your scenario you'd need to release a new version of the mobile app
you control and limit how client apps access to the data (preventing for instance a user to access another user's orders)
if you want to develop the same app in another platform (android, ...), you reuse the same APIs
To get started, I'd suggest you to read the AFNetworking tutorial on raywenderlch.com, focused on a ios networking library, but talking about JSON, REST, remote APIs etc.
Next you have to choose a server side technology - the most popular nowadays is node.js - to get started you can read other tutorials on the same website:
http://www.raywenderlich.com/61078/write-simple-node-jsmongodb-web-service-ios-app
http://www.raywenderlich.com/61264/write-ios-app-uses-node-jsmongodb-web-service
if you don't want to use node.js and/or mongodb... the same architecture applies, just languages and technologies differ. Just transpose what you learn from there.
If you want to read about other languages to use at server side, just google for it - if you want to use ruby, try with ios rest api server ruby.
Note: I made no mention of swift because your question looks more like an architectural problem than a language specific problem. The tutorials I mentioned here use objective-c, once you've designed an architecture and chosen the language at server side, you can start looking into how to call REST API from swift.
We are building an application that consists of a web app and a native iOS client. The web app is pretty straight forward with Meteor. But on the Native iOS App was wondering if someone can give us some pointers on the best practices for that app to call into meteor. I have seen that there is something like the collectionsapi api which exposes meteor collections over http, but am not sure how we would handle authentication for Native iOS clients if we used something like the collectionsapi or similar. Any pointers from some folks who have done this would be greatly appreciated.
Meteor's communication system is based on DDP (Distributed Data Protocol). You can access meteor's methods & make subscriptions to data which is probably the best way to go since you can get live data back too!
There is an objective-c client but its not been maintained : https://github.com/alansikora/objective-c_ddp-client
The ddp client was originally made prior to an official ddp specification (pre1). So you would have to adjust the client a bit to bring it up to date. Luckily its not too much work. The full DDP spec can be found here: https://github.com/meteor/meteor/blob/master/packages/livedata/DDP.md
Using DDP is a very attractive alternative to making a traditional REST request (POST,GET,PUT,etc). As the data on the wire is the same system meteor's client communicates to its server. So if you're able to make something on meteor work in a web browser you could pretty much replicate it on a native iOS client.
If you are still wondering about this, I've been working on a free, open source project that enables native ios clients to do meteor auth (SRP auth) and communicate via DDP. The project lives here: https://github.com/boundsj/ObjectiveDDP
There is an example app here: https://github.com/boundsj/ObjectiveDDP/tree/master/Example
I'd like to create a service, similar to a chat application (realtime app).
From what I can see from my research, BlazeDS is the preferred way, but it involves Java and Java EE. Also, the latest Ruby results seem to be from 2009-2010, so they are likely outdated.
Are there any actively maintained Ruby/Rails solutions for integrating push notifications with Flex?
The current situation
Do you have to use Flex? HTML5 websockets is a nascent but growing technology and there are implementations now. Flex's days are numbered. Yet, websockets doesn't yet have native support in IE.
em-websocket is a ruby websocket server based on eventmachine. The service Pusher is based on it.
Faye is a websocket server and client. (Railscast)
There are other Ruby implementations such as Cramp and Socky.
If you're open to servers in other technologies such as Node, there are many with Ruby or Javascript clients ready to go.
Update: I might mention that I looked into doing something similar with Flex a while back, and got a copy of Flex on Rails. The book's server push example uses Juggernaut, which unfortunately has stopped further development. The author states that Server-Sent Events (SSEs) make Juggernaut redundant. All major browsers except IE support them natively, similar to the situation with websockets.
There are shims ("polyfills") that use javascript to bring these missing capabilities to the browsers. For example, the jQuery Graceful WebSocket is a jQuery plugin that implements a websocket client but falls back to AJAX polling so the functionality will still work in IE, just won't be quite as instant. Because it detects websocket support, as soon as a browser supports websockets they will be used.
Bridging the Gap
We seem to be caught in a transition period, where we are at the sunset era of Flash but not yet at broad support for its replacement technologies. There is one library that may bridge the gap: Socket.IO. This library selects the most capable technology transport at runtime. It will use Flash if present, but can also use websockets, AJAX long polling, AJAX multipart streaming, a "forever iframe" if necessary. This gives it broad browser support:
IE 5.5+
Safari 3+
Google Chrome 4+
Firefox 3+
Opera 10.61+
iPhone Safari
iPad Safari
Android Webkit
WebOS Webkit
This is actually broader compatibility than either Flash/Flex or WebSockets alone. Socket.IO is implemented in Javascript for both server and client, so you need a server-side Javascript runtime such as Node.
Possible solutions
While there don't seem to be many current references to a Rails 3 -> Flex solution (as you have found), it appears there is some traction with the combination of Ruby/Rails and Socket.IO.
If you want to add chat to a Rails app using Socket.IO, there's a nice reference blog post by Liam Kaufman who creates a chat app in Rails 3 using Socket.IO: http://liamkaufman.com/blog/2012/02/25/adding_real-time_to_rails_with_socket.IO_nodejs_and_backbonejs_with_demo/
There's also a socket.io gem which adds support to the Cramp server mentioned above.
There also seem to be other stackoverflow questions with others working on the Rails 3 and Socket.IO combination.
TL;DR summary
While there isn't much indication that folks are doing direct-to-Flex from Rails anymore, there are other solutions with the most promising being a combination of Rails and Socket.IO.
If you want to live within the Ruby world, you can use regular WebSockets to talk to a Flex application. It won't be pretty, but it would work, and you could avoid the Java back-end. This would be a lot more raw than telling BlazeDS to fling structures around, but it should be doable.
On the Flex client side, there is a library written by Kaazing, that is bundled with their WebSocket servers. Download one of their WebSocket servers, and in the client-libs folder, there should be a swc (with docs) that you can use to talk to em-websocket (or really, any websocket tech).
Now, all this being said, you won't have nearly the scaleability of BlazeDS or GraniteDS, but it should work for smaller implementations and demos.
You can use https://github.com/rubyamf/rubyamf or https://github.com/victorcoder/rubyamf_plugin
But you will be have problem with realtime messaging because rubyamf and rubyamf_plugin don't support RTMP.
You can use the RestfulX gem & Flex framework. That's what I use for Rails/Flex.