Dynamically Generating Download Files

Download Now Img

It may come as no surprise to many of you, that I love Dart. With this love, I’ve made a significant change in the way I handle some of the tasks I get on a day-to-day basis. One of the tasks which would inevitably come up is the take some kind of data or input, handle and manipulate it in some way (internally they like to call it massaging the data, but its rarely that relaxing) and create an output file (usually text).

In the past, normally I would have accomplished this by writing a little Ruby script, or even a Perl script. This often presented a few problems however. First would be that if I wrote the script on my Linux PC, then I’m the one who had to constantly be emailed the data, or generate it myself. Then e-mail off the results. It also meant that if I wasn’t in the office, it wasn’t done. So an option was to my script on a server, then any of the server admins could run the script (once I documented where it was, how to run it, etc). But it still meant that they would have to go through the same process I would need to.

Continue reading

Posted in Dart | Tagged , , , | Leave a comment

Going POSTal

Going postal!

So it seems, that people like their client-side applications to be able to talk to their servers. Strange what people like to do these days.

As it so happens, there are a few ways to accomplish this in Dart. Each has some pros and cons associated with it, and which one you want to use will really depend on how you’re displaying and collecting information.

Continue reading

Posted in Dart | Tagged , | Leave a comment

SwiftKey Keyboard

image

So after using the Fleksy trial and having somewhat less than success in using it, I decided to try another keyboard. This time I went with the SwiftKey keyboard.

I had used the trial before in the past, but it has been some time since I last used it. Very quickly I found my experience to be much different than my previous one with Fleksy.

Continue reading

Posted in Reviews | Tagged , | Leave a comment

Fleksy keyboard

image

Fleksy keyboard tutorial.

I decided to download the Fleksy Android keyboard and give it a try. In fact I’m using it right now to type this post (barely).

Upon installation, Fleksy brings up prompts to enable the keyboard and set it as the input method. It then immediately goes into the tutorial. My initial impressions were favorable until it came to two finger swipe to get to the mini keyboard and the invisible keyboard. For some reason the two finger swipe on my galaxy note is extremely hard to achieve.

Continue reading

Posted in Reviews | Tagged , | Leave a comment

Everything old is new again

I was very recently asked to apply some updates to a project that I had last touched back in June 29th, 2012 (the project’s original start was May 7th of 2012). It has been running happily ever since. But as all things, there was a request to add a new feature to satisfy customers.

However many things have changed in Dart since that script was first deployed. Significant library and language changes. Looking at the source I immediately realised that I would need to rewrite the application from scratch based on the old source code rather than simply trying to update the source directly. Since the script was running fine in the past there had never been a need to continually apply updates as they occurred in the language or libraries. I just left it run.

Continue reading

Posted in Dart | Tagged | Leave a comment

HTML5 Canvas, 2nd Edition and Dart

html5 canvas with dartSome time ago I picked up HTML5 Canvas, 2nd Edition by Steve Fulton and Jeff Fulton, from O’Reilly. I wanted to learn some Canvas tricks for myself and just get a feel for it (plus I love learning new things!). O’Reilly has since gone ahead and made this book available for free online. Check out HTML5 Canvas. The online version also includes interactive components.

But I’m very much into Dart and all the samples were, understandably, written in JavaScript. So as a personal project I began writing the samples in Dart. As I progressed, I thought that these samples would be a great way to help introduce Dart developers to the HTML5 Canvas as well. But being a shady area of reuse I wasn’t sure on where exactly I would stand on O’Reilly’s fair use policy. So I reached out to O’Reilly directly to see how they felt about my making the sources generally available. As it turns out they were happy to grant me permission to share my Dart port of the samples freely!

Continue reading

Posted in Dart | Tagged , | Leave a comment

New Dart (and Polymer) Update (0.8.5.1_r28990)

editor update notification
Woo Hoo! A new update for the integrated build! I’ve been waiting for this one to land (normally they occur weekly but this was about 2 weeks after the last one). I won’t detail all the changes in this update, that is done much better in the official announcement. But I will mention that this change does require some updates to sources I’ve released.
Continue reading

Posted in Dart | Tagged , | 1 Comment

Polymer and Route

I’ve seen a number of different requests for examples of how to use the route package with Polymer. As it so happens, I also needed this functionality for one of my own projects. After getting it working for my use case, I decided to write a little mini sample.

For the impatient of you, you can go right to the source.

Continue reading

Posted in Dart | Tagged , | 1 Comment

Polymer Plunge: Diving In

Not long after completing my previous post, Polymer Plunge, I started running into a few more things to note regarding the web_ui to Polymer transition. Rather than editing the previous post, I decided to try and collect a few more and create a follow up post. And here we are.

First I want to note that the Dart site has already been updated with changes for the latest and greatest version of Polymer. From the index page, to the first 5 tutorials to the Polymer specific page. If you haven’t already, I highly recommend that you check out the Polymer Dart page, and as well the dedicated page Upgrading to Polymer.dart from Web UI (possibly featuring a few tips from my last post).

Without further adieu, here’s a few more caveats to be mindful of when working with Polymer. (Note: not all are specifically related to web_ui to Polymer porting, but are related to Polymer itself).

Conditional and Iteration Templates require PolymerExpressions
Firstly, if it’s been a while since you worked with web_ui, recall that we now have to use if="..." and not instantiate. Similarly we now use repeat="..." and not iterate="...". But these aren’t new changes and did come into play just prior to the Polymer dart port.
Of note however, is that with web_ui we could put our boolean tests or iterate statements just in the quotes. Now we must ensure that we use the moustache braces as well to make them Polymer Expressions. For example: <template if="{{ someBool }}">...<template>.
Can use noscript in Polymer Elements
When the Dart port of Polymer first showed up, it was required that every custom element has a corresponding dart class registered to it (usually using the @CustomTag() annotation). However that is no longer required, and if you have a very simple element, you can easily add the noscript attribute in your Polymer Element declaration. See Seth Ladd’s sample: simple_custom_element_without_script.
Important Note: If you plan to have a polymer element without a script, but forget to put in the noscript attribute; OR if you have a polymer element but forget to include the script in your polymer element (ie: forget to put in the <script type="application/dart" src=".."></script>), then your element will not display on the page at all. It won’t just be non-functional, it will not be there at all. I’ve been bitten by that one a couple of times.
Place your Imports properly
If your component uses another custom component and you need to import it with: <link rel="import" href="...">. It’s important to make sure that you place the import inside of your polymer-element tags, but outside of your template tags. Otherwise your imported resource won’t work. In my case, it just didn’t display anything.
Don’t use onPropertyChange for ObservableLists
I mentioned how you can use onPropertyChange to setup observable getters. However if you want to bind a getter to an ObservableList, then we need to listen for changes in the list itself. Similar to:

var list = toObservable(myList)
..changes.listen((_) => notifyProperty(this, #myGetter));

Note the cascade so we still return our ObservableList and not a StreamSubscription.

ObservableList.sublist() does not return an ObservableList
This is a little bug that I ran into that I thought I would mention as well. Per Issue 13965: An ObservableList.sublist returns a standard List, not an ObservableList as one might expect. Simple solution if you still want an ObservableList is to wrap the call in toObservable. toObservable(observList.sublist(0, 4));.
DocumentFragment.queryAll() does not return an ElementList
A recent update to the dart:html library made a change so that instead of a List<Element>‘s being returned from queryAll(), an ElementList object was returned instead, which would provide direct access to variables such as classes which enables us to easily access the classes of all returned elements without manually iterating through each. However for some reason DocumentFragment, and thus ShadowRoot, did not get the new return type for their queryAll() methods. As such if you try to use the classes property it will work, but you will get warnings in the editor. It’s my suspicion that their code was updated but the method signature was not. See Issue 14015.
No Package Layout Conventions
As per a question I posted on Stack Overflow, and as well a corresponding issue in the tracker. There are currently no package layout conventions for Polymer projects. Due to Issue 12867 we are unable to use package: URL schemes in HTML Imports. As such making relative file look-ups awkward at best and failing at worst. My thought thus far has been to simply create a web/src/ directory for my polymer implementation files and reference things from there. But I’d love to hear your thoughts on the subject!

[Edit: Oct 23-2013]A few additional changes to Polymer since this post should be noted. See A new Dart and Polymer Update[/edit]

Posted in Dart | Tagged | 1 Comment

Polymer Plunge

Well it’s about time that I took the┬áPolymer Plunge. I have a project in the office that is constantly growing, frequently getting new feature or component requests. This was totally anticipated from the beginning however. As such from the get-go I decided to go with Web Components and web_ui to build the application. It made each component much more modular and easy to assemble. I’ll get more into why web_ui / dart in a different post.

But the days of web_ui are waning. Polymer is the new shining light and as its feature set starts to match web_ui the time has come for me to start migrating over to Polymer.dart. But where to start? The documentation for Polymer is still pretty sparse, and the quick pace that Polymer is evolving, the few existing blog posts and articles are becoming out-dated quickly. +Seth Ladd has started a (somewhat redundantly named) GitHub Repo: dart-polymer-dart-examples which is essentially the current de facto repository of simple Polymer examples. So I’ll start there. [Edit: Recently the documentation situation has improved significantly and a great platform for getting documentation is the dartlang.org’s Polymer.dart page. Also see the Polymer Intro Tutorial.]

First stop is the README file, as all of his notes on how to use Polymer and various quirks are stored in there. I’ll note some other issues I ran into porting over my web_ui application below. The README is fairly up-to-date and contains many of the latest and greatest changes that have occurred with the Dart Polymer port. After reading that through, be sure to go through many of the samples found in that repository’s web directory. There is no real order set to them, but it’s great for a quick and dirty cookbook type usage. Find the example you want to learn about and look at that code. One caveat I will mention is that if you’re looking for a CustomEvent example, look at the todo_element sample.

Additionally, I spent a fair bit of time looking at the tests for Polymer from the package’s repository to get a good feel for how things are expected to behave.

Now for some of the issues I ran into during my porting process:

Use <polymer-element> and not <element>
First and foremost I’ll get this simple one out of the way. When declaring a custom element in Polymer, use the <polymer-element> tag to define your element, not the old <element> tags.
dart:json is depreciated
dart:json is going away. I needed to take a little time to convert everything over to use dart:convert. Fortunately it involved very little changes, as I always prefixed my dart:json import anyways. Code changed from Json.stringify(...) over to be JSON.encode(...) and from Json.parse(...) to be JSON.decode(...).
Can’t just call query()
Because web_ui was never really integrated with the ShadowDom, it was possible to just call query() within an element’s class and you could get the nodes from within that element. Now if you want to properly access those components you have to call shadowRoot.query(). shadowRoot will return the ShadowDom for this element, and is the same as calling getShadowRoot('my-tag'). You will sometimes see the latter in sample code as early on there were some issues with shadowRoot returning null when it shouldn’t be. These have since been resolved.
ObservableMixin is already included
Sticking with some legacy Polymer stuff, many Polymer samples will show that you need to define the element’s class as class MyElement extends PolymerElement with ObservableMixin. Fortunately, because it was such a common situation, ObservableMixin is automatically included for us now. We no longer need to add the with ObservableMixin portion every time.
@CustomTag() Annotation replaces constructor attribute
In web_ui if we had a class with the UpperCamelCase name of our custom element, it would automatically perform the association of element to class for us. If we wanted to specify a different class to use for the custom element, we could pass the constructor attribute specifying what class to use for the element’s model. That functionality doesn’t exist with Polymer, and instead we must use the @CustomTag() annotation and pass in a string which matches the value passed to the name attribute of our Polymer Element. In the long run this makes it much easier to choose our associated classes and identify them in the code without the need to flip back and forth to the HTML file if we decide on a classname change later.
No dash-to-camelCase Mapping
One feature of web_ui that I admit I miss is the automatic mapping of dashed attribute-names to camelCase attributeNames. For instance if I had my-value in web_ui it would automatically map it to myValue in the dart code. That functionality has been removed to keep similar behaviour with the JavaScript version of Polymer. The current recommended method is to use camelCase or lowercase attribute names in the HTML and camelCase in the dart code (HTML is case insensitive so Polymer is maintaining that).
Make your entire app a tag
In Polymer the suggested style is to make the entire app a tag. Essentially your index page would look something like: ...<body><my-app></my-app></body>. In part this is because in Polymer, everything is a tag. However this is actually important as well because unlike web_ui, you cannot bind variables (single or two-way) which are not within template tags. Additionally, you can’t bind global variables, and rather bind variables from the associate model directly.
Bind to value= and not with bind-value
In web_ui if we wanted to do two-way binding, we would use bind-value or maybe bind-value-as-number or something like that. Fortunately that’s been simplified in Polymer. Now we bind directly as you would do for one-way binding, but we pass it as the value= for the input element. That is now we would write: <input type="text" value="{{myValue}}"> instead of using <input type="text" bind-value="myValue">. Note that the addition of the moustache braces {{ }}} is required.
Need to manually bind observable getters
It used to be very simple to implement observable getters in web_ui. As long as you added the @observable annotation to the getter, and as long as one of the backing properties it used was observable, then you had an easy observable getter. In Polymer it’s a bit more involved. In order to setup an observable getter we need to setup an onPropertyChange binding for our backing observable, and then from the callback that takes, we need to call notifyProperty on the getter. (Note: on the plus side, now that we have support for Symbol literals, with the # sign, this becomes much shorter) onPropertyChange(this, #backingObservable, () => notifyProperty(this, #obserableGetter)); where #backObserable is the name of the observable that’s used, and #observableGetter is the name of the getter that we want to be observable.
Apparently, I’m just learning, if you have a variable named foo and setup a method named fooChanged(var oldValue) (or accepts whatever type of foo is) then it will automatically create the onPropertyChange stuff for you and instead just execute whatever is in your method. So my above code could be: backObservableChange(var oldValue) => notifyProperty(this, #observableGetter); That’ll help keep things even that much cleaner for you. And no worries about where to put the property bindings.
Public variables are not automatically attributes
In web_ui anytime I wanted to make an attribute on the Custom Element’s HTML tag, I just had to make sure the value was a public property in the corresponding class. Polymer is a little more secretive. Initially polymer required an attributes tag to manually specify which properties were to be settable attributes from the tag. Unfortunately this made for a lot of back and forth while changing or adding variables, putting it in the attributes tag and then in the corresponding dart class. However that was all changed with addition of the @published annotation. Now any variable that is flagged with the @published annotation automatically becomes observable and it is accessible as an attribute on your custom element’s tag.
Can’t pass arguments to event callbacks
A common pattern for me in web_ui was to pass arguments to my callbacks, such as: .. on-click="handleClick($event)" or sometimes I’d pass a string as the argument. All of that is no more though. With event callbacks in polymer, you cannot provide a full method to call, rather you only provide the name of the method. That method is then called automatically with 3 arguments. So your event binding still looks pretty similar, but you’re dropping the parens .. on-click="handleClick". You’re method should then have a signature like this: void handleClick(Event e, var details, Node node) {.... We automagically receive the Event and even the node that triggered the event.

Binding to disabled attribute
Another surprise I ran into with binding to attributes, was with the disabled property. With web_ui I could bind a boolean value to disabled with something like: .. disabled="{{isDisabled}}". However if I do that in Polymer, the element is disabled regardless of if isDisabled is true or not. Instead the solution was to use a type of conditional assignment I had not realized existed: .. disabled?="{{isDisabled}}". Now when isDisabled is false, then the element is active and working.

I’m still in the process of migrating my code-base over to Polymer. However in most cases I’ve found it to be an almost direct copy/paste process. There have been a few changes such as adding the @published annotation, or a few other minor changes as I move from a callback system to a proper custom events system. Most of the changes I’ve needed to make were in the HTML declarative syntax for the Polymer Elements. Most of my dart classes remained virtually the same.

In general, Polymer has made creating and working with HTML fun again. To so simply declare my own elements and reuse them again and again, and to consistently achieve the same results… This is what I’ve been looking and waiting for since I was 14!

See my follow up post: Polymer Plunge: Diving In for a few more caveats of note.

Posted in Dart | Tagged | 1 Comment