ExtJS SASS disabled button color bug

Whud'up?

Bugs are everywhere but level 0 bugs kinda irritates you even more - such is the bug I want to discuss here.
As you know, ExtJS have SASS as the technology behind the framework's CSS. They did one hell of a job there, and so creating new custom themes is something that was made very easy.
Changing the color of a button text is somewhat elementary, when it comes to creating a new theme.
A part of it is changing the "disabled" state color on a button, which should be so trivial and shouldn't take more than a minute to implement. Alas, this is not the case for ExtJS.

You see, when you set the disabled color via the button ui mixin, you find out that it uses the "up" state color eventually.
Going into the code of the mixin, the cause reveals itself:

@if $color-disabled != $color {
color: $color !important;
}

See that? If the disabled color is not equal to the color, use the color? Definitely a copy/paste bug.
Check out this next post at Sencha forums, where you see that I'm not the first one to encounter it.
the code should actually look like this:

@if $color-disabled != $color {
color: $color-disabled !important;
}

So, first of all - I hope that this post will stop your frustration as to why is this happening, and secondly, I have a workaround (or two) that you might wanna use:
The simple solution is to override the ExtJS mixin in you own .scss and fix the bug.
Another solution really depends on whether you're building you project using some kind of a build technology which has an artifact dependency mechanism (Maven, Gradle, etc.), and then you can make the modification at the SDK and deploy it to you artifact repository, with a slight version update to differ it from the original SDK.

Cheers

Displaying JS Code inside ExtJS TextArea

Hi guys,

Well, in this post I would like to talk about how to display a code snippet inside ExtJS. Say you want to create a panel where you can see a code snippet, copy/paste of whatever, but you want this code snippet to come from an actual file, in our case - JS file, and be loaded at runtime.
So, how do you do that?
It's pretty simple in the end, but finding and assembling the solution is not as trivial as you might think (and so I wish this post will turn future searches to be much faster than mine).
We're going to use a config property of the TextArea called "loader", which helps us in loading remote content to the TextArea. This loader can receive a URL to tell it from where to load the content and it has several predefined renderers that can be applied on the content and, well, render it accordingly.
Since we don't have a JS code renderer predefined, we can use a function instead of a String defining the renderer type, and in that function declare how we want the code to be rendered, which is mainly some indentations, at this point.
I used the code snippet from here to create the RegExp needed to render the code nicely (BTW, please find the ones who invented RegExp and electrocute them somewhere, ok?).
So with out further a due, here is the code for displaying a JS code inside an ExtJS TestArea.

xtype: 'textareafield',
autoScroll: 'auto',
width: '100%',
height: '100%',
loader: {
url: 'https://localhost/springapp/js/app/view/component/codesnippet.js',
autoLoad: true,
renderer: function(loader, response, active) {
var text = new String(response.responseText);
text = text.replace(/&/mg, '&');
text = text.replace(//mg, '>');
text = text.replace(/\"/mg, '"');
text = text.replace(/\t/g, ' ');
text = text.replace(/\r?\n/g, '
');
text = text.replace(/

/g, '
');
text = text.replace(/ /g, ' ');
loader.getTarget().update(text);
return true;
}
}

Cheers

Extending ExtJS 4 DatePicker to highlight marked dates

Hi guys,

So today I want to share with you a little extension that I re-wrote for ExtJS 4 DatePicker component.
I say re-wrote, because this is an advanced form of the solution presented here, except that the other one relates to ExtJS 3 and not as robust.

So the basic idea is to have a marked dates on the calendar, same as you would have on your meeting calendar date picker in outlook. I also wanted the component to show some related tooltips for the marked date, and that meant that the data provider for the component is not strictly dates (as in a String, like the other solution), but rather an Objects that contains some metadata for the date.

Let's start with the data that we wish to be displayed. We want to have the date marked, so we need a Date, and for this example we will use the JS Date object, and for each date we want to display tooltip for a mock percentage and cost. So we're actually talking of an object that might look like this:

{date:new Date(2011, 10, 19), percent: '30%', cost:596}

On the component itself we I've created a config member named "markers". This one will hold the array of objects mentioned above.

config: {
    markers: null
},

In addition I want the JS Date object that is given to the DatePicker to use the same date format that is configured for the DatePicker, so for the sake of that lets override the applyMarkers method and in it apply the DatePicker format on each date. With this process we're actually changing the data within the markers from a simple Array to Associative Array, or a Map if you want, where each cell is defined by the formatted date and in it holds the metadata. This will help us later in marking these dates easily.

applyMarkers: function(markers) {
var formattedMarkers = [],
me = this

var formatDates = function(marker) {
var format = me.format,
eDate = Ext.Date,
formattedDate = eDate.dateFormat(marker.date, format)

formattedMarkers[formattedDate] = {percent: marker.percent, cost:marker.cost};
}

Ext.Array.each(markers, formatDates);

return formattedMarkers;
},

We're getting to the heart of the modification. Here we override the fullUpdate method of the DatePicker since it is the one that is in charge of rendering the cells within the calendar, we will add our own "if" statement to ask if there are dates to be marked, and if so we will find the cells that match the dates on the associative Array and append a tooltip according to marker object data.
For convenience purposes I'm only giving the relevant code part:

fullUpdate: function(date, active) {
...
var markers = this.markers;
...
setCellClass = function(cell) {
...
// If we have a need for highlighted dates, let's find the dates
// and start highlighting them
if (markers) {
formatValue = eDate.dateFormat(current, format);
if (markers[formatValue] != null) {
// Use the highlight-date CSS class for highlighting
cell.className = 'highlight-date';
cell.title = "Percent: " + markers[formatValue]["percent"] + "\n" + "Cost: " + markers[formatValue]["cost"];
}
}
};
...
}

Notice that I'm using a CSS class named "highlight-date" to mark the cells. This class, of course, should be included in your CSS file.
And there you have it. A DatePicker that lets you mark dates and append tooltips for it, here is how you use it:

Ext.create('Flashmattic.component.AdvancedDate', {
markers:[
{date:new Date(2011, 10, 19), percent: '30%', cost:596},
{date:new Date(2011, 10, 10), percent: '10%', cost:45},
{date:new Date(2011, 10, 8), percent: '86%', cost:367}
]
})

Have a great week,
Cheers.

Apache Flex? Hell yeah

You've probably heard the old news, about Adobe ditching the development for Flash Player on Mobiles devices, but here is something even newer:
From the "your questions about flex" announcement it is pretty sure to say that Adobe has decided to ditch the Flex SDK and BlazeDS development and proposed an offer for the Apache Software Foundation to "incubate" both.
Before you jump into conclusions I strongly suggest that you read the Q&A once again, to understand what this step means to the Flex community. And now that you have, I'll give you my 2 cents on the topic.
Although many will refuse to believe, I did foresee this coming, though I didn't imagine that Adobe will renounce themselves from Flex, and I still stand behind my words that "ditching Flex and moving to HTML5 completely is also not the smartest path to take" but enough quoting myself.
Many might say that this announcement is the final nail in Flex coffin.
I think not.
As a matter of a fact, this might bring the Spring (pun intended) of Flex and maybe put a sock in the mouths of those Java geeks who walked around shouting "Adobe is not a code company" - meaning that Adobe cannot be compared to Oracle (Sun) in delivering a coding platform like Java. Now if Apache takes the wheel this might change for the best.
I will say it again - Flex will lose it's place in the RIA technologies market. HTML5, at it’s uncompleted form today, can already supply 90% of what Flex can offer, however, Flex is still a valid technology, as I see it, and if I came across a project that shouts "Flex!", I will not hesitate.
If Apache will except Adobe's offer, this will mean that Adobe no longer decides where Flex goes - the community does. If back then, we had to scream for better compiler, I believe that in the hands of Apache the response will be quicker and much better.

Just think of it - "Apache Flex".
Too bad Adobe is keeping the development for the Flex Builder, but what can you do.
So - no doubt that the future will be interesting (in spite of HTML and JS) and I do wonder what Adobe and Apache will cook for us. In the meantime, try to remember these unquestionable truths:

• Flex offers complete feature-level consistency across multiple platforms
• The Flex component set and programming model makes it extremely productive when building complex application user interfaces
• ActionScript is a mature language, suitable for large application development
• Supporting tools (both Adobe’s and third-party) offer a productive environment with respect to code editing, debugging and profiling

Cheers

Combine, Minify and Copy your JS's to your .war file using Gradle

So - In the course of work I was introduced to Gradle.
WTF is Gradle, one might ask - in brief? It's a much flexible manner of building your projects than Ant or Maven. It's based on Groovy (which always makes me laugh thinking on the nerd who came up with that name and thought he is so damn cool), and I leave it to you to go and read about it.

First thing first I wanted to build my .war file. No problem there. Just apply the "war" plugin to your gradle.build file and you're done. Seriously - that's it.

apply plugin: 'war'

So I have my .war file empty and now I want to add my JavaScript to it. Oh, wait - I want to add my minified JavaScript to it, not just that, but I want to combine all of my JS files into one, and just then minify it. To the rescue comes gradle-js-plugin which can minify my files using the infamous Google's Closure Compiler and of course the easy way gradle lets you arrange and configure it's tasks.

So I added this plugin, like this

apply plugin: 'js'

And asked it nicely to combine all the files and simple-optimize it. As you can see, my JS files are under the src/main/javascript directory

combineJs {
input = fileTree(dir: "${projectDir}/src/main/javascript", include: "**/*.js")
output = file("${buildDir}/all.js")
}

minifyJs {
input = file("${buildDir}/all.js")
output = file("${buildDir}/all-min.js")
compilationLevel 'SIMPLE_OPTIMIZATIONS'
warningLevel = 'QUIET'
}

As you remember I wanted to make all that before I copy it into my war so, I've added this procedure before the .war building. Again - compared to Maven, it's done pretty easily by using the doFirst task method

war.doFirst {
tasks.combineJs.execute()
tasks.minifyJs.execute()
}

Ok - so now we have a combined minified JS file on our build directory, the next thing to do is to copy it into the .war file. Here I use the war plugin again and use it's webInf() method to add some content to the WEB-INF. I'm copying the minidified file into the root of the webapp under a directory named "js".
Actually the webInf(method) is responsible for adding resources to the WEB-INF directory, not the root of the webapp, but by adding "/" before the "js" I've worked around it.

war.webInf {
from "${buildDir}/all-min.js"
into "/js/"
}

There you have it. Running gradle build will create our webapp with all the above included.
I guess that this is not the last post on the topic, since gradle will probably walk with me several miles, so stay tuned.

Cheers.

Flex Missioner talks ExtJS

The Plot Thickens
You know - It always made me laugh and then feel sorry for the new emerging RIA technologies. As a Flex senior missioner, I found those fail attempts pathetic at. I'm obviously talking on platforms like "Silverlight" (Silver… what? Oh, that project MS closed not so long ago), "Open Laszlo", "JavaFX" (heheh oh boy, the horror!) and the list goes on and on.
To me it appeared that JavaScript is a script (I dare you call it a programming-language!) that played it's part in the web world some 10 years ago, and has no place, but frustration, in today's web technologies.
Alas, Came Steve Jobs and thickened the plot.
HTML5, as the new web standard (you're kidding, right?) enters and changes the game rules. Suddenly we're back at the mercy of JavaScript. Things like the DOM which I happily have forgotten for the sake of Smart View Interfaces, reincarnated and came back to haunt me, along side with browser incompatibilities, poor debugging, and messy code. God damn.

A new hope...
It was then that I have discovered a new hope.
Now, as some of you may know, once upon a time there was ExtJS, which was and still is, a very nice JavaScript library. Then, one day, came the merge with JQTouch which gave birth to "Sencha".
History is lovely, isn't it? Yeah… whatever.

I'm skeptic when it comes to new RIA technologies. Maybe it's because I know what it means to really compete with Flex for territory. I'm not the kind of UI Architects that sees a nice Control or a Component and jumps with joy, pants down, shouting "Eureka!". When it comes to the best UI technology for web applications there are a lot to consider, like: Richness, Extendibility, Community, Browser Support, Vendor liability, Ramp up Time… just to list a few.
ExtJS knocked me down.
I'm used to seeing pixilated controls, with "not quite there" finish to them, but here it actually looks like… well... Flex! Even better to some extents. Going to create a theme in ExtJS, and you will find freaking amazing integration with SASS and Compass that generates you're CSS and with a single variable can alter the entire look of you're application. Now try to extend one of it's components. Again - nothing dodgy there. MVC you say? Well, you have it. I know it's a bit twisted but there is a solution that actually give you the benefits of MVC.
And JavaScript? ExtJS made it so close to OOP, that you even don't feel the heartburn when writing "new" to create an Object.
Oh wait, hold on - what about the client Data package? No problems there, mate. JSON you say? There you go - a verity of "proxies" to integrate with any kind of Web Services out there (though I didn't see any AMF implementation, and as you know AMF out-performs any String based communication when it comes to large masses of data). This, my fellow Flexers, is not some immature platform we're dealing with here. It looks like every aspect was thought of.

Sitting on the shoulders of the giants
So, some might say, and be right about it, ExtJS is sitting on the shoulders of the giants, meaning it looks as if a lot of the component architectures, down to the Data packages ware "inspired" by other technologies, and dare I say, Flex in particular. Do you have a problem with it? On the contrary my friends, I'm good with that.
I must say, though, that the layout configuration is somewhat not intuitive, where words like "fit", "flex" and "stretch" don't do exactly what you thought they would, and hey - don't forget the whole browser compatibility, where extJS 4 doesn't really play nicely with IE9 (CSS gets screwed up and other kinds of glitches)… oh well.

Breathing on Adobe's neck?
Another thing to add to the grill is the fact that Sencha has launched it's own Animator, as if breathing on the neck of Adobe which also, recently, launched it's own solution for animation and transition editing tool for HTML5. now - that's pretentious of Sencha. Why? I believe that the experience that Adobe has in Designer IDE's plus the advantage they have from Flash, plus the integration with other graphic tools (Photoshop, Illustrator) will probably crush any attempts from Sencha, but you can never know. History teaches us that it can take only a single Company to change the entire developing agenda of the web, even if it's taking it 10 years backwards.
:)

Cheers.

Who moved Adobe's Flex?

You're all probably familiar with the book "Who moved my Cheese?" by Spencer Johnson which basically talks about reacting to changes in life. If you don't know what I'm talking about, go a head and read this short story.

In any case, the analog I want to share and discuss is referring to Flex as the cheese, and just to make it clear - I'm not taking any sides here (since, really, It's getting hard to side any particular one recently), but rather tell you how I see things.

The way I see it, someone did moved Flex. It is clearly no longer the best tool for creating RIA. Nowadays you have HTML5 and all the JS libs that pop up like mushrooms after the first acid rain. HTML5 is the real competitor in the field, and don't let anyone tell you different. The lately passed away Silverlight and the ridiculous JavaFX were never a match for Flex and Flash.

Now, if you were the mouse in that story you would smell the change and act upon it, meaning - go and learn HTML5 and take the rust of your JS skills. It is pretty obvious that sitting, doing nothing and waiting for Flex to come up with a game-changer bunny out of it's hat is the bad choice here, but, and that's big "but", ditching Flex and moving to HTML5 completely is also not the smartest path to take.

It is true that web developing, and RIA in that sense, are going through some major changes. It is odd, one might think, that the future lies in technologies that belong to the past. I have to admit that the future looks very interesting and challenging. What Adobe's sees for the future is a fantastic integration between it's Flash platform and HTML5. The possibilities are amazing. This is what I also see in front of me.

Whilst HTML5/CSS3/JS are proudly presenting the major features they have, Flash player now supports, among others, a monstrous 3D rendering engine called Molehill. It always seemed as if Flex/Flash is leaving the trivial stuff to HTML, while it itself is moving forward to more complex features. Trivial, today, is what Flex offered in the past 5 years. Let HTML5 do that. By all means - why not?

And now you hear that IE10 will not support Flash (to some extent), which is, IMHO, a poor decision MS made. Any UI technologist can see the tremendous value in combining HTML5 and Flash together. A browser that will not support this integration is doomed to vanish.

So yeah, the change is here already and yeah, people who wish to stay relevant need to embrace it, but this doesn't mean one should take one path over another. What we have ahead of us, is a parallel lane road. We can, and should, drive in both lanes alternately.

BTW - Wanna know who moved the cheese?
Mr. Steve Jobs.

Google Is Buying Motorola

Now it's only a matter of time, Apple :)
Please refresh your memory:

• Why continue developing for iOS?!
• Why Android Defeats iOS 
• Those who don't know their history are bound to repeat it 

Enjoy

OT: מנג'יני לא סוחב

צילום: ארז כרמל

ולו רק בכדי להצדיק את כותרת המשנה של הבלוג הזה, הא לכם רשמים של עבדכם הנאמן מההופעה של Dream Theater שהתקיימה לפני מספר ימים.
שורה תחתונה, לבוא להופעה עם כרטיס VIP זה משהו אחר לגמרי. ראשית, זה מעיד עליך כי זקנת ושיבה זורקת בשערך. ובנינו, למי יש פין להדחף אל בינות ילדים מזיעים, אפילו אם זה אולם ממוזג? ראבק, זו גם הפעם השלישית שאני פוקד הופעה שלהם, אז פעמיים הזיעו עליי ממיטב בתי-השחי (אפילו הטורקיים שבניהם) וזה מספיק בכדי להבין שקצתי.
לאחר שנכנסנו כלאחר כבוד מהתור לזקנים, והתמקמנו על הכיסאות של הטריבונה היינו מוכנים לכל מה שבא. ואכן, התקליטן של האולם הנעים את זמן ההמתנה במה שנשמע כמו דיסק האוסף  המתוייג בטוש "רוק ושונות", שכן עפנו ממטליקה אל פינק פלויד אל Rush. אקלקטיות של אושפיזין קבוע באברבנל. הקשר מקרי הן לאירוע והן למציאות. ישראל, מה תצפה?
לפנינו יושבים מספר קינדרים עם כל התוספים הנדרשים - מכנסיים קרועים, כובע של דידי מנוסי, חולצה של הלהקה וגרופית. אני, אישית, לא מבין מה עושים ילדים בני 17-18 עד הטריבונה ולא עם שאר זבי החטטים למטה. איזה נוער קקה זה, הא? חס וחלילה שלא יתלכלכו נעליהם מבדלי הסיגריות.
הקהל החל זורם פנימה והנה להקת החימום עולה. משהו שנקרא Against the wall, שזו המלצה שבכיף הייתי מאמץ לחיקי ומוסיף מטח יריות סטייל מוסוליני. גיטריסט וסולן שלא הפנים שזמר הוא לא, עוד גיטריסט שלפי הקפיצות והעיוותות גוף שלו וודאי שכח את אחת התרופות בבית, בסיסט קטן ומתופף. הם מנגנים מין סגנון שאני יכול להגדיר אותו כ"מטאל עם נגיעות של זבל אמריקאי". בקצרה? שההוא לא ישיר, ממש לא חייבים לדחוף בלדה לכל שיר, לדחוף פרסומת בזויה לחנות כלי נגינה באמצע ההופעה גורם לכם להראות כמו האחים ג'ונאס ו... אל תשיר, בנאדם, אתה גיטריסט מוכשר מאד. תסתפק בזה. בבקשה.
אחרי נצח קל הם ירדו מהבמה ואז החל סשיין שאני לא יכול להסביר עד הרגע בו אני כותב מילים אלו - סרטון וידאו של חבר'ה שקוראים לעצמם סולסטיס קוייל, באים ומסתלבטים על סירטוני האודישן למתופף של DT. איזה קורע, הא? היינו צריכים לצפות בחרא הזה 10 דקות. מי אלה, ולמי, לעזאזל, אכפת מהבדיחות הפרטיות שלהם? איזו שכונה זו?! אם אני הייתי המנג'ר של DT הייתי תובע להם את הנשמה עד לזה שישב וכתב את הכתוביות בכדי שכולם יבינו את ה "גיחי גיחי", אך מסתבר ש DT דווקא תמכו באמבציליות. בשביל זה אנשים שלמו כסף? מה זה?!
ואז הם עלו, ואין מה לומר. פטרוצ'י הוא בנו של לוחם ויקינגי עטור נצחונות. הגוץ הזה פשוט עומד שם כמו רובוטריק ומעיף את הקהל עם הפתיחה של Under a glass moon. זה לא משנה שהגיטרה נראית עליו כמו זו של גיטאר-הירו. באיזשהו שלב אתה מבין שהוא למעשה האחיין של הרקולס.
חבורת הדרדקים העומדת לפני החליטו שהם קמים. דבר הנוגד לחלוטין את הרעיון של ה VIP. שבו נבלות. אבל הם בשלהם, מקמצים את אצבעותיהם לסמל המגוחך של רוני ג'יימס דיו ורוקעים ברגליים. כן, רוקעים ברגליים על טריבונה שמאד מזכירה את גשר המכביה. אני כבר ראיתי בעיניי רוחי איך כולנו צוללים מטה, בין ברזלים עקומים וכובעי דידי מנוסי. כמובן שהילדודס עמדו כל ההופעה, מה שהכריח אותי גם לעמוד כל ההופעה, מה שגרם לי להבין כי זקנתי אף יותר משנדמה לי, אבל מה? תהרוס להם את הכיף? שיעמדו הנבלות, שיעמדו.
והנה כולם מסונכרנים, וכולם מחכים לכניסת התופים של אדון מנג'יני. ומנג'יני? מנג'יני לא סוחב.
עכשיו אני לא אומר את זה בגלל שפורטנוי הוא האב הרוחני של הלהקה הזו, הרוח היוצרת המעניינת היחידה שם והאיש שידע לתקשר הכי טוב עם הקהל שלהם. אני אומר את זה כי פשוט מייק מנג'יני מתאמץ, מפוצץ וגורם להכל להישמע ב laidback. בעוד שפורטנוי התעופף בחינניות על המערכת, מנג'יני עובד קשה כמו חותך שווארמות באוגוסט... באילת. התופים שלו מכוונים מאוד נמוך. כל טאם-טאם זה כמו נאפלם ובכלל, המערכת שלו נראית כמו כלוב בעוד מנג'יני נראה כמו שימפאנז הכלוא בו, חסר אונים נוכח האתגר, מתקיף כל סורג תוך כדי שהוא מסדר את שיערו הסתור לעיתים יותר מדי תכופות.
אזני הרגישה אף קלטה מספר פישולים, אפילו בקטע הדגל Ytse Jam, אבוי. הו אז הבנתי - הוא יודע לעשות דברים מאד מהירים עם יד אחת, המנג'יני. מרגש. אבל מה מעבר לזה? יוק. אין ספק שהפלייליסט האפעס משעמם ש DT נגנו באותו ערב, היה בחלקו בזכות יכולות התיפוף של מנג'יני, שכנראה לא יכל לקטעים מעט יותר מורכבים בזמן הקצר שהיה לו להתכונן אליהם.
גם העובדה ש DT דוחפים אותו כמו איזה מוצר חדש על המדף מכעיסה נורא. נתנו לו סולו תופים, שעל פניו היה בהחלט מרשים, אבל אנחנו יודעים שהוא מתופף נחשב. אז מה? הוא מנגן מהר ולא מעניין. בעודו מתייזע על התופים אני שואל עצמי מה הוא יוכל לתרום ללהקה, מעבר לעליזות רוחו העולזת ומזגו העליז (אהמ...)?
מפה לשם הגענו לשיר החדש של הלהקה שאם אסכם אותו זה יסתיים בשעמום טהור. אבקת זיפ של נדוש. תרכיז של פיהוק.
מה שכן, מאודי לא ראיתי את ג'ון מיונג כל כך פעלתן. זז, הד-בנגינג, מסתכל, מנגן יחד עם העולם! וואו! עוד שנייה אולי הוא היה פותח את הפה ומדבר. כל זה גורם לי לחשוב שהנזיר שאולין השתקן הזה הוא זה שטרפד את החזרה של פורטנוי לשורות DT. נו שויין.
אחרי שעה ארבעים, הם ירדו, לא לפני הדרן ולטעמי, משלוש ההופעות בהן ביקרתי, זו הייתה ההופעה הגרועה ביותר. אני לא חושב שזה היה בגלל הטריבונה, אני לא חושב שזה בגלל הילדים שעמדו כל ההופעה כמו נרות חנוכה ואני לא חושב שזה היה בגלל הסאונד המעט עמום. DT הם מכונה משומנת של מוזיקאים ושל כסף, ככל שזה מצער לשמוע. החברים משווקים עכשיו מוצר חדש עם תוסף דלק פלסטיק בשם מייק מנג'יני, שעם כל הרצון הטוב, לא מדגדג לפורטנוי את ההיי-האט. יש מצב שהתקליט הבא שלהם יהיה משעמם. אולי אפילו יותר משעמם מאוקטבריום (ממנו הם נגנו בהופעה, לשעמומי כי-רב). יש גם מצב שלא. מי יודע? אני מקוה כי יום יבוא וכולנו נצחק על התקופה ההזויה הזו בה הם ניסו להחליף את המנוע מאחורי ההצלחה. ועד אז... ואללא, שיהיה רק בשמחות.

Why continue developing for iOS?!

Hi guys,

You probably know the concept behind modular application in Flex, right? Right. And you probably thought it would be super cool to load external applications into a shell application on your mobile, right? Well I did anyway…
Did you know that iOS does not support loading external SWF's into a "shell" SWF, given that the loaded SWF uses the executable memory? It is enforced both technically and legally, which brought me to think that Steve Jobs probably really doesn't like the idea of one application loads another application.
Oh yeah, sure, you can do that with JS injection, where you create extra modules on the fly and inject them into the DOM. That is something that Job's cannot enforce restrictions on, at least technically. Legally he sure did. Don't say you didn't know.

Wanna know why?

Is it because a security breach? Nop, not really.
Is it because a performance issue? Again, no.
Is it because any reason written in the big "thoughts on flash" BS mail Job's wrote? Oh No.

The answer is - Apple's AppStore business module.
If you load application via your application you're bypassing the AppStore, (good heavens!).
As always, this is the one true motivation behind all the restrictions that Apple enforces over developers. You can do whatever you wish as long as you don't compromise the AppStore. As once was wrote: "Share it fairly but don't take a slice of my pie" and If you try to take some from Job's pie you'll be hurting.
Doesn't it seem weird to you that a single company, that no longer has the bigger share in Mobile OS in the market, still tells you how to develop your applications? Is HTML5 is really that good, or are we're pushed towards it like cattle, only to satisfy the interests of this single company?
I see great ideas tossed to the trash only because there is one mobile OS that wouldn't support them. One!
Somehow Apple has managed to convince the people that it's the only mobile solution out there.
In an era of free communication, speech and internet I have to ask - Why?!

I think it is time that developers will rise and say "if your device does not support progress and innovation, you will have a poor experience". If you're device only support CSS3 animation and transition, this is what you'll get - a sluggish, bad performing animation.
Come on, people - we are being held down by a ball and chain only in the name of product design. It's time to break free from these draconian constraints and understand several things:
Apple no longer owns the mobile market.
There are better alternatives to iOS.
iOS is no longer the most distributed mobile OS out there.
Mobile applications Developers do not work for Apple.

I call to all - develop more applications for Android, RIM, WebOS WP7 or whatever vendor which offers free of charge and constraints platform and leave that single iOS to deal with it's walled garden. make Apple beg you for content, not the other way around. We have the power to change this 1984 reality, for the better.

Think about it.

AIR and Mobile still missing a notch

Everybody's happy about the move Adobe made when it finally managed to push Flex application into the iOS. You have to admit - it is amazing, no less.
Still, being the bitter man that I am, I have to poop the party and tell you that it is far from being all a bed of roses. To be more specific, here are 2 issues that I have encountered with that made me realize that there is still a lot of work to be done on Adobe's behalf.

First one is the GPU usage and Spark layouts. You see, Spark layouts are one of the strong features that flex gives us. Having the ability to relatively easy (and I do mean "relatively", it’s not super-easy as Adobe claims it to be) create custom layouts for DataGroups is a big differentiator over other technologies. Adding the ability to transition and rotate object in 3D, makes it even more powerful. Alas, harnessing the GPU for rendering these 3D layouts on a mobile device is currently not available. Even when using the "cacheAsBitmap" and "cacheAsBitmapMatrix" properties, nothing really improves. I guess that we will have to just wait on that.

Second thing is embedded fonts. After embedding the a font, it looks pixilated and not smooth. Playing with it's style doesn't do the trick either (anti aliasing and the sort). Having the text inside an item render that supposed to be rotating and moving as a part of a layout and you have a very-very pixilated glyphs. How disappointing.
These 2 issues are critical, in my opinion. I hope that the next versions of Air for mobile will include fixes for it, but for now - just know that there are problems with it, so look out.

Cheers.

2 reasons to avoid GWT

Hi guys,

Say your role involves dealing with UI technologies and part of it, naturally, is deciding which technology fits your project best so you've probably came across the big debate of Flash/Flex vs. GWT.
Although the two can live happily together without stepping on each other's toes sometimes the project dictates using one exclusively.
Both technologies mentioned above have their pitfalls, but allow me to focus on GWT and hand you 2 good reasons why you should avoid it :)

The first reason is cross-browsers compatibility:
Well - that's a complete bullshit, and if you've been messing with HTML/JS/CSS long enough you know it. GWT only claims to be fully browser compatible but the reality shows different. Gecko, Trident,  Webkit and other browsers engines interpreter JavaScript differently. It is a fact. There is no one standard there. Read it again - it is a fact!
GWT claims it can compile for each browser permutation, but reality shows that it's simply not working on all browsers the same way.  Forget my bad experience with it - let's rely on logic and ask, can the GWT team guarantee that they have covered all aspects of JavaScript for each JS interpreter engine? All of it? Can they? Come on...
Hold on, you know what? let's say that GWT, at it's core, is browser compatible. Does anyone use GWT alone for building RIA's? I mean, the framework don't have half of the controls needed for it yet. So what do you do? You rely on 3rd parties such as Smart Client. Now, did anyone guaranteed that Smart Client is a full browser compatible? Let me help you - it's not. How about blending IE's quirks-mode into the dance? Oh, now you're dancing, mate...
So when people tell you that GWT is browser compatible, you can tell them that you will believe it when you see a full RIA application running on IE, FF, Chrome, Safari, Opera the same way.

The second reason is memory profiling (especially on IE):
While Firefox has it's amazing Firebug (got to admit it, it's pretty amazing) IE is lacking a good developer tools, at least on IE8, which doesn't have memory profiling for it's developer tool, and for a good reason, it seems, since IE is probably the worst option to run JS on, memory-wise. Modules that run smoothly on FF or Chrome, are jammed on IE, generating an embarrassingly high memory foot print. IE simply doesn't know how to decouple JS from the DOM efficiently enough, leaving objects the GC can't touch.
Now, after searching the web for different memory profiling I came up with a few solutions, but when trying them, the information was so abstract, that I couldn't pinpoint the cause for the memory leak I was experiencing.
Having GWT generate JS code under the hood keeps you wondering why the hell objects are not marked for deletion when you have no real ability to track down the reason. I hate code generators. This truly sucks ass.
So you can always remind GWT evangelists that profiling GWT memory consumption is pure hell. At least on IE.

Needless to say, but Flash and Flex do not suffer from the 2 critical problems mentioned above. Flash is truly a cross browser technology, and profiling it's memory is easy.

With that said, you will probably make your own decision, but remember what you've learned here, just in case…

:)

Cheers.

More than 400 downloads for Flashmatticomponents

Hi guys,
I'm excited to announce that Flashmatticomponents, an open source project I've created, have been downloaded more than 400 times so far.

if you don't know what I'm talking about, please visit Flashmatticomponents and check it out. all the people downloading, I hope you found the package helpful.
Cheers.

Flashoo and Wix are Opening the Summer

Hi guys,
Just a short announcement that might help you open the summer a little bit better.
The Flash/Flex forum Flashoo and the web-sites builder platform company Wix are throwing a cool BBQ on the coolest rooftop in Tel-Aviv.
This event will take place at Wednesday, May 25. 6pm. You can find all the details here.

Here is the Agenda:

• 18:00 :: Gathering, Barbecue opens!
• 18:40 :: "Flashoo in Chain" project showcase - Atar Shadmi. 
• 19:00 :: HTML5 for Flash veterans - Omri Nachman.
• 19:25 :: Flash Mobile Development - Mihai Corlan. 
• 20:20 :: Advantages of writing inefficient code - Nir Yaniv. 
• 20:45 :: 3D Flash and Molehill - Michael Ivanov and Ronen Tsamir.

You can sign up here, just hurry up cause there are only 130 open spots...
And here is the post on Flashoo

See ya there (you know - the one with "Flashmattic Flashmattic" on his sticker... heheheh)
:)

OT: Guthrie Govan

מה המצב?

גיטריסטים אצלי באים בתקופות.

אם פעם זה היה קירק האמט כשהייתי צעיר מדי להבין שהוא יודע שני סולמות ואפקט אחד (ווא-ווא למי שתוהה), אם זה מאוחר יותר מרטי פרידמן המלודי, שמאז הפך לקוקסינל יפני או ג'ייסון בקר הפנומן שמאז הפך צמח. אם זה אלן הולדסוורת' שבעצם לא רוצה לנגן על הכלי ואחריה דיויד גילמור שלוקח הכל באיזי. סטיב מורס וג'ף בק... הכל תקופות.

לאחרונה החזקתי מפטרוצ'י. באמת גיטריסט ורסאטילי מאד, שיכול לנגן למעשה הכל. הכל בלי רגש, אבל הכל. הטכניקה שלו היא בהחלט מהמוצדקות, אבל כמה אפשר להקשיב לו רץ בסיקוונצות על סולמות? אז זה יותר מהר? יופי, מרגש לי את הפופיק. חלאס...

ופתאום, ככה בשיטוטי ביוטיוב אני מוצא גיטריסט-על. יש לו את הטכניקה, רק שהוא לא עובד עם קונגו על הראש שלך. יש לו את הטאצ', הוא יצירתי ברמות אחרות ובעליו הגאים של חוש מלודי נהדר. אני גם מאוד מתחבר לגישה שלו למוסיקה בכלל ולסולואים בפרט. הפירוש שהוא נותן לתוים שהוא בוחר עושה לי המון הגיון בראש, הוא פשוט מעביר בצורה חלקה את הכוונות שלו לכדי צלילים. כל מי שמנגן יודע שהדבר לא פשוט כמו שהוא נשמע.

השם הוא גאת'רי גובאן (Guthrie Govan)

תכלס? נראה כמו קיבוצניק שסיים את האבוקדו ונשאר עם הסנדלים בחזרה של המקהלה. שיער מתולתל וזקן של נער גבעות... בחור טוב, לכל הדעות. אה, הוא גם אנגלי, אז קבלו את המבטא והגישה נטולת הפוזה האמריקאית חינם.

לא לא, אחים יקרים שלי, אין הרבה דברים שכאלו. אני ממליץ לכם בחום לבדוק מה הוא מעולל ב youTube. אני מאמין שעוד נשמע ממנו המון.

אז לתקופה הנוכחית, זהו גאת'רי שמספק את הפסקול.

שאו ברכה!

No sorting for Spark DataGrid? What the hell?

Simple test:
There are numerous examples of the new Spark DataGrid on the web, Just take one of them and put "sortable" on one of it's columns… nothing.
Looking at the SDK I see this nice comment over the "sortable" getter:

/**
* TBD
*
* @default true
*/

TBD as in To Be Decided?
Are you serious, Adobe?
Did you really take away the most important feature of the data grid?

I might be wrong here, but information on the blogs and documentation clearly suggests that Adobe chose not to implement this feature at the moment.

Disappointing to say the least.

Custom Scroll bars for MX Tree with no "white box"

Hi guys,

We ran, at work, into a styling problem which has a simple solution yet elusive.
When you try to custom an MX tree (since Spark tree is not available at the moment) you create a vertical and horizontal scroll bars, same as you would anywhere else.
Once both are present you'll notice that there is a small "white box" in the gap that both leave at the bottom-right. Now this bug is known and has a workaround when happens on any Container based control. The solution relies on the fact that there is actually a member named "whiteBox" on the Container that represents the rebellious shape. Set it's visibility to false or it's alpha to 0 and there you have it.
The trouble is that the Tree, or for the sake of the matter, the ListBase doesn't have this "whiteBox" member, so where does it come from and how do we make it go away?
Simple (and some might say, stupid) answer - the background. Just set the background color to "null" within the CSS, and no more white box. Here is a code sample:

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

   xmlns:s="library://ns.adobe.com/flex/spark"

   xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600"

   backgroundColor="0x000000">

<fx:Declarations>

<!-- Place non-visual elements (e.g., services, value objects) here -->

</fx:Declarations>

<s:layout>

<s:VerticalLayout verticalAlign="middle" horizontalAlign="center"/>

</s:layout>

<fx:Style>

@namespace s "library://ns.adobe.com/flex/spark";

@namespace mx "library://ns.adobe.com/flex/mx";

mx|List {                        

content-background-color: "null";

}

</fx:Style>

<s:Panel

width="400"

height="300">

<mx:Tree

width="100%"

height="100%"

horizontalScrollPolicy="on"

verticalScrollPolicy="on"/>

</s:Panel>

</s:Application>

Hope this helps you,

Cheers.

HTML5 Canvas Performance - should we be worried?

Here is a Tweet from Grant Skinner that surprised me, since Grant is one of the pioneers in Canvas development, having his team develop EaselJS, a framework that puts sense into the mess we call Canvas.
Grant claims that HTML5 Canvas performance is something to be worried about, as it appears to be sluggish, and I must say that from the experiments I've done with it, I've noticed that too...
Knowing Grant's work, I'm pretty sure that he had tested and benchmarked all there is (and probably still is) to back his assessment.

I, like Grant, would really like to know what Steve Jobs has to say about it.

HTML5 Context Updates :: Are you serious?

Hi guys,

So HTML5 is out there and the Canvas is one of it's big promises (aside from the fact that all that is being done so far as for samples of what can be done with it, was available, like, 10 years ago with Flash 4, but let's not let the facts confuse us).

As a technologist in spirit and a Lego-boy at heart, I jumped at the opportunity to play with the Canvas and get my hands dirty with it's bits and bytes. I guessed it would be a good idea to share my experience with it, especially from a Flasher point of view, since you have a lot of HTML-ists out there that are so excited that things move on their screen just by writing HTML and JS that are ready to claim that Flash is dead.

I'm not going into the tools and libraries that are popping up everywhere, but rather to what the technology offers in the means of rendering and controlling the graphic objects on the stage (can we call it that? Yeah, sure, why the hell not).
So it appears that each Canvas has it's own context. This context is where you draw your stuff on and is the object you render.

Let's say you want a ball to move from the left to the right. Simple enough in Flash, you create a ball, throw some motion Tween on it, and you're good to go. Not so much in HTML5 Canvas.
In HTML5 you draw the ball on the left, and each time you want the ball to move, you update it's coordinates and draw it once more. This goes on until the ball has reached it's goal position.

Now, some may say that this is what happens under the hood in the Flash Player, but the bottom line is that you have to make this "update coordinates-clean context-redraw" every time you wish something to move on your screen.

This means that if you have objects for each player in your new game, you have to implement the "update" and "redraw" methods, and moreover - call them manually (on a timer or what have you).
Does this suck? Hmmm… A bit. It's like you have a heart beat (or EnterFrame) which is not a core part of the technology, but rather a pace maker the developer needs to control.

This makes me realize that although you can draw and move stuff on HTML5, the framework is so immature in compare with Flash/Flex, that it makes the comparison a bit embarrassing.
This certainly does not mean that it's not heading the right way in full speed (given that the path has been laid before, now we only need to convert it to HTML5), but it would take some time.

I will be here, monitoring it and getting my hands dirty…
Until then… Have a good one :)

Spark ItemRenderer States Bug

Hi guys,
Here is something I found myself struggling with for an hour, and I thought I might spare you the time. In spark, when you wish to create a Spark Item Renderer, you typically create a new class that extends, obviously enough, the ItemRenderer class.
This is what I did, but I wanted more functionality to it, and implemented some states to that renderer. Which is trivial enough, some might say...
What happened is, that when hovering over the Item Renderer I've just created, the states started acting weird. Mainly changing to the initial state for no real reason.
This seemed to be a nice voodoo in the making, but after diving in a bit , I found out that what causing the trouble is the Super ItemRenderer Class itself.

Why?
It has many features, some are related to states (normal, hovered - rings a bell?). This states handling goes crashing into the state behavior I wanted so… now I have the cause.

Solution
The way to go in my situation is using the DataRenderer which is a simple Group based Class that only implements the IDataRenderer. That is exactly what I need, and thank you for sparing me all the extra Bytes for functionality I don't need, Adobe. next time, try and direct me into using it in the first place...

That's all, people.
Take care.

Flashmatticomponents has passed the 300 downloads!

Hi guys, back in the time, I published a bundle of components up on Google Code. Since then, over 300 developers have downloaded the package!
oh joy :)
I know that 300 is not that big of a number, but then again, it sure makes me proud.
if you don't know what I'm talking about, please visit Flashmatticomponents and check it out. all the people downloading, I hope you found the package helpful. Cheers.

Setting a static background for a DataGroup

Hi guys, So… this is my first post for 2011, and a technical one. How sad, huh? Giving that we have a little less than 2 years for the great galactic alignment and the end of humanity, I thought it would be a great opportunity to display some code regarding a static background for the Spark DataGroup… yeah… oh well.

This is the thin - you would like to create a single DataGroup with an Item Renderer, but have it's content (the item renderer) spread on a background that will simulate different regions in it. get it? no? ok - what I mean is to have a background with 3 colors in it. this background is static and supplies the background for the item renderer's content.
Now, you can say: "why doing it like this, and not have the item renderer define it's background colors. Having multiple ones will create the illusion of a continuous background", right? Wrong. You will have the background just where you have data.
I want the whole list to have the same background, regardless of data. The idea of having 3 different lists combined was also an option, but I rejected it as being to expensive and, well, HTML-ish :). There must be a better way, right?

So, here how it goes:

<?xml version="1.0" encoding="utf-8"?>
<s:Application
    xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/halo"
    creationComplete="application1_creationCompleteHandler(event)">
  
    <fx:Script>
        <![CDATA[
            import mx.utils.UIDUtil;
            import mx.collections.ArrayCollection;
            import mx.events.FlexEvent;
          
            [Bindable]
            private var collection : ArrayCollection;
          
            protected function application1_creationCompleteHandler(event:FlexEvent):void {
                collection = new ArrayCollection();
                collection.disableAutoUpdate();
                for ( var x:int = 0; x < 3; x++ ) {
                    collection.addItem( UIDUtil.createUID() );
                }
                collection.enableAutoUpdate();
            }
          
        ]]>
    </fx:Script>
  
    <s:layout>
        <s:VerticalLayout
            horizontalAlign="center"
            verticalAlign="middle"/>
    </s:layout>
  
  
    <s:Scroller
        width="50%"
        height="50%">  
  
        <s:Group
            width="100%"
            height="100%" >      
            <s:Group
                width="100%"
                height="100%"
                minWidth="{dataGroup.contentWidth}"
                minHeight="{dataGroup.contentHeight}">
              
          
            <s:Rect width="100%" height="100%" >          
                    <s:fill>
                        <s:SolidColor color="black"/>
                    </s:fill>
                </s:Rect>
                <s:Rect width="100%" height="50" bottom="0" >          
                    <s:fill>
                        <s:SolidColor color="0xFFFF00" />
                    </s:fill>
                </s:Rect>
                <s:Rect width="100%" height="50" top="0" >          
                    <s:fill>
                        <s:SolidColor color="0xFF0000" />
                    </s:fill>
                </s:Rect>
            </s:Group>  
              
            <s:DataGroup
                    dataProvider="{ collection }"
                    id="dataGroup"
                    width="100%"
                    height="100%">
                  
                    <s:itemRenderer>
                        <fx:Component>
                            <s:ItemRenderer width="100" height="100%" minHeight="200">
                                <s:states>
                                    <s:State name="normal" />
                                    <s:State name="hovered" />
                                </s:states>
                              
                                <s:Rect
                                    height="100%"
                                    radiusX="10"
                                    width="100"
                                    radiusY="10">
                                    <s:fill>
                                        <s:SolidColor
                                            color="#7fff7f"
                                            color.hovered="#FF6666"
                                            alpha="0.3"/>
                                    </s:fill>
                                    <s:stroke>
                                        <s:SolidColorStroke
                                            color="0x4769C4"
                                            caps="none"
                                            joints="miter"
                                            miterLimit="4"
                                            weight="1"/>
                                    </s:stroke>
                                </s:Rect>
                            </s:ItemRenderer>
                        </fx:Component>
                    </s:itemRenderer>
                  
                    <s:layout>
                        <s:HorizontalLayout
                            useVirtualLayout="true" />
                    </s:layout>
                  
                </s:DataGroup>
        </s:Group>  
    </s:Scroller>
</s:Application>

It’s based on a sample code I took from one of Adobe's demos , just to get the whole item renderer thingy fast. What you should be interested in is that the Scroller which usually wraps the DataGroup is now wrapping a Group inside of it. this Group holds 2 items: another group for the background and the DataGroup. Inside the inner Group I've created a background with Rects, nothing fancy, just for the sake of it. I wanted to maintain the background ratio even when the scrolling is on. This is pretty much it. hope it saves you some time. Cheers.