Using Device Fonts

Setelah bekerja pada beberapa proyek yang telah bergerak teks, saya memutuskan untuk mencobanya di ol W300i. Lihatlah, frame rate yang brutal dan tidak mungkin ada orang yang menginginkan animasi berombak ketika mereka memilih item dalam menu. Jadi, saya memutuskan pilih "perangkat Gunakan font" di properti dari textbox.

Setelah melakukan hal ini, saya senang untuk mengatakan bahwa animasi berjalan jauh lebih mulus dan benar-benar cocok dengan telepon lebih baik! Jadi kata nasihat, jika anda berencana untuk menghidupkan teks untuk alasan apapun (* batuk pilihan menu), itu ide yang baik untuk beralih ke perangkat font!

Using the [] operator with Flash Lite 1.1

Flash Lite 1,1 mendukung [] operator, yang berfungsi dengan cara yang sama seperti titik dan kolon operator untuk membuat atau membaca variabel dalam klip video. Sebagai contoh, tiga pernyataan berikut adalah sama sintaks:

/*
dot, colon and [] operators can create and read variables in movie clips
*/
mymovieclip:myvariable = “test1”;
mymovieclip.myvariable = “test2”;
mymovieclip[“myvariable”] = “test3”;

The [] operator juga dapat digunakan untuk mengakses video-klip properti.

/*
dot and [] operators are equivalent for accessing movie clip properties
*/
mymovieclip._name
mymovieclip[“_name”];

The [] operator, tidak seperti titik atau operator kolon, memiliki perilaku ketiga yang memungkinkan Flash Lite untuk membuat sebuah variabel dengan nama numerik.

mymovieclip [1] = "Test4";

Melalui teknik ini dimungkinkan untuk membuat standar array array menggunakan sintaks yang juga kompatibel dengan Flash Lite 1,1 ActionScript. Contoh kode berikut menunjukkan bagaimana menggunakan [] operator untuk meniru Flash Lite 1,1 array yang erat ActionScript 1,0 sintaks berikut.

// add a movieclip named "emptymovieclip" to this timeline
// duplicate the emptymovieclip as container for an array named “fruits”
duplicateMovieClip("emptymovieclip","fruits",1);
// create variables within the fruits movieclip using the [] operator
len = 0; // store array length
fruits[len++] = "apple"; // increment len for each fruit in array
fruits[len++] = "orange";
fruits[len++] = "pear";
fruits[len++] = "grapes";
fruits[len++] = "bannanas";
fruits.length = len; // assign to a variable in the movieclip
// loop through array and print values
for(i=0; i
trace(fruits[i]);
}
// delete the fruits movieclip and variables to clear memory
removeMovieClip("fruits");

Kode ini menciptakan klip baru dengan melakukan duplikasi klip video yang kosong untuk bertindak sebagai pemegang untuk ditiru variabel array.

Fruits sebuah variabel, len, dengan nilai awal 0 untuk mewakili panjang array. Gunakan [] operator untuk menciptakan variabel dalam klip video, masing-masing dengan nama numerik. Untuk setiap item dalam array, kenaikan variabel yang len untuk melacak panjang array.

Nilai yang len juga memberikan angka yang incrementing nama dari setiap variabel dalam klip video. Setelah menyelesaikan array, menetapkan len variabel ke variabel fruits.length untuk mengemulasikan properti panjang dari 1,0 ActionScript array.

Sekarang menggunakan ActionScript konvensional dalam 1,0 kode untuk loop dengan panjang array ditiru properti dan [] operator untuk mengakses nilai-nilai dari array.

Meninjau contoh FLA dan SWF terletak di "array operator" folder disertakan dalam artikel men-download file.

Tutorial : Multi-User Game dengan Flash Lite

Tutorial ini menggambarkan betapa mudahnya untuk membuat multi-user game untuk perangkat mobile yang dilengkapi dengan Flash Lite, Adobe Flash Player dirancang untuk perangkat selular. Versi pertama Flash Lite Player, diterbitkan di Jepang pada tahun 2003, dengan cepat diadopsi pada perangkat NTT DoCoMo. Pada saat itu Flash Lite

Pemain telah membatasi interaktivitas, dan pengembang dapat menghasilkan hanya wallpaper, screensaver, dan sangat konten sederhana. Hari pengembang dapat menggunakan hampir semua fitur yang tersedia untuk versi desktop Flash Player konten mereka untuk perangkat selular. Flash Lite 2.1, versi terbaru, menawarkan banyak fitur baru. Salah satu yang terbaik - XMLSocket - adalah fitur dalam tutorial ini. Kelas yang mengimplementasikan klien XMLSocket soket yang memungkinkan berkomunikasi dengan Flash

remote server dan kemudian kembali ke Flash Lite klien lain. Tradisional sistem berbasis HTTP sering pendapat server dan download data baru dengan menggunakan permintaan HTTP. Sebaliknya, sebuah XMLSocket memelihara hubungan tersambung ke server, yang memungkinkan server segera mengirimkan data yang masuk tanpa permintaan dari klien.

Tutorial ini menggunakan contoh multi-user game, TicTacToe, permainan tradisional dimana pemain dapat tantangan satu sama lain.

Selengkapnya bisa anda download di Flash Lite: Multiplayer Game Example

Flash Media Server 3.5 And Flash Media Live Encoder 3.0 Released

Yes it's out, and this time I've double checked! Flash Media Server 3.5 is now available for download and purchase from the Adobe website.

This release mainly adds new features such as the new Dynamic Streaming, DVR functionality, HTTP delivery support, and H.264 enhancements. There are no changes in licensing or pricing. The editions also remains unchanged with the Flash Media Streaming Server (FMSS) taking care of your live and on-demand streaming needs while the Flash Media Interactive Server (FMIS) provides more complex features such as recording capabilities and Origin-Edge setups, as well as full support for server side scripting.
Of course you can also try the free Flash Media Development Server 3.5 and use all the features of FMIS up to a limit of 10 connections.

Download FMS 3.5 now.

Flash Media Live Encoder, Adobe's free live encoding tool for broadcasting live streams has also seen an update today, bringing it up to version 3.0. The major new feature here is the ability to encode multiple streams in multiple bitrates at once, publish them to FMS 3.5 and then make use of the Dynamic Streaming feature in a live setting. Pretty cool stuff.

You can download Flash Media Live Encoder 3.0 from this page.

PureMVC Skeleton App for FMS

t's a bit embarrassing to admit that it has taken me this long to post this app. I first spoke about it at my talk at MAX 2008 in Milan but then Christmas came and went and I got swamped with work... Apologies, but better late than never.

So what have we got here? My PureMVC Skeleton App is a simple Flex project that uses thePureMVC framework to give you a bit of a head start with your next FMS project. I'm by no means suggesting that this is the best way to build an FMS app but what I can say is that it works well for me. Not only that but since I've picked up PureMVC I have been able to build much larger projects than ever before, and the framework allows me to come back to an app months later and pick it up in no time at all. Everything has its place and it's easy to find your way around, and projects generally end up well maintained.
One thing I should point out is that the app itself has no UI - there's nothing to see when you compile it (hence the skeleton bit in its name). You will however see traces if you compile a debug project, or install Firebug for Firefox so you can see the Thunderbolt AS3 traces I tend to use extensively.

In order to connect to your own FMS application you first need to create it on FMS (mine is called pmvcskeleton) and then go into the ResourceBundleProxy and on line 42 add your corresponding RTMP string. I'm not sure if this is a good idea but I often use ResourceBundles for configuration options such as the RTMP string, I find it quite handy since they usually do not change so I just compile that in.

It helps if you are a bit familiar with FMS based applications and the MVC design pattern. For everything else check out the PureMVC website, it has tons of info and a lively community. Or why not sign up to my FlashMedia List, there's always a bunch of knowledgeable people there ready to help.

On this note I will leave you to it, take a look at the app and feel free to post a comment if anything isn't clear.

Massive thanks to Simon who gave me some excellent tips when I got stuck with certainPureMVC nags.

Download the project .zip here.

Flash Platform News from Flash on the Beach

As you may know I am spending the main part of this week at Flash on the Beach in Brighton. If you don't know what Flash on the Beach is, it's the biggest Flash (and Flex, AIR etc) conference in the UK, if not Europe. It's also the best conference of the whole year in my calendar. I presented my session on monday right after the keynote so I am now free to enjoy the conference fully. While attending some of the sessions I gathered a few interesting bits of information, some of which may not have been public knowledge before.

First of all I remember hearing that AIR is coming to mobile devices, which is cool, especially considering that AIR is ActionScript 3 only (outside HTML and JS and so on) so this is definitely one to watch. Another interesting note was that ActionScript 3 support will come to server side FMS, and while it was not mentioned when exactly this may be it was stated by the Flash Player Team that it was 'being worked on'. Nice, and FINALLY! The Red5 team is also working on this feature, and I am sure they'll have it added way earlier too. Lastly, it sounds as if the ball will soon be firmly be in Apple's court as far as Flash on the iPhone is concerned. The Flash Player Team 'is working on Flash support for the iPhone, and are doing the best job they can'. In the end however, the iPhone is a closed platform and it is up to Apple to decide if they want to 'allow' it or not. A lack of Flash on the device is definitely not down to Adobe not trying hard, and there don't seem to be any technical problems hindering it either, but rather it sounds like a question of politics on Apple's part. This is how read it. Adobe will also concentrate on other devices of course, and the iPhone is only one piece of the puzzle. The bottom line to be seems to be: the Flash Player for iPhone will be available sooner rather than later, but it's still down to Apple to ok it.

Anyway, that's it from me for now - the pace of this conference is relentless, in a good way.

Vendor Lock Out: Screen Sharing via the Flash Player and FMS

The following post has been sitting in my drafts folder for a while and I wasn't sure whether to publish or not. Today I decided I would, and it was after reading a very interesting article by Mike Slinn on InsideRIA. It talks about Adobe's lack of focus on its developer community, and how a shift in startegy may mean winning the RIA market for Adobe.

I'm always hesitant posting an article such as the one that follows as it will most likely be perceived as mainly negative by Adobe and its employees, many of which I know personally and rate very highly. I realise that there are people behind the software that this corporate behemoth churns out and it is for that reason that I'd like to say upfront that everything posted here has Adobe best interests in mind. I desperately want Adobe to succeed in the RIA market (and commonly they are doing a good job - but could do better...) and it is frustrating to see them making decisions that I think are not in their best long term interest.

One of my recent posts to the FlashMedia List seems to have struck a nerve when I asked if anyone there had tried out a Java application called JScrCap yet. According to its author, a developer can 'put this Java code on your web site as a Java applet and get browser-independent, platform-independent screen sharing solution with minimal installation efforts from end users'.

Due to the continued lack of screensharing support in publicly available editions of the Flash Player, this sounds like one of the best workarounds yet. It quickly became clear that there was a distinct vibe running throught the list, and that is was one of discontent with the way that Adobe is conducting business these days.

One poster noted (about JScrCap): "I can't get it to work... seems that FMS drops the connection as soon as publishing starts. I see the connect, but as soon as the FCPublish event hits the server, goodbye client. No messages in the logs.
That's what got me to wondering if FMS does that on purpose. JScrCap uses the screen codec, and I'm wondering if FMS is dropping the connection because the screen codec is reserved for Adobe Connect (my only reason for thinking that is the fact that so many other goodies are "reserved" for Adobe's use... I'd love to learn that the problem is me doing something wrong.
Charlie (aka the Wowza guy) said that it works with Wowza, so that leads me to think the problem is not JscrCap."

And more:
"Yeah... and I'm about fed up with the business rule restrictions Adobe has put in place. Were it not for concerns about the rtmp patent, I'd dump FMS and move to Wowza today. As much as I like FMS and programming AS on the server side, I'm running out of patience with Adobe. FMS is too f'ing expensive to have such a limitation."

Charlie was quick to point out that JScrCap works fine with Wowza. Adobe - are you listening? This link has more details. http://www.wowzamedia.com/forums/showthread.php?t=5328

It seems fairly obvious that FMS is blocking streams which utilize the screencodec (or at least they have an explanation for it... but that still means it's not there), a video codec that is highly optimised for screen capture and transmission. This codec is also used in Adobe's own collaboration platform, Connect. Within Connect - and this is my own experience - screensharing is one of the most heavily used features. I have yet to attend a Connect meeting in which the presenter would not share her screen, and I use Connect for that very reason. It's a KILLER feature for any real-time collaboration tool.

Another commenter on the list states that 'Adobe demonstrates a lack of vision with disallowing other services to interact with them'. Yet another one notes: "I've been waiting for screen sharing with FMS as well, for too long. Adobe, you are shooting yourself in the foot. FMS could be THE STANDARD, but bad business decisions are causing you to lose ground because you're trying to make money using outdated business models."

In fact the disgruntled posts just kept on coming: "I've got two FMIS seats to upgrade and at least one more to buy in the next
several weeks. Forgetting the money, their instransigience on the screen sharing has me ready to bolt. Makes me ill to be treated like this."

The whole thread made me realise that now would be a good time to give this topic one last shot, which is the reason I am writing this post now. I quite frankly cannot be bothered to fill in another feature request, or vote on existing ones, or indeed jump through hoops of any kind over this. This topic has hung over our heads for far too long, and maybe we can have an open discussion with some Adobe representatives over this. I'm not holding my breath though.

I understand the list members' view points all too well. Many of them can count themselves amongst the most long standing and loyal FMS developers (and dare I say Adobe supporters) within this small community, yet I do feel a real shift happening. I think it may be fair to say that some of us are starting to lose patience, and are getting more than fed up with what we perceive as business tactics on Adobe's part that are putting us at a disadvantage. There simply is no other logical reason that could explain the continued lack of screen sharing within the Flash Player in a form that is leveraged by Adobe Connect (and has been leveraged for years since the product was still known as Macromedia Breeze - we're going back roughly seven long years), a vital feature for any decent collaboration tool, as well as the incompatibility that several users have discovered when using encoders that utilize the screen codec. Not only is the most obvious piece, the Flash Player add-on, outside of our reach (and firmly within Adobe's) but the server that would happily support this codec out of the box is being sabotaged and a potential workaround is being denied. Actively denied that is. By Adobe. Yet at the same time Adobe is hard at work trying to attract developers to the Flash platform.

To complicate things even further, Adobe also would like to sell its Flash Collaboration Service (AFCS) to the masses. While AFCS has a lot to offer, I do wonder how it fits into Adobe's overall business strategy. On one hand we're being told that screen sharing is not a crucial feature (it's not present in AFCS), on the other hand we all know that the opposite is the case. Of course it's not all about this one feature, the question for me is where exactly is Adobe heading. Will they focus on selling me the tools I need to do my job, or are they potentially more interested in building products that are similar to the ones I'd like to build - using Adobe tools and servers? There's clearly a lot of overlap, and a real conflict of interests on Adobe's part. How can they push Connect and AFCS without stepping on the toes of FMS?

Adobe is clearly making some moves in the right direction, and I'm a big fan of most of their products. However it's time now to step up the game and be a lot bolder in their overall approach. Having a hard-core, forward-thinking and extremely loyal developer crowd behind them will their single best asset in a RIA market that's likely to hot up much more over the coming months and years. Adobe, we can't do it without your help, and you can't do it without ours. Up and to the right is where we'd all like to be. Let's make it happen.
You can help by voting for the screen sharing feature, as well as other related ones such asAcoustic Echo Cancellation (which is apparently a Connect-only feature also) and RTSP support.