senchainc-blog

[senchainc-blog]

Our Favorite iOS 6 Mobile Safari Features

Another WWDC, another major iOS update! Here are three of our new favorite feature from the keynote:

Camera support in Safari -- how cool is that? You can upload from your Camera Roll or take a picture right in to the browser using the Media Capture API. 

Smart App Banners look like an awesome way to make it easier to integrate native and web apps. It probably won't use Web Intents, but it's a cool feature all the same.

CSS Filters! Combine this with Camera support and you have all the ingredients you need to build a mobile web Instagram without any need for a native app.

[senchainc-blog]

HTML5 Developer Scorecard: iOS 5.1 & iPad 3

This week we tested iOS 5.1 and the new iPad for our latest HTML5 Developer Scorecard, and were surprised at the change in JavaScript performance and overall rendering.

Read on to see what you'll need to know if you're relying on an embedded WebView or localStorage for your app.

[senchainc-blog]

I was very surprised when I saw the new screens for this Sencha Touch app, InstaMatch. It has changed a lot since its first iteration. It's free this weekend, and has graphics that fit the new iPad third-gen, so go get it!

Our latest app, InstaMatch – The Instagram Game is now available on the App Store! Download it here. 

[senchainc-blog]

Sencha Touch Charts 2 beta is now available for testing

Version 2.0 beta of our HTML5 charting and drawing library for mobile devices is compatible with our recent GA of Sencha Touch 2, contains improvements in performance, a new TreeMap visualization, and a new animation package.

Please download the beta and provide feedback on our Sencha Forum.

[senchainc-blog]

Our talented tutorial and Sencha Touch guru Drew Neil is back with a 10 minute screencast to explain Layouts in Sencha Touch 2.

If you've never watch one of Drew's screencasts, you're missing out. He has a clear, concise way of explaining and demonstrating the process of developing in Sencha Touch. Watch this video introducing you to layouts and I guarantee you'll come away with a better understanding.

In Sencha Touch, the Component and Container form the basic building blocks for creating an interface. Each container can be assigned a Layout which handles the positioning of its inner items. The layouts work either by neatly arranging components to use the available space, or by showing just one component at a time and providing some way of changing the focus between them.

In this tutorial, we'll see each different layout type in action and see how they can be combined in any manner you can think of.

See more of Drew's screencasts in our Vimeo album: Learn Sencha Touch 2 w/ Drew Neil

[senchainc-blog]

Join the HTML5 revolution with Sencha Touch 2 and build mobile apps for every Android, iOS, and BlackBerry. We're excited to share with you the power of web technology: incredible performance, beautiful themes, and endless possibilities.

[senchainc-blog]

Today we're proud to announce the release of Sencha Touch 2.0. With a huge focus on performance, simplified API, and native packaging on both Mac and Windows, we’re certain it will change the way you think about mobile apps.

[senchainc-blog]

Connect 2.0 is here with new core middleware, miscellaneous improvements, and some new docs.

[senchainc-blog]

This customer spotlight video from Xero includes some great shots of Ext JS and Sencha Touch.

Via Fast Company's Co.Design.

[senchainc-blog]

Create rapid prototypes of your next great web app in Photoshop with the new Sencha Touch GUI PSD from TimeWave Media:

“We’ve created a layered Photoshop PSD file based off of the Sencha Touch Kitchen Sink demo app, as well as their new [Touch Charts] interface features. This file is intended to serve as a reference for designers working on Sencha Touch projects, by providing the basic building blocks for all the new interface options available.”

Download and start comping today!

[senchainc-blog]

IGN's new iPad app built with Sencha Touch debuted on the Apple App Store today.

We’re particularly impressed with the lengths they went styling components for a custom theme, not to mention how responsive the app is in a native package. We highly recommend checking it out on the App Store, it's free!

[senchainc-blog]

Our stance in the CSS vendor prefix debate

Alex Russell wrote a piece about the CSS vendor prefix debate, and our CEO Michael Mullany responded with a piece of his own. You should head over to Alex's blog to read what is now an epic comment thread, but we also felt we should share it here with everyone.

Click through to read about Sencha's stance on this issue, and why we don't see a WebKit-only future.

Originally posted by Michael Mullany at Infrequently.org, February 17, 2012 at 4:21 pm:

Since both sides of this debate make claims to “what developers think/act”, we thought we’d lay out the Sencha opinion on -webkit prefixed effects: why we use them, and why we don’t want other vendors squatting on them. And incidentally, we’re fans of CSS as a technology.

But first a little background.

Here at Sencha, our frameworks haven’t focused on progressive enhancement: in our opinion, it’s not very appropriate for apps. A grid that degrades to a poorly laid out table is not generally useful, not for developers, not for users. Our community’s users expect their web apps to look and behave exactly the same, whether they’re in IE6 or Chrome 17. This has not been easy to achieve. It’s not just a matter of adjusting to the well known problems such as IE6’s broken box model, but also working around a multitude of other browser quirks (such as the extensive bugs in IE’s VML implementation for our web charting.) Suffice to say, as a cross-platform framework company, we put a lot of time behind abstracting browser inconsistencies.

When it came to developing Sencha Touch in late 2009, we took a slightly different tack. Our primary goal was to create a web framework that could provide a native-quality application experience.

Quite quickly, we figured two things out. First, most smartphone hardware on the market simply didn’t have the power to run high quality experiences in their browser. Second, many mobile browsers (Blackberry OS 5, Windows Mobile 6 CE etc.) lacked the JavaScript engine or the CSS support that we needed to create compelling user experiences. With these two constraints, we decided that our initial version of Sencha Touch 1 would target just the built-in browsers for both Android and iOS. Luckily, at the time, those two browsers were responsible for the vast majority (90%+) of all mobile web traffic in the U.S. (as measured by ad requests http://www.slideshare.net/admobmobile/ad-mob-mobilemetricsapr10). Our interpretation was that other platforms were delivering such a bad experience that few people were using them for regular web browsing.

The biggest benefit of targeting just these two browsers was that we could take full advantage of the huge set of -webkit visual effects – which were then mostly available only on WebKit-based browsers. Gradients, transforms, transitions, border-radius, and CSS masks were indispensable in creating the richest experience possible. Even though they were technically experimental, most of them had standards track documents that meant that we could rely on some form of the capability being a standard at some stage for other browsers, if and when they arrived on volume mobile platforms.

Using WebKit effects reduced the size of our download package (far fewer images), allowed for easily themed applications, and drastically increased the performance and smoothness of our animations. In particular, CSS 3D transforms were hardware accelerated on iOS, which delivered noticeably better frames per second when compared to JavaScript-based animations. Without WebKit effects, we simply wouldn’t have been able to deliver the quality of product that we needed.

Subsequent to our release of Touch 1.0, there have been a bunch of new mobile browsers from RIM, Mozilla, Opera and Microsoft. We’ve added support for RIM and announced our intention to add support for Windows Phone. As a leading implementor of “WebKit” only mobile frameworks, we’re often asked when we’ll add support for these browsers. Here’s how we think about this.

For us, “supporting a browser” is not just a matter of adding multiple vendor prefixes or doing feature detection. Every single browser we support —even the supposedly generic WebKit ones— have had major differences in the correctness and performance of features, which makes the “use feature detection” approach advocated by many fairly useless. We have browser specific code for Android 2.2, 2.3, and 4. We have code just for the Kindle Fire and code just for the Blackberry Torch. Our list scroller implementation for Android Gingerbread is based on scroll position animation and our list scroller for Android 4 is based on CSS transforms. This attention to detail, and our browser-specific code, is needed to create the most compelling experience possible. It’s why people use frameworks rather than try to code to the naked browser.

In addition, we’re a developer’s developer, so we care about supporting the browsers that our developers care about developing to. Today, that means Android, iOS and Blackberry. Soon it will be Windows phone. This means that a lot of -ms is going to start showing up in our CSS files, and it also means that we’ll be replacing WebKit-specific effects that do not look like they are headed to standards track. The two major effects that are only are truly useful but have no standards track document yet are background-clip: text and CSS masks. (There is an aspiration to move these effects in to a general FX spec at some point in the future, but we would have much preferred that Apple or Google submit standards track documents for these much, much sooner.) These are now supported in both Firefox after a fashion as well as WebKit. These effects are useful for theming icons and other small graphics that can be delivered as custom fonts. For Windows Phones, we’re looking at the prospect of using image based theming, fonts or SVG masks. But we hope IE implements CSS masks soon too.

On the other hand, we see only minor demand from our developers that Sencha Touch work on Firefox Mobile or Opera Mobile because each of these has much lower levels of usage on smartphones. But this isn’t the only reason that we don’t support them, it’s because in our opinion, the quality of the implementation of the effects that we need to use is often much poorer in these browsers (although we’d also cast stones —big ones— at the Android 3 browser). If Mozilla decides it’s going to expropriate -webkit prefixes and masquerade as an iOS browser, we can see a requirement for us to figure out a different way to detect that it’s Firefox and disable those effects.

At a higher level, we agree that it’s very odd behavior for Mozilla to cry wolf about a WebKit-only monoculture when their implementations of the effects that we and other developers are most excited by have been dilatory and underwhelming. And, we’re not worried about a WebKit-only monoculture, it’s clear that IE10 has a pretty good shot at overturning WebKit as the best browser on Windows. At the very worst we’re looking at a duo-culture.

So after all that context, here’s what we’d like to see.

First, no prefix squatting. It’s a terrible idea and will make developers go through contortions to route around it. Daniel Glazou’s proposal that it’s ok to squat only in the smallest possible way, may not be a terrible stop gap, but we’d still prefer “no squatting period”.

Second, a much stronger effort from the browser makers to move experimental effects into standards track. At most, there should be a 6-month delay between first ship and an Editor’s draft at the very least. Even now there are a ton of effects that remain outside standards track. Just two more examples, WebKit text decoration effects should be integrated into CSS Text. And CSS Masks —which arrived in WebKit in April 2008!!— should have long since been put into a track document.

Third, more aggressive pruning of non-viable standards track features or even whole standards track documents. For the longest time, the CSS Text spec was a peculiar species of speculative fiction. I can point to other living dead spec documents. It’s not very helpful when we have to read transcripts of meetings and long discussion threads just to figure out what we can count on and what we can’t. And waiting for something to hit Candidate Recommendation status is not realistic.

Fourth, more aggressive pruning of experimental features that have been rejected as ‘a bad idea’ by the CSS Working Group. There needs to be a “negative standards doc” listing things that “ain’t going to happen”. It’s been very clarifying for us for WebSQL to be declared a dead end (although we personally liked its functionality quite a bit.) Once a feature hits the negative standards track, browser makers should have 6 months to remove it from their edge versions.

In any case, this is the take on the prefix kerfuffle from the perspective of a mobile framework developer. Enjoy.

[senchainc-blog]

Last time we posted about Xero, they were featured as Business Insider's App of the Week. This time they're up for an IxDA Interaction Award!

We're voting for their incredible implementation of Ext JS and Sencha Touch, and we hope you will too!

Vote for Xero today »

[senchainc-blog]

Embed CSS3 Animations in an iBook using Sencha Animator and iBooks Author

Sencha Animator lead Arne Bech quickly figured out that you can embed Sencha Animator exported projects in the new HTML5-powered iBooks released yesterday by Apple. Check out our quick tutorial to learn how, then download the project files to start your own interactive iBook!

[senchainc-blog]

I can report that our JavaScript framework of choice is Ext JS by Sencha. This framework can serve as a solid foundation for any serious JavaScript development.

Yakov Fain, Farata Systems (via [Adobe Flex Journal](http://flex.sys-con.com/node/2124139))

[senchainc-blog]

**Sencha is hiring!** 2011 was an incredible year for Sencha and its employees. We nearly tripled the company, and we're not done building the team! If you'd like to come work with us in the Silicon Valley, California, be sure to [check out our Careers page](http://www.sencha.com/company/careers) for open positions.

[senchainc-blog]

Nice Sencha mention in this recent eWeek deck on the major transition to HTML5 happening right now.