I'm making a simple gaming platform. It's supposed to be used only on (W)LAN. One of the devices is running a node.js server, and client devices can be computers, smart phones or tablets. I'm planning to handle all the client-server communication using socket.io, as that makes it possible to have almost real-time connection and to have sessions without having to manage user accounts.
When the user joins a system on a browser, the interactioin goes like this: Starting view ---> game selection view ---> join/create game view ---> game lobby --> actual game.
The question is, what would be a good approach for changing these views? I've thought about some possibilities:
I could load a partial web page (html-document) when a page is changed
I could load one large html-document when joining the system and show/hide divs on a page change
I could use some more complex framework
Which approach would be best, considering that the application will be used on mobile phones and therefore memory usage and battery life are important factors?
I would use Backbone.js Views. It's lightweight, and you can use it without using any other component from Backbone.
Related
So after spending some time with Meteor, I found that this is probably the best isomorphic data-centric framework to build web applications.
I am currently trying to build an HTML5 mobile application for Kids (Under 5 Years), the content of the application should get updated as the child progresses solving and interacting with the available activities. (So new activities should be downloaded at runtime of the application).
Mobile support of Meteor is good. Meteor + Cordova can serve my purpose.
But what I am confused about is:
Is Meteor is the best framework for my use case, where the application is mostly static. No state to be maintained across. (Only the number of levels crossed by the user has to be synced.)
But Application need something like Hot Code Push, (Don't know how to maintain that differently for each account)
If not, then what is the preferred tech-stack to build HTML5 mobile applications/games where it is required to push levels or new activities at runtime and that too differently for different users/clients. (Some might be the premium subscribed users getting extra level/activities on monthly basis.)
We currently have an asp.net webforms web application, which needs updating in terms of look and speed. I think its time to redevelop it and was thinking about creating a webApi and change the website to asp mvc. But then i started using AngularJS and loved it, now i am thinking about redeveloping our site using AngularJs and a webApi.
Am i right in thinking that using AngularJs + ASP MVC is pointless, as they are nearly the same thing (although 1 is clientside and 1 is server side)
Also i have a couple questions about using angularJs on a website.
On the mobile apps that i have used angularJS i have used the routeProvider and stateProvider to change the page. This adds #/SOMETHING to the url and angular loads the correct content accordingly. Does this work ok with search engines like google?
Should the whole web application be 1 app within angular, or should it be broken down into app modules and each be a separate "app", even though it is 1 website? I am wondering about performance. Say i have a website where the user can look at companies, contacts, projects. Each module may have 10 different pages, can angular handle this? In our app we would have over 20 modules, each with maybe 10 pages+.
Is this something i should avoid? Would ASP MVC + webApi be better?
Any other views and opinions are greatly welcome, i want to get as much information as possible before making my decision and developing.
Thanks in advance
Let me try to address some of your concerns.
ASP.Net Partial views can still be used even if you decide to use AngularJS and WebAPI. Have a server view has some advantages. For example if your view has element that are only accessible to authorize users in a specific role, then better to not emit that view content from server, rather than hiding it on client side using AngularJS.
I have not done mobile development using AngularJS so i cannot answer your bullet point 1. But as far as SEO goes every client side framework has the same challenge. Google SEO techniques for Angular and you may find something interesting.
Regarding bullet 2, all depends. Multiple SPA apps can be created if the functionality is tangential. For example user side of app and admin side of the app can be different SPA but they can be a single SPA too. I think it all depends upon on scenario and there is no hard and fast rule.
For bullet 3, this is too broad question. I can only say AngularJS is a very capable framework and can do everything that MVC+ WebApi can achieve. There is a learning curve involved and it takes some time to do stuff the Angular way but i believe it is well worth.
I've just read about single-page web applications that expose a RESTful interface for retrieving the data - for example in JSON format, and that just provide a single HTML page referencing the Javascript file responsible for invoking the RESTful interface and building the web user interface dynamically in the client's web browser.
To implement this in Play, one should implement the controllers so that they return JSON instead of HTLM and implement some CoffeScript for rendering the user interface on the client side.
So far so good... but I'm wondering whether this design makes sense for large web applications since the amount of javascript code to be run on the client side would increase more and more.
My initial idea was to implement the web application using Play's template engine and then to provide a RESTful interface for Mobile apps.
Any suggestion, idea, or link to documentation that covers this topic would be really appreciated ;-)
The Play for Scala book has a chapter on this topic. They use a single view as an entry point, that's it.
As for large applications, that's a valid concern. For that you might want to use libraries such as RequireJS (which Play 2.1 has built-in support for), among others. You also might want to split your app into sub-modules to manage complexity. On the client side, you probably should use a framework, too, such as AngularJS.
Concerning Play there's not much left to say, it's a very good platform to expose RESTful JSON services. I recommend you take a look at the JSON documentation and also check out ReactiveMongo.
Providing a common REST API should work fine. At the moment I am working with a Play 2.0 server app for browser (Backbone etc) and iOS clients. The browser client is totally separate from the Play app and deployed independently.
I think there is some initial overhead compared to Play template approach but having just one set of controllers to test etc makes life easier.
Couple points to consider:
Client authentication. Preferably you would use the same way for all the clients.
At some point you might want to introduce some specialized REST API for one of the clients in order to save bandwith and number of requests. For example mobile landing screen is a typical candidate.
You need to document your REST APIs more detailed as the web client devs are not sharing the codebase.
So I am a web (Rails) developer, and I would like to create an iPad application for my site. The web application heavily relys on javascript libraries that are built specifically to interact with users in a unique manner.
Now I would like to transform that same interaction to my iPad application. I need a way to reuse my js files since re-coding the libraries will take forever. There are three options that I might follow:
1- Using Rhodes: built on ruby and inspired from rails.
2- PhoneGap: which is basically a web browser inside an app, so I presume that including js files would be possible.
3- xCode: which will take lot of time for me to learn and implement.
My questions are:
1- Can I import my js files in the rhodes project?
2- Which is the best to implement this?
3- Is there any other options that I should be looking at?
Any hints and pointers will be greatly appreciated,
Thanks a lot everybody
As i am not aware of the app you are developing & its design, Two approaches i see here as it is Rails,
Mobile Web
The existing web app shall be customized to mobile web (iPad & most
of the tablet in fact).
Create controllers specific to mobile/tablet. this shall connect to views created specific to mobile/tablet.
Detect the device/platform when HTTP request is posted and re-direct to specific views you have created.
Good thing is your JS is always the same(will need minor modifications thou) and dev time reduced significantly without learning new stuffs.
PhoneGap
You can pull up all the JS you have written and build some html/css integrate everything and build the project inside a phonegap template for iOS and create a on-device app and distribute. but the JS will undergo some changes here too.
But this will no way be different than mobile web and this comes other overheads like CORS and build/release, updates management & app stores etc.
Native APP
As you said, you got to learn iOS development (objC). you can create RESTful services in your rails end and expose them to the iOS app.
Rhodes i am not very sure, its little tricky and it depends on your existing web app too. try it before deploying.
I have been learning Ruby & more specifically the rails framework the past few months and am now preparing to dive into Javascript. I know that any good/modern rails app will include javascript within its code. I also know that Javascript/Jquery/Coffescript help with adding some interactivity, style and functionality to web apps.
My question is what is the standard set of problems/features that one approaches with JS (or Jquery/Coffescript ect) vs Ruby/Rails?
Use Rails to:
Build Extensible applications with MVC (Model, View, Controller) code.
Manage Data (CRUD - Create, Read, Update, Delete).
Manage Security (Access) and Authentication (Identity).
Manage State over time.
Apply REST for standard actions.
Apply a 'middle layer' for validations (the database being the backend validator).
Manage the back end part of AJAX communication and processing.
Build applications in a TDD/BDD Agile fashion with code that is easy to understand.
Build API's for communication.
Provide a full-stack Application Server.
Use Javascript and libraries like jQuery for:
Improved user interaction - Sliders, highlights, glows, color changes, etc.
Improved user feedback - the 'front line' for immediate feedback for validations.
Improved page load speed - less page loads and fewer user experience interrupts.
Improved User experience with effects. - Transitions, Fades, etc.
Presenting and Managing interactive contents e.g. maps, video, sounds.
Tasks that are specific to managing the DOM - HTML, CSS and browser events.
The front end part of communication via AJAX.
Making things look & work similarly in different browsers & browser versions.
Pre-built tools for sliders, image fades, forms, layouts, tool tips, etc.
Pre-built mini-apps, ready to apply to any data. Isotope is one amazing example!
Some tasks you would do with javascript:
update parts of a web page without the user having to reload the whole page.
3rd party sources eg - I had google map on a site and used almost all javascript for it.
pop-ups, user interaction
display videos, interactive images.
Some tasks you would do with ruby/rails:
all your server side stuff like get data from your models.
make sense of any data your client sends to your application.
process your data before sending it to the browser.
Javascript is client side and can manipulate the page after it has loaded. Its more about interaction with the page while rails is the backend of a app. Javascript is present in most web sites, ruby/rails or not.