- Mobile Devices.
- Data stored on the user computer/device in the form of a swf for local access later.
- It’s simpler to use. (loadMovie(); is pretty easy)
- Data is deserialized twice only as opposed to four times.
- You don’t have to learn a new API and can reuse your existing knowledge.
- It is useful in mobile applications with limited processing power
- The final downloadable bundles of SWX will contain everything you need to get up and running (you don’t need to buy or download additional tools).
I would really like to focus on the first two items because these have huge implications around what is now possible for mobile devices and for persistent data.
Mobile Devices
The Flash community has been in desperate need of a slim client that doesn’t require huge XML files and can be accessed using just Flash. SWX uses the loadMovie(); command, which we all know has been around since, “Availability: ActionScript 1.0; Flash Player 3″. How easy is that. All you have to do is load a swf into the mobile device and you automatically have all of your data. You access it just like a regular Flash object.
SWX isn’t bogged down by parsing XML and freezing the player while it does so. It is able to be used without heavy load on the processor or large files that have to be parsed. Aral has this to say, “SWX, by design, is the least processor intensive method possible since it is SWF bytecode and that’s as native as you get in Flash.”
Locally Stored Data
Storing Data in a swf is a great concept. It allows the main swf to read and access data from the server without the server load and multiple pings back and forth. I would love to see this concept explored further. It is like an intermediary data base on the users computer. I would imagine that with a little ingenuity and Aral Balkan like genius there could be a way to check if the file is loaded onto the users computer already and if so check a SharedObject for the reference to the local file and only access that swf. This would entirely alleviate the need for a connection after the first time the data is passed into the SWX. Obviously, this has many ramifications, but I would love to see it explored more.
Summary
Great concept, great implementation, and a great way to be more accessible for mobile devices. This is just the solution needed for getting a heavy data app to perform well on mobile devices. I am very excited to see the future of it.
SWX is a great idea.
Aral,
This is going to be great. We will be developing the mobile portion in Phase II of development and I can’t wait to try out SWX. We are going to be deploying in multiple languages and on multiple devices.
Let me know what I can do to help in the development. I am excited to hear what you come up with regarding the caching solution.
Thanks, Curtis! I’m working on a new release as we speak that should bring us interoperability with Amfphp and thus with existing service classes (as well as initial support for PHP objects, though not typed classes yet.)
I agree with you wholeheartedly that SWX is going to be very important for mobile work.
Regarding local storage, I added a feature recently (it’s definitely in the last release) where you can query the SWX gateway via GET and get the SWF back. You should be able to use this to manually generate SWFs for offline use (of course, there’s no reason you can’t automate this with a little CURL and either POST or GET.) A caching solution based on this might be an idea later on too perhaps.
Can’t wait to see what you build with SWX and thanks again for your encouragement and support! 🙂