Rien Verbrugghe has done a great job of cataloging a huge number of Flash Lite development, testing and packaging tips from a number of conference sessions and also the various Flash Lite development blogs. If you want a handy quick reference of Flash Lite development tricks and common gotchas this is worth book marking or printing out.
In my new position the team I have joined and me are carying out some in depth testing of an Action Script 2 code base for Flash Lite 3 using, among other things, ASUnit based unit and acceptance tests. The early stage of development means it is too soon to leverage the new automated testing features of Adobe Device Central CS4. One of the most important aspects of our testing has been to check memory use over the lifetime of the applications we are developing. We are interested in tracking any memory leaks in our code and also any memory space fragmentation as the Flash Lite player creates or destroys objects and classes.
This memory information is viewable from Adobe Device Central in the Memory Panel, where device central provides a graph showing memory usage over time, separating Static Heap and Dynamic Heap consumption of the player as your Flash Lite application runs.
Testing for memory use, loss and leaks is currently not present as standard in ASUnit for ActionScript 2. In order to include this form of testing at a basic level we have employed a trick I picked up at Max San Francisco this year (If you are the person that explained the trick, please leave a comment so I can credit you). The technique makes use of the FlashLite SharedObject as a way of measuring the file size of objects and classes before and after you think you have destroyed them in your code.
The premiss is a simple one. In your test as part of the test setup create a local SharedObject create an empty data property and save the SharedObject to disk, then call the SharedObject.getSize() method and store the size of your empty SharedObject. The code should look something like this.
// size variation threshold for the SharedObject
private static var SIZEVARIANCE:Number = 5;
private var iS:SharedObject;
private var iSSize:Number;
// standard ASUnit test setup
private function setUp():Void
instance = new TestableClassObject();
iS = SharedObject.getLocal("iS");
iS.data.iS = undefined;
iSSize = iS.getSize();
Some things to keep in mind are the following. The length of the SharedObject name and the length of the data property name will have an impact on the result of SharedObject.getSize(). In the above example I have limited both these values to 2 characters (‘iS’). All that remains is to link the value obtained from this setup function into a standard ASUnit test which looks something like this:
public function testDestroy():Void
iS.data.iS = instance;
assertTrue("testDestroy : test that the TestableClassObject 'instance' is destroyed successfully by checking size variation (" + SIZEVARIANCE + ") in SharedObject", ((iS.getSize() - iSSize) < SIZEVARIANCE));
In this test I am simply calling the target class instance’s destroy method, which should manage the removal of any stored references, arrays and object present in the class. I then save the locally stored instance back to the existing shared object, re-call SharedObject.getSize() and compare the size difference to the value of our initial empty SharedObject (iSSize) from the test setup method.
If the file size of the SharedObject is greater than the SIZEVARIANCE threshold then the test will fail. If that is the case then you have the ability to inspect the shared object using a SharedObject viewer (I use the free Solve by Darron Schall). In the viewer you will be able to see what items are not being properly removed from your class instance oronject. A common issue I have seen is the failure to destroy arrays that are prpperties of my classes for example. Some time over the holiday break I will put together a full example for download.
I missed this yesterday. Nokia have released the Flash Lite Flash Lite Developer’s Library 1.1 . One of the important aspects of this launch is the inclusion of documentation for using the new Nokia S60 Platform Services.
The Platform Services enable flash application to access Device Capabilities and services that were previously only possible through third party solutions Such as Kuneri lite.
The S60 platform allows Flash Lite applications installed on S60 mobile devices to:
- Access and launch applications on a device using the AppManager Service API
- Access and manage calendar information using the Calendar Service API
- Access and manage information about contacts using the Contacts Service API
- Access and manage information about landmarks using the Landmarks Service API
- Access device logging events using the Logging Service API
- Access device location information and perform location-based calculations using the Location Service API
- Access information about media files stored on a device using the Media Management Service API
- Send, retrieve, and manage messages such as SMS and MMS using the Messaging Service API
- Access data from the physical sensors of a device using the Sensor Service API
- Access and modify system information on a device using the SystemInfo Service API
These new API’s are supported through FlashLite 3.x on Series 60 5th edition devices. Flash Lite applications use the S60 Platform Services through Service APIs. The Service APIs are supported through a Nokia-proprietary ActionScript 2.0 library. Before you can create Flash Lite applications that use platform services, you must install the library for use in your Flash Lite applications.
Here is a run down of updates from the Change History section of the Flash Lite Developers Library.
Change history Flash Lite Developer’s Library 1.1
- Added information on the S60 Platform Services, the corresponding ActionScript Service APIs, and the ActionScript Service object required to access the APIs.
- Added section “Flash Lite API reference”. This section describes the ActionScript APIs provided by the S60 platform for use with Flash Lite applications.
- Added section “Flash Lite authoring and optimization tips”. This section provides tips and guidelines for authoring Flash Lite applications and optimizing their performance.
- Added section “Flash Lite with S60 touch”. This section briefly introduces the touch UI and Flash Lite touch keypad of S60 5th Edition devices and provides instructions for disabling the touch keypad.
- Added section “Flash Lite example applications”. This section contains links to example Flash Lite applications that you can download to your computer and then to a mobile device or emulator.
With Adobe Max San Francisco now only 2 weeks away its important to make sure you have organized your schedule, if you haven’t already. This year Adobe hosting 2 events which aim to bring developers together with some of the industry leaders in the mobile market place. So if you are a developer interested in mobile or you already have content or existing applications that you think might work as a mobile application or service, Adobe Max should offer some great opportunities to get information from the experts.
November 16, 2008 at the Marriott from 1pm-6pm
Join Adobe and our partners — Nokia, Qualcomm®, Verizon, Sony Ericsson, GetJar, Thumbplay®, and Zed — to learn about new opportunities for mobile developers this year. Get a sneak peak at what you will see and hear at MAX before anyone else does! Hear from Adobe partners and key industry players as they present the newest mobile solutions, technologies, and distribution opportunities for mobile developers. To learn more and RSVP for this event go to: http://www.eventsadobe.com/mobilesummitmax08/invite.html
Mobile Fast Pitch Networking Party
November 19, 2008 at the Thirsty Bear from 6:16pm-9:30pm
Adobe is hosting a special Mobile Networking Party to allow developers to showcase their mobile applications using our Adobe® Flash® mobile technologies. If you already have a web-based application and are thinking of going mobile, you can also present your idea and get feedback from our industry leaders. Join us to support fellow developers or to present your ideas. For more RSVP and presentation information for this event go to: http://www.eventsadobe.com/mobilenetworkingparty/invite.html
In addition to these 2 events there are also a number of great sessions on at the conference tailored to Mobile:
- Open Screen Project: Delivering Rich Internet Experiences Across Devices
- Creating Mobile Applications: A Real-World Example
- Mobile Workflows with Creative Suite® 4 and Adobe Device Central CS4
- Flash Lite 3: Learn How to Package and Distribute Mobile Content
- Spotlight on Finetune and Teknision™: Building a Multiscreen Application
- Create Unique Browsing Experiences on Nokia Phones
- How to Build a Mobile Business
- Developing the Ultimate Flash Cast™ Channels
- Project Capuchin – Bridging Adobe Flash Lite and Java ME™
Remember the most popular MAX sessions fill very early, so be sure to register today to secure seats in your preferred sessions. You’ll be surprised by what real live Adobe Flash Lite applications exist today.
Headline Numbers for this update:
261 profiles included
57 new devices
updates to 204 existing profiles
In total that makes 525 device profiles for you to create content with
I you are a Flash developer producing mobile content for Flash Lite then this week end you really hit pay dirt. First Nokia announced a set of Components for Flash Lite 2. Next Adobe also release a set of Components, for use with Flash Lite 1 and also Flash Lite 2, courtesy of Mark Doherty. Finally Scott Janousek resurrected the google code links for Shuriken, a set of open source Flash Lite2 components from last year.
So with all these ‘new’ flash lite components available what can you expect from each component set?
Nokia Flash Lite 2 Components
Nokia have provided their Flash Lite 2 Component set as an MXP file for simple installation into Flash CS3, the components are easily accessible from the components panel once the MXP has been installed. Included in the zip file you download is a full readme.txt explaining how to install the MXP file through Adobe Extension Manager. The components also include full usage instructions in the form of flash help files and usage examples. Flash Lite Components that are included in the distribution are:
- Signal Level display, including network generation.
- Battery level display.
- Dynamic List Component.
The Signal and Battery indicator components react to softkey placement/screen orientation. All three of the components have easily accessible skin components in the library, and also allow limited visual control from the properties panel. Mark Doherty noted that the components appear to be quite memory hungry. The Signal and Battery Indicators seem to use in the region of 600k according to Adobe Device Central, the Dynamic List Example reports around 800k although the actual memory usage of the list without a demo data set is closer to 700k.
Adobe Flash Lite 1 & 2 Components and UI Examples
Over at flashmobileblog Mark Doherty has released some UI components as well. These are provided for both Flash Lite 1 and Flash Lite 2 projects. There is limited documentations for the examples, the Flash Lite 2 examples look like they should be easy to integrate as long as you intend to use them ‘as is’ in this case they would simply require the addition of key listeners to control them. If you needed the components to be used in a more dynamic fashion, there would probably be some work to do. Included in the Flash Lite 2 component examples are:
- List, this offers similar functionality to the Dynamic list in the Nokia Component set.
- Slider, This offers a horizontally scrolling icon menu.
- Gapper, This is a vertical variation of the slider.
- TileGrid, Shows a gridded icon menu with scrolling screen control.
- NavModel, this demonstrates a full application screen control system, also included are working Signal and Battery indicators and a list components.
The examples in this file are certainly easy on the memory, all of them use less than 500k, this is particularly impressive of the Nav Model example given the amount of interactivity and feedback that is demonstrated.
As with any Flash Lite 1 work, making use of the earlier versions will be a little more fiddly than the Flash Lite 2 counter parts. But the code in each of the examples is clearly identified and if you know your way around ActionScript 1 you should find incorporating the ‘components’ easy enough. Included in the examples are the following Flash Lite 1.1 components.
- Carousel, A full screen horizontal slider.
- Displays, demonstrates the various device stats you can access from Flash Lite 1, also included are battery and signal indicators.
- IconMenu, offers a FlashLite 1 version of the Slider component in the Flash Lite 2 set, this is similar to the functionality produced in the tutorial here.
- Menu, actually seems to be a Flash Lite 2 example, an alternative dynamic list example.
- Story, This is an example of scrolling text in flash Lite 1, similar to the scrolling text component I have released.
Agin the Flash Lite 11 components are very efficient when it comes to memory usage. None used more than 400k when published, and most were below 300k. The trade of with both these example sets from Adobe seem to be the slight increase in the amount of work you would need to do to integrate them. The other thing to note, is that these examples do offer examples of far more compelling UI methods than simple lists.
Shuriken Open Source Flash Lite 2 Components
The last set of Flash Lite components are those that
While the examples are good they do seem to be quite heavy in terms of memory usage, and they are not without issues. The scrolling list example for instance takes around 700k to display, but more concerning is that this memory usage raises during operation, implying the component has a memory leak somewhere. The complexity of this initiative while making development easier, may be its problem. Complex class structures in Flash Lite tend to give rise to cross references and memory leaks quite quickly.
So there we have it 3 sets of components, all certainly have there advantages and disadvantages. The Nokia Flash Lite components are great for Plug and Play development, I would say the Adobe UI examples are great for producing engaging canned demos as they stand, but with a bit of work could be converted for very memory efficient project use, and the shuriken component frame work may be a little heavy at the moment, but keep a watch on them, they could certainly offer a great, familiar framework for Flash Lite development, when they can solve the memory issues.
Also worth a note is that Mark Doherty has put a shout out at the end of his post regarding a shelved component framework that he could release from Adobe if interest is great enough. Mark has asked the FlashLite comunity to provide some support if it were released, to document and update the project, but this could offer a great opertunity to unify the current state of disperate component solutions emerging.
Credit where its due:
Following the announcement from Adobe of the open screen project, news comes from the Embedded Systems Expo that NEC is showing what sounds like it might be an alternative to Adobe’s Flash Lite Player.
Its a little hard to make complete sense of the post from EETimes.com. But some interesting quotes from the short, slightly cryptic article:
By using our new IP, one can design a portable device capable of processing Adobe Flash Lite several times faster, when compared with using a processor.
Also in the announcement is a hint of better video quality as well.
After reducing the number of gates required for an IC and further tuning the video quality output by Adobe Flash Lite, NEC will start offering its IP in August this year.
One thing that does seem to be missing is an explanation of which Flash Lite version they are supporting, although the mention of video implies this is based around the FlashLite 3 player.
One further interesting thing is that I could find no mention of NEC being involved with the Open Screen Project from its press release.
Credit where its due: EETimes.com
Keeping with the algebraic/code functions as titles from my Last post I thought I would put some thoughts down regarding the news from Adobe earlier this week of their Open Screen Project (OSP). Anyone working in the Web/Internet industry at the moment will be well aware of the Rich Internet/Interactive Application (RIA) moniker. What Adobe is committing to is much larger though this is about true cross platform convergence. Its about Rich Anywhere Applications (RAA) or Rich Everywhere Applications (REA) if you will. You see what I did there 😉 .
Interestingly this is a concept I began to scratched the surface of with my presentation at Flash On the Beach Last Year, and over the last few months has been a subject I have continued to keep close to hand both in my day job and my personal development projects. At the moment the Flash Player Fragmentation offers a considerable challenge to any developer wanting to design and or develop for multiple devices and multiple screens.
Articles like the one posted over at ADC on adaptive screen layouts offer a great foot up. But before we get to visual display we need to know what player version we are targeting. And to do that, we have to hit the time machine button and roll back all the way to Flash 4…..
This just popped into my news reader from ZDNet.
Well, you really believe that Flash is synonymous with the internet and frankly, anybody who wants to browse the web and experience the web’s glory really needs Flash support. We were very excited about the announcement from Windows Mobile, adoption of Flash on their devices and the fact that we’ve shipped 0.5 billion devices now, non-PC devices. So we are also committed to bringing the Flash experience to the iPhone and we will work with Apple. We’ve evaluated the SDK, we can now start to develop the Flash player ourselves and we think it benefits our joint customers. So we want to work with Apple to bring that capability to the device.
If the mountain wont move to you..
More exciting news on the future of FlashLite 3 proliferation. Bill Perry has a great explanation of how the news that Microsoft has licensed Flash Lite 3 and Reader LE for future Windows Mobile based devices will affect FlashLite 3 content developers.
Recently I have been involved in some FlashLite 1.1 development that requires a certain level of online data interaction. With memory being at a premium on Mobile devices I have been spending many a spare moment looking at efficient data transfer methods.
Stepping back into FlashLite 1.1 (flash 4/5) scripting has been a nostalgic experience. The halcyon days of ActionScript 0/1 were where I broke my teeth, so to speak, on flash. It has been an eye opener also to return to using Perl as well in order to format data efficiently for consumption in my simple FlashLite 1.1 applications.
In these days of XML, SOAP, SQL, and huge component frameworks, it has been nice to go back the the “demo days” of flash and try and eak every byte out of my data format. Remember of course, no XML or SWX support in FlashLite 1.1.
So what have i been playing with? How about a Live London Tube Status FlashLite 1.1 application?
FOTB 07. What can I say. Incredible. First off let me say a very big thank you to John Davey. John did a great job, I can only guess the amount of organization involved in Flash on the beach, the speaker list and session line up were brilliant, and the shwag was top draw, both for attendees and speakers. It was a pleasure and an honor to have the chance to be involved in a presenting capacity. Thank you for inviting me John.
At the event I presented a session that discussed the issues of Localisation, and to a lesser extent my new love, Mobilisation. This was my first time presenting at a larger event like this. Certainly I was nervous, and I am sure that there were tell tale cracks in my voice a few times as I went through my slides. As I got in to the flow of the presentation I think I settled in a little.
I did have a slight issue with timing, which meant I rushed the last few slides, unfortunately, as a result I had to drop one of the examples. It also meant that I missed the opportunity to ask questions of the people that attended if they had any. So my apologies there.
Any way below is the link to my speakers notes, and also the examples from my session on Localisation.
Flash on the Beach 07 Localisation Presentation Files
On a related note I have uploaded to Flickr a few of the images my little lomo camera captured of the event. You can see them over on my Flickr stream
Following on from the simple BatteryBroadcaster class posted last week I have put together a second helper class for FlashLite, again built in ActionScript 2, so it should work for any FlashLite 2 or FlashLite 3 project. The NetworkBroadcaster class centralises all network and signal related events, and broadcasts any changes to listeners on 2 separate intervals. One for general signal levels, the other for “other” network status events, for example changes in network generation support.
Continue reading FlashLite Helper Classes for Download. Pt 2. NetworkBroadcaster
Along with the news of updates for CS3 and Device Central to support FlashLite 3 Authoring from within the CS 3 suite of products. The FlashLite product website has a side by side comparison of various Flash player specifications that are currently being used in Mobiles and other devices.
see the Flash Version Comparison Chart
Some Points of interest for me were the following:
- The FlashLite 3 player is actually smaller than the FlashLite 2.1 player
- The minimum memory requirements for the FlashLite 3 player is un-altered
- The recommended memory is un-altered for for the FlashLite 3 Player
- There is no improvement in the worst case memory usage of FlashLite 3 content over FlashLite 2.1
- Added support for meta data in FlashLite 3 Content
Also I see that the FlashLite 3 player has “External API for browser scripting”, assuming there is a mechanism to update the players within device web browsers this may well offer a clean interface for the detection of screen orientation I have been experimenting with lately.
Another interesting point FlashLite 2.1 and FlashLite 3 seem to both offer support for “Complex languages (Thai, Arabic, Hebrew, etc.)”. Yet this is still not supported by the desktop player? Yet.
Following the press release announcing FlashLite 3 I proceeded to do some more digging. Wondering how I can start producing this new fangled FlashLite 3 Content, I followed some links through from the new Nokia Mobile Developers Site mentioned in the previous post and found new downloads for updates to Flash CS3 and Device Central at the Adobe Developer Connection Web Site
Adobe have posted a press release today, it seems that they announced the release of FlashLite 3 at Max in Chicago. Included in the release is the well know news from a previous press release that the new Mobile FlashLite player will support the Flash Streaming Video Format .FLV.
Also mentioned in the release is the news the new “community for creative professional” from Nokia. This looks like it could offer a great resource for developers looking to deploy to mobile handsets, and devices.
The Full Press Release can be Found on the Adobe press release site.
The full press release from Nokia covering their support for FlashLite 3 can be found on the Nokia Press Release Site:
Bill Perry has posted a very interesting presentation, the subject is Creating and Selling Your Mobile Flash Content. You can down load the presentation from Bills Site.
I also noticed Bill has a document linked at the very top of his site, under the banner “Addressable devices for developers“.
Following my initial post last night detailing some of the player information of the FlashLite 2 support in the N95 web browser, and also one of the issues. I thought I would take a quick look at the files from last night with fresh eyes over lunch. I have included a couple of screen shots to show the rotate issue more clearly. The page that is in these screen shots is at the following location.
In the file I am simply reporting to screen the Player version, the stage width and height, and then also loadin an image thumbnail from my new gallery of animal themed photography
The bottom 2 fields are reporting the FlashLite players
In the first screen the FlashLite movie from this URL loads has loaded in the Vertical page format at a resolution of 240×320 (wxh).
In the second screen shot below the browser has been rotated into its horizontal format. This operation does not seem to cause the
Stage.onResize event to fire, and the flash movie still reports a resolution of 240×320 (wxh).
A side effect of this rotation of the flash movie is that it seems to get scaled down in order to view it in the new format. This means the text becomes unreadable. Very frustrating.
I took delivery of a new Nokia 95 a few days ago, and I must confess I am very, very happy. One thing that attracted me to the device was the IN BROWSER FlashLite 2 support, this offers a way to build web experiences into the browser that owners of the new Nokia smartphone will be see. Of course this Assumes that the developers of the content stick to the usual limitations of developing for FlashLite, and other limited performance devices.
So I have spent a little time getting to the usual nitty gritty that us flash developers require in order to produce to the Nokia N95. I.E.
The FlashLite Player on the N95 reports the following from the
When using html that sets the swf files width and height to 100% I get the following information from the N95 browser.
Stage.width == 240
Stage.height == 320
Here comes the but……
When I make use of the rotate screen functionality that the N95 offers to view the SWF in landscape format, and measure the width and height. I get the following.
Stage.width == 240
Stage.height == 320
I extended my movie to make use of the
Stage.onResize event. But at no point could I see that event fire through my event handler. As a result I have not been able to see the expected result in landscape format of
Stage.width == 320
Stage.height == 240
Maybe I have made a simple mistake.
The N95 does seem to be a very capable device. The battery is pretty short lived, but the functionality it offers is great. From a development point of view I will be looking to see what I can do in the Browser and out, It would be wonderful if the Browser offers FlashLite 3 once that is available, maybe a later firmware patch. We shall see.
my first example is (very basic) available to view at this location. bittube.com/flashlitehome/index.html
I will package the source, what there is and post it later on.
Let me state first off that I haven’t yet had a chance to play with SWX yet. However I was at LFPUG when Aral gave his talk and announced his ‘new born baby’, and I have to say I sat with a broad smile and a warm feeling inside as Aral presented and finally demonstrated SWX. You see it really did seem to hark back to a more innocent by gone era from of flash. Back to when people saw a perceived problem and attacked it with the tools and techniques they had to hand.
Aral himself voiced his concern over the loss of ‘go at it’ attitude within flash development as it has evolved. In part due to the ‘rule of the rod’ attitude of insisting on Frameworks, Patterns, and Object Oriented development practices. It was truly refreshing to see a developer express sheer glee at returning to a hex editor to decipher the .SWF format with one single goal in mind.
Reading some of the responses to this project has also bought a smile to my face. This time not for particularly good reasons. Its plain to see there seems to be some issue with the ‘raw’ approach that Aral has taken to accomplish his goal. Some quotes that stick out for me revolve around the ‘Hacky’ nature of the solution Aral has produced. The use of
onEnterFrame as a polling device, or the use of
loadMovie as a transfer system. But why should this be a problem? Aren’t they there to be used?
The current ActionScript 2 standard is where it is now as a result of just such work arounds and hacks. Thank you very much. Dig deep enough into some of the ActionScript 2 classes and you will find not only hacks like this, but in some cases, what you might consider worse ones. In
mx.Transitions package for example we find the
OnEnterFrameBeacon a class that not only makes use of
onEnterFrame, but also a
MovieClip that is created to a ‘Magic Number’ based depth? There are I am sure any number of other examples.
Flash is where it is today to any number of early flash developers working with very limited action script and coming up with work arounds and hacks to get it to accomplish the myriads of solutions we are now fortunate enough to be able to develop now. Remember ‘jump movies’ or __proto__ or storing sine tables to do 3d? Before PaperVision. No amount of Java development sensibility is going to change that to quickly.
Even with all this wonderful ActionScript 2 Object Oriented (?) loveliness, developers every day are finding they have to go back to the oldskool to get there applications to work. Flash hacks still have a huge level of relevance today, for the simple reason people are still finding things they want to do in flash that they cant do any other way. Flash Lite, Accessibility and Localization are some pretty good starters that still require copious amounts of hacking at times.
For those of you that are developing Flash Lite applications and games you will be well aware of the issues of Memory leaks in the Flash lite player. One area where this can occur is in the creation of “crossed references”. These result in objects that are effectively locked as far as Garbage Collection is concerned, and so result in memory ‘leaking’ over time.
As Mike over at Flashgen.com and also Aral Balkan reports it seems someone is looking to contest the ridiculous Balthaser RIA patent that was reported a while ago by a number of Flash developers. I have also been contacted by Oliver Lorenz with regard to providing more information and certainly urge anyone that wants to beable to continue RIA development without the potential of infringing on this patent.
The issue I have with the patent is its broad and sweeping coverage of very common interface and application GUI design systems. As an example reading one portion of the “Summary of The Invention”.
When editing a component, the user may modify a number of features associated with a component including, but not limited to, the volume of an acoustic component, the link between a menu entry and an associated component, the font, font size, color, or effect of a text field, or the layout, size, transparency, rotation, color, position, or level of any graphical rich-media component. The user may modify these components by means of a slider bar or a textual input field. In addition, the user may modify the volume of a sound component by means of up and down volume buttons. The user may undo modifications made to a component’s parameters. The user may also modify the position of a graphical rich-media component by a graphical input field, by clicking and dragging said component, or by text fields. When the user modifies the position of a graphical rich-media component by means of clicking and dragging said component, said component may align itself to a grid point or a guide line. The user may also modify the style and the Uniform Resource Locator (URL) of a component linked to a menu entry.
Unless I am mistaken the recently posted link to Netvibes would actually infringe on this part of the patent. In that the user can select ‘panes’ or ‘graphical rich-media components’ of the netvibes application and alter there position within the application by clicking and dragging them to a new position.
In this example, because there is no specific technology linked to the patent claim, any RIA in any technology, Flash, Ajax, Appolo, XUL Runner, HaXe, Sparkle, add any other future technology here….. These systems would all be in break of the patent claim.
And this is just ONE of the EIGHTY THREE different claims in this patent.
Very worrying I think any developer would agree. Everyone involved in Internet application development, in my opinion, should take a serious look at this patent. Think about ANY work they have done or seen in past. The work they are doing today. Then consider the possible implications of future networked development. If you know of anything that has been posted, exhibited or shown publicly that can bring this patent down, it is in every ones interest to make it known to strengthen the Magix reexamination.
And remember we are not just talking about flash applications or work here. If you remember or are aware of ANY online application, in any technology, be it DHTML, Director, Java or anything else. If it used any, all or even one of these systems to allow user interation then it may well be enough to show that Mr Neil Balthaser did not invent these systems, and certainly has not right to lay claim to doing so as he has in his patent application.
It all started at university. Microsoft or MSN Australia I think it was, that was the first ‘flash’ movie I saw. And it changed everything I had seen on the web until then. Of course unlike everything else on the web at that time there was no way to see how they had done it. Or at least you would think 😉 . A few moments in a hex editor to remove those pesky 10th and 11th bytes, if memory serves, that was the ‘copy protection’ and we were off and de-compiling, perhaps the first flash de-compiler was actually UltraEdit? 😀
As you will have seen Mike Jones (FlashGen.com) and I are meeting to take notes, share war stories and generally reminisce the ‘Good OldSkool Days’. To find out what files we still have, and even which URLs are still live (Flash 3 (alpha) circa 1997/8 btw JD produced by Spooky & the Bandit – you may remember them :p)
Keep your eyes peal for more news as events unfold….
So over the long weekend I spent some more time plugging away on the PSP version of my portfolio site. And despite my best efforts I have stumbled on an issue that continues to upset the PSP version of the flash playerï¿½s limited memory.
First a little background to the site. The first version of the site was a journey into a completely code generated flash movie. That is to say, every possible aspect would be generated using ActionScript 2. The rational being to learn some more about the Draw API and also get clarify the ideas of OOP and MVC that i had heard so much about all over the web, but had yet to apply to flash properly. That first development has also offered a great focus for development in terms of learning Flash 8 and more recently both Flash 9 or Action Script 3 and now this latest version for the PSP version of the flash player.