I'm developing a tool that will comprise a central website and a desktop application. I've only really done entirely online developent, or entirely offline/client-side development before and not really had to link the two. I could use some help in how to approach passing data to/from the online site & desktop app.
The desktop app needs to communicate & do some control of iTunes, so initially I'm building this in Cocoa on OSX & making use of the ScriptingBridge framework.
On the website side I'm thinking of using Ruby on Rails, with data stored in a mySQL database, as I'm fairly familiar & seems like a good match for the online job it has to do. (But open to other suggestions if there's a better approach!)
I'm struggling to find the best approach to easily transfer data between the Cocoa app & the online rails database - is there a simple way of having the Cocoa app access the online database directly, or is it typical to dump some XML onto the webserver and have the app read that?
Opening a RESTful API on your RoR system is as simple as you can get. Have your desktop app communicate with that API using JSON or XML.
Advantages to using JSON rather than XML: (1) extremely simple to manipulate in Rails (2) extremely simple to work with in Javascript, should the need arise to build a web client in addition to the desktop one.
It's a very bad idea to have the desktop app communicate directly with your remote database. Two main reasons:
Security. Such a setup just begs to be hacked. Some databases are "built for the web" (CouchDB comes to mind) and would be alright here, but MySQL isn't.
Flexibility. With desktop application in the field, making changes and distributing them to all clients is hard. Should the need arise to change your schema, the web application layer frequently allows you to keep the interface with the desktop clients stable.
Related
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.
I have a database on a database server. No web service in place to be consumed by a web application.
If I want my iOS app to communicate with a database server (send & receive data), I know I can create a web service and then call that service from my iOS app. But what web service is recommended for this? Should I just write a .asmx web service in .NET or should I go for MVC WEB API or may be go for WCF ?? I have spend hours doing research on this. Please help.
A lot will depend on where you expect the service to be hosted, and what technology stack(s) are supported by the host. If you are self-hosting, then do whatever works in the technologies you know and understand. If you want to use a host that targets its services to small-to-midsize independent development teams, many providers like Heroku support things like Rails services. PHP is always an option as well. Microsoft-based solutions and Java-based solutions tend to be more widely used in larger enterprises and data centers, and if that's where you'll host your service then these would also be good options. And of course I'm speaking in broad generalities here: For any general trends I might list here there are lots of exceptions where other approaches make sense.
If you'd rather let the decision be driven by what makes things easiest for your iOS code, I would recommend you start with server-side technologies that support REST-ful interfaces using JSON to represent your service's resources. REST-ful services are very easy to consume from iOS, and JSON-based representations of resources are very easy to parse and produce in Objective-C.
I am personally used this approach to set a direction for my app. For the service side, I am going with a Rails implementation of REST-ful web services. I'm a Java developer by profession, but for a small independent project the options for hosting Java services were more limiting than with Rails so I've picked up rails on the side to make my project work. So far it's suited my project quite well.
I am very new to IOS development.I wonder which language/framework everyone is using to create RESTFUL web services for high traffic, scalable IOS app backend.
The solution requires:
1. Secure Login
2. Restful web services (JSON)
3. High traffic
4. File upload/download
5. Quick search result from large volume database
I am from .NET and MSSQL background. I heard people are using PHP, Java, Python, RoR with IOS webservice development. I understand every language can have pros and cons, just want to know what is prefered in today's trend.
And for database, is NoSQL database a prefered choice than RDBMS for scalable large volume databse? I am checking MongoDB.
Apologies if I am asking wrong questions. I am investigating the technologies for this new project, and any input will be greatly appreciated!
Thanks
I have worked in three major projects that all of them have desktop clients, web clients, and mobile clients (Android, iOS). The 3 have completed different server side approach, and all of them make me and the users happy:
Project 1:
Server: Delphi + RemObjects
Clients: Delphi desktop apps, PHP Web apps, Java applets, Android apps, iOS apps
Why Delphi? Because the existent project was already a Delphi multi-tier app, the development team have domain of Delphi platform, ans was easy with RemObjects (or even with the standard DataSnap) to return JSON, SOAP or XML-RPC to be invoked by the clients;
Project 2:
Server: PHP
Clients: ExtJS Web apps, Android apps, iOS apps
Why PHP? The development team was experienced with PHP, the projects was originally a PHP web app with some classes well defined and not coupled with the UI. Some new classes in the server that reused the existing code base, just converting to/from JSON were enough to allow the clients to talk to the server, with minimum effort.
Project 3 (initial development):
Server: C# ASP.NET
Clients: ASP.NET apps, Android apps, iOS apps
Why C#? Again: the development team was experienced with C# and ASP.NET, the projects was originally an ASP.NET app. We are refactoring some app logic into web services that will be consumed for both the ASP.NET app and the clients.
As you see, there is no need to make the team learn something completely new on the server side.
I'd suggest you to keep your development in .NET with MSSQL, taking advantage of your current skills.
If the application traffic grows you can move the server app to an IaaS server (like Amazon AWS EC2) that supports SQLServer, or even better to a PaaS server, which in this case Windows Azure will probably be your best friend.
These are all loaded questions that can't be answered without more information about what you're making, etc. I use a combination of Ruby with Sinatra and DataMapper (and SQLite/PostgreSQL) for most of my projects, but that's my personal preference and probably won't be of much help to you.
Rather than choosing a technology stack based on trends, why don't you just pick something with a good user base for help and go from there?
I have built two rails apps that need to communicate and send files between each other. For example one rails app would send a request to view a table in the other apps' database. The other app would then render json of that table and send it back. I would also like one app to send a text file stored in its public directory to the other app's public directory.
I have never done anything like this so I don't even know where to begin. Any help would be appreciated. Thanks!
You requirement is common for almost all the web apps irrespective of rails, Communicating with each other is required by most modern web apps. But there is a small understanding that you need to get hold on,
Web sites should not directly access each others internal data (such as tables), (even if they are build by the same language (in this case Rails) by the same developer),
That is where the web-services comes in to play, So you should expose your data through web services so that not only rails application can consume that, but also any app that knows how to consume a web service will get benefit.
Coming back to your question with Rails, rails supports REST web services out of the box, So do some googling about web services, REST web services with rails
HTH
As a starting point, look at ActiveResource.
Railscast
docs
Message queuing systems such as RabbitMQ may be used to communicate things internally between different apps such as a "mailer" app and a main "hub" application.
Alternatively, you can use a shared connection to something like redis stick things onto a "queue" in one app and read them for processing from the other.
In recent Rails versions, it is rather easy to develop API only applications. In the Rails core master, there was even a special application type for these apps briefly (until it got yanked again). But it is still available as a plugin and probably one day becomes actually part of Rails core again. See http://blog.wyeworks.com/2012/4/20/rails-for-api-applications-rails-api-released for more information.
To actually develop and maintain the API of the backend service and make sure both backend and frontend have the same understanding of the resources, you can use ROAR which is great way to build great APIs.
Generally, you should fully define your backend application with an API. Trying to be clever and to skip some of the design steps will only bring you headaches in the long run...
Check out Morpheus. It lets you create RESTful services and use familiar ActiveRecord syntax in the client.
I have a Rails application that right now is pretty standard: Heroku/PostgreSQL backend, users go directly to my site to update data, there's no mobile app or anything. We're going to start licensing out the tech to other companies, so that different versions of the interface live on company1.mywebsite.com, company2.mywebsite.com, etc, where all of these interfaces share the same database.
I want some advice on how to go about building this. Do I create a separate Rails app for company1, company2, etc (with a lot of redundant code) and then set up each of them with API keys to query my master app, using its RESTful routes?
Any tutorials to point me to would be great as well.
I recommend you the book Service Oriented Design with Ruby and Rails, by Paul Dix. It has a lot of info about the kind of system that you want to build.
To answer your question:
Build an API server. It serves a JSON – for example – RESTful interface.
api.mydomain/client1/users.json
Build a frontend server. It consume the API service – using typhoeus for example – and serves the final pages. It uses a subdomain or domain name for identification of different clients.
client1.mydomain/users
We have a similar "platform".
What we did:
build a master API app (REST + Push)
build a core plugin for rails which has all the shared code
build a separate rails app for each client which has all the client specific code
We are using this setup for 3 years now and I'm pretty happy with it.