My question might be too easy. But i come from web development background and just started creating iOS app by learning from here and there. I have made 2 prototypes, but the second one need backend, cms.
From my prev experience i used php, mysql, html, css. I custom made the cms to organize my content and all user data, etc would be stored into database and can be maintained from the cms.
I use swift, but i seem to miss something important. in ios area what are the tools to develop the db (not local storage, coredata, and such) and maintain that; like what i used to use in web dev area? i dont even know how to ask the right question, but i really hope you guys would understand
can you guys give me direction? a link to basic knowledge of this will be fine
thanks
I think usually it will be database on a server and you will send requests and get answers in JSON format. You will have to parse them and use in your app.
Related
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.
Before I begin, I have only just started learning how to code so please presume no prior knowledge. Everything I learn from you guys will be a first for me :)
My friend has a website created using WordPress and has asked me if I can figure out how to implement a program into his page. Specifically, he wants the site to contain a playable computer game that interacts with his page.. like desktop destroyer for example.
What I need to learn:
1) I need to know what language wordpress uses to build their pages
2) Do i need to learn another language like ruby on rails and embed that into the page?
3) Where to start...
I'm pretty much starting this completely from scratch so any other helpful guidance is very much appreciated!
Wordpress uses PHP to build it's pages. I think it would be very hard to make a video game in PHP: AFAIK there hasn't been much in the way of graphical library work done for it.
What you would probably end up doing is to make a standalone game, probably using Javascript and Html5 (Flash used to be the best choice for this but of course it's not supported in iOS which makes it a bad choice now). Get your game working in an empty browser page, then you can embed it into your wordpress site.
If you've already got the game, and just need to include it in the wordpress page then that's simple. You can just embed it: it runs client-side so php doesn't even have anything to do with it (PHP just runs on the server, like Ruby on Rails).
EDIT: just realised, it's not just "very hard" to write a game in PHP, it's impossible, since it's a server-side tech and the game engine would need to run in the browser. Duh. You could of course handle the back end with php - saving and loading data from a database for example.
Where to start
Look at what you want to achieve - you want to make a "game" in a Wordpress site - this will be less about Wordpress and more about the game.
#Max Williams summed it up pretty well - a "game" online is comprised of two elements - the front-end and back-end.
--
Games
The back-end is basically an API which connects to the DB & server. This would be where the likes of PHP / Rails would come in - a way for you to interact with data on your server
Even games such as World Of Tanks use this setup; the front-end gives you an interface to interact with the data provided by the back-end.
In reference to your PHP / framework question, you need to realize that your Wordpress site will just serve a framework of pages, in which you'll be able to include a game. The inclusion of the game would be to load either a flash or, even better, a java app which will be dynamic & sprite-based
The front-end app will basically take your inputs / interactions, and send them to the backend. This will typically by done with a perpetual websocket connection, but can be achieved in other ways too
Finally, for each request which is received by the server, it will respond with data the app has to factor into the game experience. Sounds complicated, but it's quite simple (not easy) when you think about it logically
So, my cohorts and I have been doing some development with Phonegap +jQueryMobile for an application we've been planning to rollout. We switched off doing this natively for iOS and Android, since its mostly html anyway, and phone gap seemed like a great way to do this without having to write a whole bunch of platform specific code (although we're more or less newbs when it comes to this type of development.)
Previously, all the html, javascript, etc, was going to be housed in the app itself. For the most part, this seemed to work for us, and we advanced our design/testing/etc accordingly. However, things have changed in our approach. For each of our customers (once they go through a log-in/authentication) has a 'starting' html file (essentially 'their' index.html) that is specific to said customer. This was different from before where everyone had the same files.
Now I've played around with storing certain scripts on the web server to try and off-set opening the html running on the server, but it's not really that useful when trying to integrate some of the functionality like the camera or some of the other plugins we're trying to use. It's essentially a form-based application, so this is the ONLY file that will change from customer to customer. Also, this will not be something that changes frequently. For the most part, it will be setup for a customer ONCE AND ONLY ONCE, and it truly is unlikely to change.
Is there a way to more or less pull down this html file from a web server to replace the one that is stored internally in the app, and then load that version? Would doing something like that (if its even possible) violate Apple's or Google's App guidelines? Or is what I'm describing not even possible in the framework?
The only other thing I can think of would be to change the stored 'index.html' file to not load any of the form itself, but rather make ajax (or equivalent) calls to do so, but I've been told by our developer working the web design side of things that it would be a huge pain.
Any insight/knowledge would be appreciated.
If you really need to do this (I don't quite understand why), I think your best bet is to go the AJAX route. At least Apple does not look kindly on applications that update themselves without going through the App Store submission process.
You can do the same index.html for all and a script config.js that be the responsible of load/unload resources/html of each user at app start.
All you need to do then is save that config JSON values in localstorage and go.
We are planning to make a "large" website for I'd say 5000 up to many more users. We think of putting in lots of real time functionality, where data changes instantly propagate to all connected clients. New frameworks like Meteor and DerbyJS look really promising for this kind of stuff.
Now, I wonder if it is possible to do typical backend stuff like sending (bulk) emails, cleaning up the database, generating pdfs, etc. with those new frameworks. And in a way that is productive and doesn't suck. I also wonder how difficult it is to create complex forms with them. I got used to the convenient Rails view helpers and Ruby gems to handle those kind of things.
Meteor and DerbyJS are both quite new, so I do expect lots of functionality will be added in the near future. However, I also wonder if it might be a good idea to combine those frameworks with a "traditional" Rails app, that serves up certain complex pages which do not need realtime updates. And/or with a Rails or Sinatra app that provides an API to do the heavy backend processing. Those Rails apps could then access the same databases then the Meteor/DerbyJS app. Anyone thinks this is a good idea? Or rather not? Why?
It would be nice if anyone with sufficient experience with those new "single page app realtime" frameworks could comment on this. Where are they heading towards? Will they be able to handle "complete" web apps with authentication and backend processing? Will it be as productive/convenient to program with them as with Rails? Well, I guess no one can know that for sure yet ;-) Well, any thoughts, guesses and ideas are welcome!
For things like sending bulk emails and generating PDFs, Derby let's you simply use normal Node.js modules. npm now has over 10,000 packages, so there are packages for most things you might want to do on the server. Derby doesn't control your server, and it works on top of any normal Express server. You should probably stick with Node.js code as much as possible and not use Rails along with Derby. That is not to say that you can't send messages to a separate Rails app, but since you already have to have a Node.js app running to host Derby, you might as well use it for stuff like this.
To communicate with such server-side code, you can use Derby's model events. We are still exploring how this kind of code works and we don't have a lot of examples, but it is something that we will have a clear story around. We are building an app ourselves that communicates with an email server, so we should have some real experience with this pretty soon.
You can also just use a normal AJAX request or send a message over Socket.IO manually if you don't want to use the Derby model to do this kind of communication. You are free to make your own server-side only routes with Express along with your Derby app routes. We think it is nice to have this kind of flexibility in case there are any use cases that we didn't properly anticipate with the framework.
As far as creating forms goes, Derby has a very powerful templating system, and I am working on making it a lot better still. We are working on a new UI components feature that will make it possible to build libraries of self-contained UI widgets that can simply be dropped into a Derby app while still playing nicely with automatic view-model bindings and data syncing. Once this feature is completed, I think form component libraries will be written rather quickly.
We do expect to include all of the features needed for a normal app, much like Rails does. It won't look like Rails or work like Rails, but it will be similarly feature complete eventually.
For backend tasks (such as sending emails, cleaning up the database, generating pdfs) it's better to use resque or sidekiq
Now, I wonder if it is possible to do typical backend stuff like
sending (bulk) emails, cleaning up the database, generating pdfs, etc.
with those new frameworks. And in a way that is productive and doesn't
suck. I also wonder how difficult it is to create complex forms with
them. I got used to the convenient Rails view helpers and Ruby gems to
handle those kind of things.
Also, my question is not only about background jobs, but also about stuff one can might do during a request, like generating a pdf, or simply rendering complex views with rails helpers or code from gems. –
You're mixing metaphors here - a single page app is just a site where the content is loaded without doing a full page reload, be that a front end in pure js or you could use normal html and pjax.
The kind of things you are describing would be done in a background task regardless of the fornt-end framework you used. But +1 for sidekiq if you're using ruby.
As for notifying all the other users of things that have changed, you can look into using http://pusher.com or http://pubnub.com if you don't want to maintain a websocket server.
I am planning to build a website. I can build the front end with html,css and javascript with the help of twitter bootstrap and jquery ui. Actually i have done a bit of work and it looks good to me.
But I am short of knowledge in case of server side language, (just learning python and django in fact).
So is it advised to build by blog without the database things and all? or should i delay it by 3-4 months until i learn server side programming?
Can I do thing like searching posts, sorting them , comment on post with out the use of databases?
Is it easy to transform my blog to a database based one in later stage easily without taking it off the web?
ps: i dont want to use blogging platforms like wordpress.
you can make a website using static web pages. But that wont be really good enough for your users or readers. Besides that you really have to put a lot of time in manually writing the code for each page.
But if you choose to build a dynamic blog that will be better for the readers. You deploy functions like search , comment more easily.
Using a free and open source blogging platform like wordpress will cut down your task. It has ready made themes, plug ins available to get your tasks done and customize your site the way you want.Again it will be far more secure and attractive.
So my suggestion will be to go with wordpress.
And as far as the learning par is concerned you will learn more stuff while working with wordpress than building a static site