Showing posts with label HTML5. Show all posts
Showing posts with label HTML5. Show all posts

January 21, 2014

Using custom binding to manage large datasets with the Kendo Grid

The KendoUI grid comes with robust client-side functionality, and Ajax-capabilities - sorting, filtering, paging is all just built in. With the Razor wrapper, the .Pageable(), .Sortable(), and .Filterable() extension methods take care of it all. If the data you’re displaying is minimal or even a few thousand rows, this is probably the route to go – just set the grid's dataSource to Ajax, create a read action on your controller, and you’ve got a pretty robust grid.

But once you get into dealing with “large” datasets, you may want to consider implementing custom binding to get data in front of the user without the wait. When I say “large”, I mean data that takes more than a few seconds to display, or data that is likely grow quickly to an unmanageable size. In our scenario the size of the dataset could be up to 25 Mb, but even after compressing it to 800k, it was taking several seconds to send the data from the server to the browser and then display the data in the grid. After the painful initial wait though, paging, sorting, filtering was then instantaneous since the data was all client side. But what to do about the initial wait?

That’s where custom binding can help out. By implementing custom binding, you can combine the best of Ajax and Server binding to quickly deliver large datasets to your users. A small drawback is that all the sorting, filtering, paging has to be handled in the controller method. Fortunately Kendo makes this fairly easy by automatically passing collections of criteria on the request object – here’s a quick overview of server code required to manually implement paging, sorting and filtering when implementing custom binding.

Sorting
The sorts collection on the request object contains the fields and directions of all sorts that are currently applied to the grid.

Filtering
This is beautiful – I was expecting to have to write code to handle all possible operators and fields, but Kendo’s ExpressionBuilder class will take the filters collection from the request and convert it to a lambda expression to be applied to your dataset! Way easy.

Paging
Based on the page number and the page size, determine the subset of data to return to the client.

One other thing to remember when implementing custom binding is that Server caching of the dataset is something to keep in mind – especially if the db call takes more than a second or two. With custom binding, we’re calling back to the server on every filter, page, or sort event – so we don’t want to make a db call on top of that every time. This is true even (and especially) if we use Kendo’s Server databinding instead of Ajax databinding. So anyway, if you’re using Kendo’s data grids, the out of the box Ajax binding is a good, easily implementable solution, but if you’re dealing with large amounts of data, you’ll want to look into custom binding.

Full Razor code for grid with custom binding enabled:



Full controller method for grid Read event:

Share |

August 02, 2013

Manipulating Kendo's RangeSlider via JavaScript

After dealing with Kendo's Range Slider control this afternoon, I thought it would be worthwhile to post some sample code for dealing with this control on the client side. Manipulating the RangeSlider on the client side is very simple and straightforward, but there isn't good documentation of this control, which has many properties and methods, so you could wind up spending a lot of time grasping at straws.

Kendo's RangeSlider control:

We're creating this control in an ASP.Net MVC project using Razor syntax:
@(Html.Kendo().RangeSlider()

    .Name("RangeSlider")

    .Max((double)Model.RevenueUpperBound)

    .Min((double)Model.RevenueLowerBound)

    .Values(Model.MinVal, Model.MaxVal)

    .Events(events => events.Change(x => "updateVals")))

But after the page is rendered, we want to programmatically change the start and end points via JavaScript. Looking at the object in FireBug, you can see several promising properties and methods like selectionStart, selectionEnd, bind(), etc... But ultimately, you'll just want to new up a JavaScript array containing the two integer values you want to use as the start and end values.

The example below resets our RangeSlider to a start value of 10 and an end value of 111. (Make sure your start and end values are between the upper and lower boundaries of the control itself).
function resetSlider(){

  //Get a handle on our element's RangeSlider
  var slider = $('#RangeSlider').data('kendoRangeSlider')

  //Feed it an array of two numbers.
  slider.value(new Array(10, 111))

}
That's it... As easy as 3.14.

Share |

November 20, 2012

Hats off to CodeProject, Intel

CodeProject is currently holding a Windows 8 & Ultrabook App Innovation contest and I was fortunate enough to make it to the second round. It's a great contest, as all first round winners, myself included, were winners of a brand spanking new prototype model Ultrabook for development:
4Gb memory, Intel I-7(Ivy Bridge) Processor 2-2.5GHz,
160Gb HD, 5 Touchpoint Screen, Windows 8 OS.


I don't really have any technical points in this post, but I wanted to give some kudos to the folks at CodeProject as well as Intel, since I did have an issue with my screen cracking after a week or two. Since it was a free laptop, and CodeProject barely knows who I am, I was not hopeful about being able to get this issue resolved. And it's an unbranded prototype, so I wasn't really sure what manufacturer would be able to help me. Plus, it's a touch screen, so you can't just replace the glass like other laptops (even though it was still fully functional using mouse and keyboard).

But Chris at CodeProject pointed me to Premier Intel support, which came with the laptop, and they swapped it out for me as soon as I could give them a UPS tracking number. Five days later, I'm up and running on the replacement, and it's the best laptop I've ever owned. Fast, responsive, and boots to a functional Windows 8 login screen within 5 seconds. Thanks, CodeProject!

Share |

August 24, 2012

Deploying HTML5 Metro apps to the Windows Store
...some common gotchas

After going through all the effort to build a Windows 8 Metro app before the OS is released, you'd think the hard part is behind you when development is done - what with the in-progress documentation, empty Google searches, and constantly mutating API. Now it's time to deploy to the Windows Store. How hard could that be?  Based on my own experiences, and insights from other early-bird developers, here's a look at some of the common offenses that will surely take you down the path of rejection:

1). Read the Certification Requirements. Really.
2). No items in the left and right swipe margins. No exceptions.
3). Buttons, in app functionality, credits, go down in the app bar or under Settings, not on screen.
4). Snapview - your app has to be usable when "snapped" to the 320 pixel sidebar section in Windows 8.

There are standard ways to handle the switch to Snapview in Windows 8, but for Metro HTML5/JavaScript apps you also should consider using Responsive Design,  Which I'll talk about next week.

Share |

March 06, 2012

PhoneGap HTML5 Portability II - Chrome Web Store Hosted Apps

Last week I talked about the Chrome Web Store being another good high-traffic outlet for your PhoneGap HTML5 codebase.

One of the first issues I encountered with my Packaged App in this new outlet was with advertising.  The ads displayed just fine, as they do on the main website, except for one thing - for every click, the earnings were always $0.00.  That's not good.  After an exhaustive search, I came across this promising answer, but still, $0.00 every time.

The actual problem was that I was using a Packaged App, which essentially is your entire codebase running locally on the user's machine. It ends up that ads within a Packaged App don't have a "legitimate" source URL, according to AdSense, since it's really just local code on the user's machine.  The Chrome Web Store's alternative to a Packaged app is a Hosted App - which is a link to the URL of your application. 

The Hosted App solution is not only appealing as a valid source to display ads, but from a maintainability standpoint I now have one less place to deploy to.  All I need now for deployment is my manifest file and app icons - the Web Store app just piggybacks on my already-existing website.

Here's a sample manifest file for a hosted app:
{
  "name": "My Cool App",
  "description": "This is a test of the Chrome Web Store",
  "version": "1.0.0.1",
  "app": {
    "urls": [      
      "*://www.yourwebsite.com /mail/",
      "*://www.yourwebsite.com /otherarea/"
    ],
      "launch": {
      "web_url": "http://www.yourwebsite.com/"
    }
  },
  "icons": {
    "128": "icon_128.png"
  },
  "permissions": [
    "unlimitedStorage",
    "notifications"
  ]
}
Note that you need to specify a launch URL, as well as any other non-asset URLs you'll be using.  And you will need to verify that you are the owner of this site using Google's Webmaster Tools.

So the quest for a solution to the AdSense problem sent me down the path of investigating Chrome Web Store "Hosted Apps", which not only resolved my advertising issue, but ended up being a better solution in general for my needs.

 If you're debating which type of app would work best for you, here is a good comparison of Hosted vs Packaged apps

Share |

February 27, 2012

HTML5 Portability beyond PhoneGap - The Chrome Web Store

One of the great benefits of doing mobile development using PhoneGap is the portability of the codebase. The same HTML application is easily wrapped and built for all major devices using PhoneGap and/or PhoneGap Build. And since your app is written using HTML, CSS and Javascript, you can make it accessible as a web app as well.

After I had already published a few apps to the Android Market using this technique, I read about the Chrome Web Store. And once I digested their publishing and deployment specs, I noticed that the same PhoneGap codebase could easily be deployed to this outlet as well. I re-deployed the same apps to the Chrome Web Store a few months ago, and my experience was so positive, I wanted to share a quick overview of how to deploy to this store, and some things you'll want to think about:

The deployment is simple for Chrome Web Store Packaged Apps - basically you create a .zip file of your HTML app, along with a simple .manifest file, the app icons, and preview images. Here's a sample manifest that launches splash.html at the root of your app:

{
  "name": "My Cool App",
  "description": "This is a test of the Chrome Web Store",
  "version": "1",
  "app": {
    "launch": {
      "local_path": "splash.html"
    }
  },
  "icons": {
    "16": "icon_16.png",
    "128": "icon_128.png"
  }
}

(Full documentation)

The preview images are not required, but you'll never get very high in the rankings without them... and of course the image sizes don't match the Android Market sizings, so you'll need to create new ones. And they will not accept them until the images meet their aesthetic criteria - I had two go-arounds with them because of font sizing.

...but the pleasant surprise was the traffic:

The identical app in the Android Market after 6 months or so has about 2400 downloads, and is approaching 1000 active installs.

In the Chrome Web Store, there are 3500+ users in less than two months, and 250+ users daily, 14,000+ total. Rarely is there inactivity when using Google Analytics' real-time tools.

The manifest sample I showed was for a Chrome Web Store "Packaged App", but for my needs I found that a "Hosted App" was the better way to go - and even easier. My post next week will highlight the advantages of using a Hosted App, plus some tips on using advertising.

Share |