Walkthrough: Creating a basic Chrome Extension

Here's my walkthrough on creating a Chrome Extension from the PolyglotDeveloper blog:

Visual Studio TACO - Cordova WebView containing jQuery

If you're using Visual Studio Tools for Apache Cordova (TACO), you may notice a problem if you want to display an external webpage using the Cordova WebView, if the external page uses jQuery. Once you build and start debugging your app, as soon as you try to display the external page, an exception will be thrown in the jquery.js file used by the external page.

Before we look at what the problem is, here's a quick review of displaying external web pages in a Cordova app:

• Whitelist the page/domain in config.xml in the Domain Access section under the Common tab

• In JavaScript, call window.open(whitelistedUrl)

The good news about this problem, is it's not really a problem - except when you're debugging. After failing every time I tried testing opening the new window, I swapped in the non-minified jquery file (in the external page) to take a look at where we were failing. It ends up in the jquery file itself, it does a try-catch that should throw an error for all non-gecko browsers, then swallows the error:

try {
 matches.call( div, "[test!='']:sizzle" );
 rbuggyMatches.push( "!=", pseudos );
} catch ( e ) {}

...But it ends up that even though this error is swallowed, The Visual Studio TACO debugger stops the processing at the point where the error is thrown, and even if you continue processing, it usually won't display the page. Even though this code is executed on any page on the www containing jquery, when those pages are pulled into a Cordova WebView using Visual Studio TACO debugging, processing stops and the app appears to error out for no reason.

But if you run your app in Release Mode, you'll see that the page gets pulled into the Cordova WebView just fine, now that the debugger doesn't halt on the swallowed error. So the answer is that you can't debug past the point where you pull an external page into a Cordova WebView. You'll need to test that part in release mode, and if there are any problems, you can debug the page using Chrome Dev Tools on the site itself.

If this is unacceptable, another alternative would be to look into using the Cordova InAppBrowser plugin, which has no problem with external jQuery files, but the downside is that it does pop up a new browser window.

First Take on Visual Studio Tools for Apache Cordova (TACO)

I installed the Visual Studio Tools for Apache Cordova last week to see how feasible it would be to use with an existing PhoneGap Android codebase.

I still haven't gotten to the point of publishing to Google Play yet (next post), but I thought I'd share a few of the pain points/errors I've encountered during setup and steps to resolve them:

(Note that these are specific to Android)

1) "Could not create the Java Virtual Machine" error

This is a memory issue with the JVM. The recommendation is to set your _JAVA_OPTIONS TO -Xmx512M
Full instructions

2) Error DEP10201 (No device found)

The Android emulator is a slow klunky experience. When you graduate to using your personal device to debug, you'll need to set up USB debugging. First, make sure USB debugging is enabled on your phone. On some Android phones, you first have to go to Apps..Settings..About Phone, then tap 7 times on the Build Number to enable Developer Options.
Full instructions on how to enable USB debugging on an Android phone

After enabling USB debugging on your device you will then need to install a USB driver for debugging.

So now that we're set up to test and debug on our phone, we'll look at some of the TACO nuances and the deployment process next week - hopefully with an app successfully deployed to Google Play.

JavaScript Variable Hoisting

One of the little known nuances of JavaScript, is that the interpreter organizes functions and variables per scope by declaring them at the beginning of the scoping container, regardless of their order in the written script. Here's an example:
function showVariableValues() { console.log("x=" + x);//x is undefined var x = 1; console.log("x=" + x);//x is 1 console.log("y=" + y);//error } showVariableValues();
Displays:

x=undefined
x=1
Uncaught ReferenceError: y is not defined

In the above example, we're logging the value of variables x and y before they are declared, however, x has a value of

undefined

whereas y throws an error. So what's the difference? Neither variable has been declared when we are accessing them. Why do we only get an error when referencing y?

The reason is that the JavaScript interpreter reorganizes the declaration of ALL varibles within a scope to the top of the scope - in our case our scope is the function

showVariableValues()

. So in reality, our above code will be reorganized as shown below:
function showVariableValues() { var x;//declaration was hoisted by JS console.log("x=" + x);//x is undefined x = 1;//initialization stays in same spot console.log("x=" + x);//x is 1 console.log("y=" + y);//error } showVariableValues();
Notice that the declaration of var x has been "hoisted" to the top of the scope, but only the declaration. The initialization of the variable remains in its original spot. Once this variable was declared, JavaScript set its value to

undefined

- the JavaScript default. So that's why when we write the value of x, it's value is

undefined

, whereas y just throws an error because it has not been declared.

So the lesson is: always declare your variables at the beginning of their scope - if you don't, JavaScript will reorganize your code for you. If you think about it, you could probably come up with scenarios with much more confusing results than this simple example.

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. foreach (SortDescriptor sortDescriptor in request.sorts) { if (sortDescriptor.SortDirection == ListSortDirection.Ascending) { switch (sortDescriptor.Member) { case "Name": summaries = summaries.OrderBy(s => s.Name); break; case "Type": summaries = summaries.OrderBy(order => order.Type); break; //Ad Nauseum... } } else { switch (sortDescriptor.Member) { case "Name": summaries = summaries.OrderByDescending(s => s.Name); break; case "Type": summaries = summaries.OrderByDescending(order => order.Type); break; //Ad Nauseum – all sortable columns } } }

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. var exp = ExpressionBuilder.Expression<CampaignModel>(request.Filters); mappedSummaries = mappedSummaries.AsQueryable().Where(exp);

Paging

Based on the page number and the page size, determine the subset of data to return to the client. if (request.Page > 0) mappedSummaries = mappedSummaries.Skip((request.Page - 1) * request.PageSize); } mappedSummaries = mappedSummaries.Take(request.PageSize); var result = new DataSourceResult() { Data = mappedSummaries, Total = total };

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:

@(Html.Kendo().Grid<CampaignAdminListModel>() .Name("Grid") .BindTo(Model) .EnableCustomBinding(true) .DataSource(ds => ds .Ajax() .PageSize(12) .Read(read => read.Action("Index", "CampaignAdmin"))) .Columns(columns => { columns.Bound(p => p.CampaignName); columns.Bound(p => p.LeadSourceType).Width(150); columns.Bound(p => p.LeadSourceTypeName).Width(200); columns.Bound(p => p.Source).Width(200); columns.Bound(p => p.Channel).Width(150); columns.Bound(p => p.SubChannel).Width(150); columns.Bound(p => p.Exclude).Width(70); columns.Bound(p => p.Status).Width(70); columns.Bound(p => p.ProductCategory).Width(150); columns.Bound(p => p.QueryStringParameters).Width(150); columns.Bound(p => p.CampaignId).Width(100); columns.Bound(p => p.LeadSourceId).Width(100); }) .Pageable() .Sortable() .Filterable() .ColumnMenu() .Scrollable(scrolling => scrolling.Height(500)) )

Full controller method for grid Read event:
[HttpPost] //Required by KendoGrid.DataSource.Read event public ActionResult Index([DataSourceRequest] DataSourceRequest request) { var mappedSummaries = GetMappedCampaignAdminList(_userProfile.AccountId); //Apply Sorting mappedSummaries = SortMappedSummaries(mappedSummaries, request.Sorts); //Apply Filters var expression = ExpressionBuilder.Expression<CampaignAdminListModel>(request.Filters); mappedSummaries = mappedSummaries.AsQueryable().Where(expression); var total = mappedSummaries.Count(); //Apply paging if (request.Page > 0) { mappedSummaries = mappedSummaries.Skip((request.Page - 1) * request.PageSize); } mappedSummaries = mappedSummaries.Take(request.PageSize); var result = new DataSourceResult() { Data = mappedSummaries, Total = total }; var jsonResult = Json(result, JsonRequestBehavior.AllowGet); jsonResult.MaxJsonLength = int.MaxValue; return jsonResult; }

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.

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!

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.