OK, I've had enough. I've been reading this whole Apple vs. Adobe thing for months. I have my own strong opinions and they probably suck just as much as yours. And yours. And yours. So I won't bore you guys with my opinions. I am, however, just plain irritated over the whole thing. This crap shouldn't be happening. It's like two 14 year olds in an IRC chatroom arguing.
Mark Aplet and I were "discussing" the issue earlier and I mentioned a potential solution. He thought I should share this with Mr. Jobs, but unfortunatelty I'm job hunting at the moment so I just can't take the time out of my schedule to meet with him.
Now, before I outline my solution, let me just say that the only Apple product I own that I currently use is an iPod Shuffle. It's pretty awesome. I think Apple makes great hardware, and OS X seems like a decent OS. I don't use them for my own reasons, but I'm not a hater of their products, by any means. I do have an interest in the debate because I want the solutions I develop to work on all platforms. If I am working with HTML 5 in two years, so be it. I am fine with that. I love technology because it is ever changing and I love learning. But I think there's a solution to this problem which provides benefit to everyone.
Why not just create an "Apple Platform Certification" program? If a vendor, any vendor, wants to have a runtime on the Apple platform, be it iPhone, iPad or OS X, have the runtime/language/platform be certified through Apple before it is accepted. This provides two benefits:
- Apple can guarantee that the platform runs acceptably on their platform.
- Users can be sure that their experience will not suffer due to third party code.
How would this certification program work?
- Apple must provide a public certification guideline that vendors must be able to pass
- Apple can provide support to vendors to become certified. Vendors must pay Apple for this support
- Apple provides testing tools to the vendors to test their product for certification before submitting to Apple for certification. Vendor pays a fee for these tools?
- Vendors submit runtimes/platforms to Apple for certification.
- If the vendor is certified, the must maintain certification with each new major version they release
- If the vendor fails certification they can continue to pay Apple for certification support and resubmit for certification until they are able to pass the process.
- There would need to be special certification process for open source platforms. This could be provided for free by Apple to show goodwill.
Now, I am not saying this is a perfect solution, nor am I saying it is complete. What I am saying is that maybe this can be the basis for further discussions on a solution to the issue rather than inflamed and emotional arguments on the topic. This doesn't just address the Apple vs Adobe issue. it addresses the Silverlight issue and any other potential runtimes or platforms (Java?) that represent issues for the Apple ecosystem.
Do you have any other potential solutions?
Flex, Flash & AS3
The source code and demo app for this article are linked at the bottom of the post.
I'm a slacker, I admit it. When Flex 4 SDK beta was released at the end of 2008, I gave it a whirl and built a small app. I found the learning curve a bit steep for me at the time, with everything else I had going on. The SDK was also changing a lot and I didn't feel I had the time or energy to keep up the pace.
Last week I decided to finally give the SDK a new try. I am building a new AIR app and wanted an interface similar to Windows, where a user could have multiple "mini-apps" open at the same time and manage these much like a Windows session. I felt it was a perfect opportunity to leverage Flex 4 and AIR 1.5.
At first, getting up to speed was a bit rough. Certainly, Flex 4 is a shift in thinking. One can be lazy and leverage the Halo component set. However, it was my goal to use Spark almost entirely for the project. I had two reasons for this: 1. I want to get up to speed with Spark as fast as possible. 2. I wanted to take advantage of the enhanced skinning and performance of the Spark components.
The most frustrating aspect of this was the lack of documentation. There are beta docs, but they are not up to date and I constantly found myself trying to use properties that no longer existed. I also found a number of blog posts and tutorials. Many of these were very helpful, but since the SDK changed considerably through the beta some of the info was also out of date. I have to thank Simeon Bateman for his work on the "Title Window", I borrowed heavily from this for my own panels. Thanks Simeon!
I'm really liking the new SDK. It feels right. I feel like I have complete control over my skin, and I really feel like it's forcing me to better application architecture. Also, although I haven't had the time to really profile the app, it feels more responsive and more performant. I'm really looking forward to doing a lot more Flex 4 work.
Im posting the code and the demo AIR file for anyone to use. I'll explain a few things, so you can get a feel for what's up:
- The app requires the Swiz framework: http://swizframework.org/
- The menu system is built using two collections: systemMenuItems and programMenuItems. New menu options can be added in the com.funmappr.model.StartMenuModel.
- StartMenuModel creates menu arrays from MenuItem model, which allows you to configure window options. The intent is to eventually have the system use these options to know what to insert into the panel contents.
- Window options should be self explanatory, but basically you can do the following: Set how many instances of a window can be open, set the dimensions of a window, set window title, provide icon for menu item, sort order (not yet implemented), set if window is resizable.
- This is very proof of concept. I will be adding in new functionality over time, but I am not sure I will be sharing those versions. Essentially, this package is licensed under Apache 2.0. If you want to make changes to it, feel free. If you use my work, please give me credit.
- I don't provide support (unless you want to pay my rate!), but I'll be happy to answer questions as I have time.
Source - App
Flex, Flash & AS3
At work we use Surround SCM for versioning and Test Track Pro as our ticketing solution. Because of some of the limitations of these tools, I am writing a business case to transition to other tools and build processes. What I'd like is to hear how other folks out there are setup. If you have a few moments, I'd love it if you jotted down answers to the following:
- What is your source control management server?
- What is your ticketing system?
- Provide a high level overview of your build process
- How do you push from testing to staging to production, ensuring your build is consistent?
- What other tools do you use in your process to assist in the build, or make things easier?
- How large is your team?
- What types of projects do you work on?
- Does your development staff work on multiple projects at the same time?
- Do you enforce unit and integration testing?
- What project management process is your company using (agile, waterfall, etc)?
- What challenges have you encountered, and how have you overcome them?
If you have any other thoughts I'd love to hear them. Although I am biased (because I've used JIRA, SVN and Mylyn in the past), I am still trying to provide an objective and unbiased business case. I've jotted down some of the issues we've encountered using Surround SCM. If you use Surround and are aware of how to overcome the limitations we have experienced, please let me know!
- No automated changelists
- No workflow/IDE integration that is reliable or
performant. The Eclipse plugins provided by SeaPine are notably pretty bad and this is the general consensus in our shop.
- Surround cannot move/delete files on
- Surround is terrible at merging changes for XML files
- Merging requires a lot of time if there are other developers working with the same codebase
- The automated merging process is inaccurate, and requires
more hands-on work than other common tools
- Using Surround remotely is clunky and slow.
I certainly appreciate any feedback you can provide.
Also, I have enabled comment moderation on the blog to help stem the flow of spam. I'll definitely approve your comments quickly!
Process & Tooling
In this post we are going to examine the ins and outs of Runtime Shared
Libraries. Runtime Shared Libraries (RSLs) are compiled libraries of
code that allow you to cache functionality into the browser or Flash
Player. One of the most common uses of RSLs are the Framework RSLs
included in the Flex Framework, used to cache the Flex Framework. This
can potentially speed load times. These Framework RSLs are the topic of
[Read more →]
Flex, Flash & AS3
Some of you may know that I blogged at phusor.com in the past. At the time, I felt like a large part of the posts I read on other blogs were either very repetitive or that the information was based mainly on opinion rather than facts. This made me examine my own posts, and I realized I was guilty of the same. Because of this, I quit blogging. That was about two years ago.
Recently I have started learning a lot of new technologies, meeting a number of cool people, and am also preparing to launch a project of my own. I have also started creating plugins for various open source projects. I feel this gives me a lot to talk about. I've also had a number of peers and friends ask me to start blogging again. After some consideration, I decided to give it another try.
I can't promise you I'll blog frequently. I have a terrible commute, I work long hours, I work on my own projects and have to keep some semblance of a personal life. In other words, I'm a lot like you. Thanks for those who encouraged me to start blogging again, and to you for coming to my site and using your valuable time to read my 2¢.