jQuery Mobile & JS Frameworks - jquery-mobile

At my work we have an existing ASP.NET web application and are duplicating some of the pages & functionality to better target our mobile users. We are using the jQuery Mobile framework and ASP.NET Web Forms to do this.
Since this is going to target the mobile web I would like it to be fast & lightweight which means turning off the view state, loading lists on demand (when opened), and I'd like to eliminate post backs (annoying & doesn't work well w/ jQuery Mobile). Of course this means doing a lot more work client side.
One of the pages is a bit complex, it allows the user to log items, however it's layout is fully customizable. Prior to logging the user is able to define what fields they wish to track. Some of these fields are system designated but others are created by the user. They can choose from a checkbox, dropdown list, date box, radio button, text box, or list box. Some fields are also tied to other fields meaning the user can select an item in one drop down list which then reloads another drop down list with the associated data. The user also has the ability to add an unlimited amount of additional fields (drop down lists) while on the actual page used to log their item. Once the page is filled out by the user the selected fields values are saved back to the server in a database table.
I figured this would be a great chance to use a JS Framework like Knockout.js, the dependency tracking would come in great for trying to keep things synced up & reload lists as needed based on selections made in other lists. Even though I am a bit concerned about how it would handle the fact that the form layout is dynamic & can be modified once displayed (anyone know if it can handle this?).
So I started looking around for jQuery Mobile & Knockout.js and apparently there are issues, workarounds, limitations, etc. w/ the two working together and I saw the same thing w/ Backbone.js
Does anyone have any suggestions w/ this? Is it worth the hassle to try and use a JS Framework of some sort w/ jQuery Mobile? Can a JS Framework handle the form I am trying to create w/o me having to jump through hoops? Am I better off looking for some sort of dependency tracking plugin and just using that and if so can you suggest any that will wire up to my model object & other controls on the page & work correctly w/ jQuery Mobile?

Overall, knockout should be a good fit for your requirements. I'm currently using it an MVC3 applicaiton to do similar things to what you are describing.
As for your complex page, this is all doable.
Your highly customizable form. This is one area where knockout really shines. It allows a separation be how data is displayed and the data itself. This can be done with different data-bindings types and you can add your own customized bindings. I actually do this a lot when creating a form and experimenting with what the test control type is.
Dynamic Layout - With Knockout there is no direct connection between the DOM and the data. Knockout's data-bind statements allow you to connect new content to it's data at run time. This currently works well in my current app.
For your requirement about unlimited adds, take a look at the Contacts Editor Demo. It seems to have features to do the unlimited requirements
In general with knockout, once I went to using ajax to handle all my data requirements, things became greatly simplified.
As far as using knockout with jQuery mobile, knockout is now part of the new releases of Asp.Net Mvc4, developer preview. It is my understanding that knockout is key to MVC's design on building single page web offline where the data is stored locally, then dynamically added to the displayed page. Cannot find link right know, but I'll keep looking and post edit later.
Hope this helps out. Also, checkout the links on knockoutjs.net home page. -

Related

rails - mass selection of html table rows with pagination

I want to give user the ability to proceed in a common action for many selected (with checkboxes) items that are displayed in a table with pagination.
I wonder how am I going to keep track of the selected items of a previous table page while user navigates to other table pages via pagination links.
I use kaminari for pagination.
Any ideas?
An approach you could use is a hidden field or just a javascript variable that you update with some javascript whenever the user selects/de-selects an item in the table.
If your page navigation links use AJAX to only update your table and nav links, your page will still contain the hidden field or variable of the selected items. On a table update you will also have to set the selected state on your table items based on what is selected in your hidden field or variable.
Yeah, its not pretty.
You may want to consider some of the client side MV* frameworks for SPA (Single Page Applications) as things can and do get messy pretty quickly with ad-hoc javascript.
The MV* frameworks I am referring to are Backbone, Ember, Angular, Knockout, Batman and so on. Your app essentially becomes a single minified javascript asset, a single minified stylesheet, plus images and client/server is just AJAX/JSON api. These framework provide structure for your client side code and support binding of views into object state and synchronisation to the server.
It is this shift in client side architecture and native mobile apps that has seen more minimalist server side frameworks like Sinatra rise in popularity as frameworks like Rails (and yes I mean Rails 4.0) no longer provides the "rails" or conventions for developing modern web and mobile applications.
Checkout TodoMVC for a comparison of MV* client frameworks and choose one that fits your style and requirements. My pragmatic (and opinionated) choice after a considered look at all the major ones is Backbone.js + Backbone.Marionette + Coffeescript because you simply don't get painted into a corner. No disrespect intended to others.
My advice with MV* frameworks is:
be very careful with opinionated frameworks that use declarative view templates or have limited or no ability to put logic in templates, or don't support nested/sub templates. Without such features, view composition is a challenge and rendering views that vary based on say user role, or plan/subscription or have a hierarchical structure becomes difficult if not impossible. I've considered the declarative template ideology and I like the theory but reality bites.
be careful how much control you have over synchronisation with the server. You often need to "side load" related objects and the last thing you want is the old 1 + N SQL query problem being manifested as a 1 + N JSON query problem!
If you are using any form then you can go for multistep form . you can get the idea from
http://railscasts.com/episodes/217-multistep-forms
But please make sure you need to store the form object in session in this approach so if you have let say 500 fields in your form then there is a change of cookie over flow. please take a look on your application and then decide.

Using a client state model object for a hierarchical MVC web application

I'm building a large hierarchical web application and I need some help deciding on some best practices with leveraging MVC.
The application will have tabs at the top which control a sub page, and a query pane (off to the side).
There will be two templates for query panes, each used by different sub-pages. The sub-pages will be based on the selected tab with settings derived from the query panes.
Clicking on tabs or updating the query pane will update the sub-page section without refreshing the page.
I'm a bit new to MVC and what I don't quite understand is how I can leverage MVC methodologies to help me manage the web application's state (which consists of the selected tab, query options, and other page-specific options).
Currently I'm planning on initially setting up a model which stores the client state parameters (default values, or values obtained from a DB), and using it to load the page, consisting of several partial views. When anything is changed (tab/query/etc), the view will call a corresponding controller, passing back model parameters via post (I'm assuming there's no way to store session-specific client state models on the server-side?).
My question is:
Am I doing it right?
If not, what am I missing; and specifically, is there a way to store these session-specific state models server side so they don't have to be passed back to the server during every single page transaction?
If I understood everything you need Its a SPA (Single Page Application). This will provide a magic user experience, without full page reload, and low data traffic. But, requireds some MVVM framework (AngularJS, KnockoutJs, etc) and a lot of JavaScript coding. But the result is amazing. The guy behind this in MVC is John Papa, take a look in everything on his blog and you will win.
John Papa Blog
Hopes Its Help you

Right way to design a mobile ASP.NET MVC 4 data entry application with HTML5 offline capabilities

I'm creating a PoC of an ASP.NET MVC 4 mobile application (tablets) for field operators that needs to support offline capabilities. It's a relatively simple data entry application with a WebAPI backend that will use a SQL database as persistent storage.
This is the first time I'll be implementing offline support, so I'm a bit unsure of which is the best way to design this. Right now I can think of two ways, and not sure which one is better or more correct.
What I want is that whenever there is internet connectivity, the information is retrieved from the server. If the connection is lost, I want the latest information to be cached/served and available to display to the user.
Based on a few tests that I've made, the way the HTML5 offline support appears to work is that as soon as any of the Views is loaded, the browser will check the manifest and cache the version of each page at that moment of time. If my understanding is correct, that means that if the user adds new entries after the browser downloaded the manifest files, then those records would not show in the offline version.
One way I can think to work around that is to change the manifest version (since I'm generating it dynamically) every time it is served, but i feel that would defeat the purpose..or at least be incredibly inefficient bandwidth-wise.
The only other alternative that I can think of is not using regular MVC (not passing the records/db information as the model property or a ViewBag property) to display the records, but just retrieve the json for the page information needed and save in local storage. Then, generate the view using a template or javascript based on the information in localstorage. That would work either online or offline, wouldn't it?
I'm not sure if I'm approaching this the wrong way. Would building an SPA or a simple HTML/javascript application be more appropiate? Maybe using a JS framework? At this point I have some ability to determine what technology or framework we'd use.
Any guidance is greatly appreciated.
Based on a few tests that I've made, the way the HTML5 offline support appears to work is that as soon as any of the Views is loaded, the browser will check the manifest and cache the version of each page at that moment of time. If my understanding is correct, that means that if the user adds new entries after the browser downloaded the manifest files, then those records would not show in the offline version.
This is why you shouldn't use server side rendering. When the server mixes data with formatting before sending to the browser it means that the browser can't tell the difference between the two. HTML5 and Javascript are perfectly capable of handling templating on their own so why not let them?
Write your MVC application as nothing but a series of controller methods. Do not use "views" per-say. Instead use straight HTML files that use javascript to make AJAX requests to the server for data. Populate the HTML view with the data and you're golden. Then you can cache the HTML files because they're static and you can save the data separately for offline mode.
Adding to the accepted answer, there's a thorough post in this matter titled:
Build an HTML5 Offline Application with Application Cache, Web Storage and ASP.NET MVC.
The guy explains everything using a sample/complete app and do a great job explaining each and every point.
Besides that, if you really want to get the crème de la crème from modern web dev with offline capabilities, I'd suggest you take the 2 parts course by extraordinaire/star developer John Papa. It uses the SPA = Single Page Application UI paradigm.
The course is available at Pluralsight:
Building Apps with Angular and Breeze - Part 1
Building Apps with Angular and Breeze - Part 2
Enjoy as much as I'm enjoying it. Make sure you check this keyword/feature in the course: WIP = Work In Progress.
If you're interested, here's is a repo where I keep the updated course's code:
https://github.com/leniel/SPACodeCamper

Dynamic menu versus hard-coded

I'm working on building a mobile application for a client using jQuery Mobile. The question I have is fairly basic and non-technical:
The application can have three different types of users, all with a different menu layout. Some users will have access to some parts of the system that other users will not.
My question is- should I hardcode the menu system in the index.html file or should I dynamically create it when they log in? I'm assuming that there would be a slight performance gain by hardcoding the menu and then just choosing which #page to display as opposed to requiring an ajax call...but keeping the menu builder on the server side processing keeps us more agile if need to change the menu after deployment.
Deep apologies if this has already been asked. Thanks for your help!
Build your pages dynamically. On jQuery mobile, a lot of stuff will be repeated and if you want to respect the DRY principle and want to create easily maintainable code, do it dynamically.
Also, by doing this on a mobile application you will reduce the loading times : instead of loading 3 pages you'll only load one, wich can be crucial in mobile developpement.
Hard coding is bad if it can be done dynamically do it because it saves over head and produces nicer code that is easier maintainable.
If you want to change the menu in the future you can just edit the source of information instead of going through all your code having tons of messy if and else statements saying if this person is logged in don't show this option but show this one etc.

when to destroy a data-tables in Jquery-Mobile?

I'm using the datatables plugin in a Jquery Mobile project.
I'm using a multipage layout, with several pages containing tables enhanced by the datatables plugin. Since I already have a lot of overhead using Jquery-Mobile, running datatables alongside seems to push my mobile browser's limit.
So my questions:
- Does it make sense to only initialize a datatables table when the Jquery Mobile page is being pulled into view?
- Should I destroy a datatables table when I'm leaving the page for another page and re-initialize when the user goes back to the page?
I guess the question is sort of a longshot, but maybe someone can share some insights or opinion on it nevertheless.
Thanks!
I've used dataTables a lot and i had problems only when the row count got too big. In any cas to your questions
Does it make sense to only initialize a datatables table when the Jquery Mobile page is being pulled into view?
Yes this makes sense to me, no need to waste processing power and memory if the table is not shown
Should I destroy a datatables table when I'm leaving the page for another page and re-initialize when the user goes back to the page?
This is a little more difficult to decide since you have to consider the effort that you put into creating the table. That's a though decision and only testing out both options will lead you to the right decision
Yes, it makes sense to initialize them as the page is pulled into view (maybe the pageload event?) In Chrome, I profiled ~30ms hit when binding data tables to a 3-row table. That will really add up if you have large tables or many of them.
This seems a bit arbitrary. Once the hit has already been taken to create/bind the datatables, I'm not sure that destroying it will clean up anything as no datatable functionality/events will be called once the page is removed from view. In fact you will put an additional (and largely unnecessary) hit on the browser unbinding them.

Resources