Last time I wrote about ExtJS I was highlighting how our ExtJS theme helped make our grids engaging, intuitive and useful. This time I’m going to pick out an element of that article and show you how you can create your own “flag column”. This is a little “flair” that sits top right of a column to denote some attribute you can chose. In the last article we were using it to show records that had been marked as “favourites” or been “flagged” for review:
Many people who see the platform I’m helping create at Engage Software have commented positively on how different it looks to all the other software they have to use in their daily jobs. I therefore thought it would be nice to occasionally highlight certain areas of the platform that are achieved using ExtJS to show off what can be done with the right mix of components and a killer theme. Our ExtJS theme was conceived way before Neptune ever existed and has continued to evolve and improve.
In this article we’re going to take a little look at grids. More specifically we’re looking just at the rows in those grids – as that’s where most of the action happens! For now we’ll take a very high level view and in future articles I’ll reveal a little about how you can get some similar results.
Last time we looked at how we can use ExtJS 4.x’s MVC architecture to gain all the benefits of clean and well organises code base without having to use a full “single page app” viewport style methodology.
As you may remember, this can come in handy in your web application if you’re not using the ExtJS framework exclusively or if you’re just opting for a more traditional build with ExtJS providing supporting components to enhance your HTML.
This time we’re going to take a very quick look at one of the problems you may encounter when you have a set up like this; how to call an ExtJS controller method from not only another controller but even from outside the ExtJS namespace entirely.
The Dalvik Runtime in Android will shortly be no more. Commits to the master branch in the last 24 hours show that Dalvik runtime has been disabled and ART runtime instated as the default Android runtime.
No idea what I’m talking about? Under the hood, Android use a runtime library to launch apps (amongst other things). Up to now, Dalvik runtime was used and it’s main party trick was the ability to compile required files on launching an app. This reduced app install time. While this was a very clever solution in the early Android days when devices were slow and had minimal storage, things have moved on. ART runtime does it’s compiling up front on install so everything is ready to go the instant the user launches an app. As there’s less work being done at launch time, ART runtime also has benefits for reducing power consumption which leads to longer battery life. You’ve been able to enable ART runtime for a while provided you could accept that some apps wouldn’t be compatible with it in it’s beta but now it seems like it will shortly be the default.
Link : Android Authority
Why would you want to do this? Well, if you’re working on a project that’s not 100% ExtJS from top to bottom, it’s likely you’re using ExtJS along side other frameworks and cherry picking the best features as you need them. For example, at my current job, we use ExtJS for grids, forms, some data bound components we’ve built out ourselves and of course the accompanying stores that stick it all together but we don’t use ExtJS to provide a “single page app” in what may be considered the usual ExtJS MVC approach when using 4.x+.
So I decided to just give it a go and see what happened. After all, worse case scenario is I lose a little time working on a mini experiment that goes nowhere but teaches me at least something.