Back in August when Google acquired Instantiations, the speculation was that Google would possibly provide Instantiations GWT Designer as a free tool for all to use. Today, Google has made my day, because not only is GWT Designer relaunched as a free tool, but so are their three other core products. This is a huge day for Java developers, particularly those focussed on the desktop, as these tools are among the best of breed: as commercial tools they were worth the cost as they boosted productivity, but as free tools they are now an indispensible part of your software development workflow. The importance of this announcement can not be overstated. Firstly, Java developers now have a production quality UI builder for fast prototyping of their desktop application using either Swing, SWT or RCP, as well as GWT and XWT. I've used WindowBuilder in the past, and it's a great way to get started quickly. The code generated is very usable. There has been no convincing free solution available for this range of UI frameworks in the past: today that all changes. High quality static analysis of code is important for Java developers. Before you walk into a code review, it's always worth taking a scan over your code. Typically developers skip this, or else they use a free static analysis tool (e.g. FindBugs). Working CodePro AnalytiX into your development process, or just your nightly build, will help you identify bugs, and possible security issues, with your codebase earlier. Finally, automated UI testing is one of the most difficult areas to get right. While there are free solutions available, the commercial products have always seemed one step better. WindowTesterPro will allow you to automated tests for your Swing, SWT or RCP applications. It includes record and playback functionality to get you started with an automation test suite quickly. Here's a quick overview of the tools, now relaunched as Google products GWT Designer Powerful Eclipse-based development tools that enable Java developers to quickly create Ajax user interfaces using Google Web Toolkit (GWT) CodePro AnalytiX Comprehensive automated software code quality and security analysis tools to improve software quality, reliability, and maintainability WindowBuilder Pro Java graphical user interface designer for Swing, SWT, GWT, RCP, and XWT UI frameworks WindowTester Pro Test GUI interactions within Java client rich applications for the SWT and Swing UI frameworks Google plans to unify the products into the Google Plugin for Eclipse. You can download any of the tools from the GWT download page. Check out Google's announcement to find out more.
You can use a language, and not care how it works; or you can use a language, learn how and why it works, and then go on to improve it yourself. You can, of course, improve a language without knowing how it works -- just providing feedback is often plenty. But if you really understand a language, including why each of its formal features is structured exactly as it is, then you can contribute as a master, almost as an engineer. So what's the purpose of HTML? Let's say: providing user experience over the web in a browser. Okay, fine: then to become master, learn about the inner workings of the web (which moves you closer to network engineer) or learn about the inner workings of the browser (probably more useful for web developers than network engineering, especially since browser change a lot faster than the architecture of the web itself). So then what's the purpose of HTML5? and how does HTML5 get there? Paul Irish answered these questions in a great 37-minute presentation at W3Conf2011 last month. He explains how browsers work now as opposed to ten years ago, how browsers drove previous standards and how standards drive browsers now. Eacfeature of HTML5 is given a history (which often explains some otherwise unintelligible bizarrities) and a reason (often hard to summarize, because the reasons are often quite varied, and sometimes deal with e.g. security issues developers don't always worry about). Paul's a smart guy (he's Modernizr's lead developer!), and an excellent speaker. Definitely worth the time. Watch the video below.
Column propagation can help address the typical performance issues associated with hierarchical table structures, which are inherently slow. Let’s learn how!
Last week I wrote a brief introduction to Kristof Degrave's ongoing, multi-stage IndexedDB tutorial. Judging by the number of reads, it looks like quite a few of you are interested in learning more about HTML5's IndexedDB. I'm following Kristof's tutorial anyway, so I might as well keep posting about it here. Today Kristof has posted his next IndexedDB tutorial -- Transactions -- and here's where IndexedDB begins to get exciting, where the work of creation and definition begins to pay off. We're preparing for actual data retrieval and manipulation, so we'll be creating a READ_WRITE transaction. At this point, if you're trying to understand IndexedDB formally as well as use it pragmatically, you might want to get more comfortable with W3C's conceptual treatment of transactions along with the formal object description, and maybe the IDBTransaction interface too. (For me, it especially helps to understand emerging tech like HTML5 a little more abstractly, just in case the standard takes a different turn than previously expected.) If you prefer learning by doing, here's how Kristof explains transactions: Today, I’ll handle the transaction subject. As said in previous posts, every request made to the database needs to be done in a transaction. So for every read or write request we need to create a new transaction. There for we need a database connection and 2 argument that we will pass to the transaction method. The post is, like his previous tutorials, quite straightforward -- painlessly showing you how to use what is potentially one of the most powerful features of HTML5. Take a look, create an IndexedDB transaction, and get ready to retrieve and manipulate data.
Well, after hubbub, including some here at DZone, the HTML5 element has returned. Paul Cotton, on behalf of the chairs of the working group, issued a revert request -- and his explanation is interesting: The Chairs have received multiple requests to revert change r6783. This change is related to bug 13240 [1] which was never sent to the HTML WG since it used a possibly incorrect Bugzilla component. Since WG members were NOT notified of the creation of this bug the Chairs have decided that this change should be subject to the Enhanced Change Control rules in the WG Decision Policy [2]: "Therefore during a pre-LC review, or during a Last Call, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug, a WG decision, or an on-list discussion. This applies only to LC-track drafts and does not apply to drafts that may include material for future versions of HTML." We therefore ask for a revert of this change to be completed no later than the end of day on Tuesday 8th of November. If this revert is not complete by that time, we will instruct W3C staff to make this change. In other words: people don't like it, and we never really meant to approve, and we're not really sure how it got through in the first place. Now, the decision policy quoted sounds as though it would not invalidate the change, since the 'bug' was listed (and discussed) since July. I don't know what 'possibly incorrect Bugzilla component' means -- did they actually find something misconfigured in Bugzilla? -- but the vague hedging on 'possibly incorrect' raises my suspicions a bit. The meeting minutes don't help much (though it's neat to glimpse at how these conversations go). After the decision, a proposal to modify the reverted element was posted on the W3C wiki. This might map the near future of , so it's worth checking out for that reason alone -- though also, again, to help understand how HTML5-spec decisions are made. But however it happened, is back. So: did the W3C WG actually bow to popular outcry? or was there really just a bug in their bug-review system? I don't know, but I'm curious. What do you think? Update: Discussion has re-opened in the original bugpost since the revert command came through -- some deductive, some inductive. Results from the blekko web grep mentioned in the last comment might be very interesting...
So as we’vementionedoccasionallyaroundhere, we think that HTML5 app development is something that even real developers (we kid! we kid!) should be keeping their eye on as a likely method of first resort for cross-platform development and non-AppStore distribution; and here (h/t: @Dylan_Beadle) is a LIVE! ONLINE! FREE! course it might be worth at least keeping an eye on in the background every Tuesday the next 10 weeks: HTML5 Mobile Web Development Ready to create mobile web applications with HTML5? In this 10-week online course, you’ll learn how to build mobile apps using several HTML5 features—including the new semantic elements, geolocation, audio and video tags, local storage capacity, web forms, and the canvas 2D drawing surface. During the course, you’ll combine HTML5 elements with JavaScript and CSS3 to create apps for Twitter, movie trailers, and an address book. Discover how to style your apps to respond to a device’s vertical and horizontal orientation, take advantage of global positioning, draw your own controls and create basic animations, make your app available to users offline, and more—in just ten weeks. First one starts in … oh, look at that, half an hour. So unless you’re right on top of our posts, guess you probably missed that. But hey, it’s just an overview; looks like the interesting stuff starts next week, full session descriptions at the above link. Aaaaaand while we’re discussing HTML5 development, this looks like a good place to stash some of the looking worth a followup read links in that space we’ve noted recently about the various frameworks available: 10 Useful Frameworks To Develop HTML-Based Webapps for Touch Devices 18 Mobile Frameworks and Development Tools for Creating iPhone Apps Introducing Sencha Touch: HTML5 Framework for Mobile Getting Started With Appcelerator Impressive Growth for Appcelerator (note native app showcase) In-Depth Corona SDK Review [UPDATE: Yo Yo, develop killer cross platform mobile Web apps with Jo!] And here’s a jumble of other vaguely HTML related tips and tricks for design and device support: Configuring an iPhone Web App With Meta Tags CSS for iPhone 4 (Retina display) How to make your web content look stunning on the iPhone 4’s new Retina display Targeting the iPhone 4 Retina Display with CSS3 Media Queries HOWTO: CSS for the iPad Tutorials: Swipe Reading, Orientation Support, And Image Slideshows In iPad Web Apps Safari Web Content Guide: Optimizing for Safari on iPhone 21 Ridiculously Impressive HTML5 Canvas Experiments HOW TO: Get Started with HTML5 Boilerplate HTML5 Mini Template [ UPDATES: 12 Best HTML5 Website Templates For Free Download 12 Great Tips for iPhone Web Development ] And mix up HTML5 and native development: UIWebViews and CSS3 Fonts And you’ll probably want some fonts for that; check out recent news on that front, Helvetica Joins the Web Font Revolution And just in case that isn’t enough for you to read, check out 20 Useful Free PDF ebooks for Designers and Bloggers Some pretty interesting stuff in that list!
So affirms Sencha, in the latest installment of their HTML5 developer scorecards series. Four-sentence version: After putting the Galaxy Nexus through our test wringer, we can say that Ice Cream Sandwich is a major step for the Android browser. However, it still falls short of iOS 5. It’s a solid browser for normal page browsing and it adds major new features that support most of the HTML5 spec. It also has taken a big step forward in correctness of rendering, which is a welcome change for people who want to push their mobile browsers to the limit. The most exciting new feature support, in Sencha's opinion: tons of CSS3, including the more nativey-slick, like animations, refletions, transformations, and transitions. Some specific missing features: Web Workers Web Sockets WebGL datetime and range input types overflow-scrolling Shared Workers The device Sencha used was a Samsung Galaxy Nexus, which meant that some performance and zoom issues might tell you as much about the hardware as about the OS. But the biggest rendering improvement: rendering was simply correct. One way Ice Cream Sandwich beat iOS 5? Embedded inline HTML5 video. They actually played inline on the Galaxy Nexus, in Sencha's tests; they didn't on the iPad and iPhone running iOS 5. Here's Sencha's rather glowing closing summary: In summary, the Galaxy Nexus and Ice Cream Sandwich are a major step forward for the Android platform. Feature by feature, HTML5 support has gotten much better, rendering has become more accurate, and performance has gotten much faster. Although still behind the current HTML5 gold standard of iOS5, Android 4.0 is night and day compared to previous versions. That 'night and day' is pretty strong, and definitely great news for HTML5 developers. If you're developing HTML5 apps for mobile, you should probably read the full report, which includes JavaScript performance numbers via SunSpider, Acid3 scores, and detailed results of Sencha's own touch-specific test suite.
