Adobe Apollo: Astra in the AIR.
So we spent Monday and Tuesday playing with the public alpha of Adobe’s new Apollo technology and now have Astra working with it. This is technology similar in what it ultimately provides to the user as our in-house “OS Layer” code. Apollo, in a nutshell, allows a piece of Flash code to run natively on your operating system as an actual application with its own taskbar entry and native OS feel. It also supports Windows and OSX.
The Good
- Immediate support for Win32 and OSX; future support mentioned for Linux and mobile devices.
- Good memory footprint and CPU usage.
- Easily snapped into an existing Flex project (which we were not using previously, and had to learn).
- Multiple window support.
- Easy installation.
The Bad
- We don’t control the underlying technology, so are limited to providing only the functionality that Adobe chooses to expose. For example, in the current build, we have no systray icon support, no docking support, and are unable, outside of filesystem access, to communicate with other non-Apollo applications using standard OS mechanisms such as a window handle or COM.
- Due to what we believe is related to an existing Flash transparency problem (which we have since received confirmation from Adobe about), TextField objects in Apollo lose their ClearType setting. We hope this is fixed eventually now that Adobe’s own product lines depend on it.
- Requires an actual installer download and permanent installation process – the Apollo application exists in your Add/Remove programs listing and takes its own directory on your computer. This was not what we had hoped for, and tends to create an ambiguous installation environment for an existing Trillian/Win32 user.
- A somewhat large runtime; our OS Layer plugin is 84K, as it barely does anything – in comparison, Apollo is a few megabytes.
Ultimately, the “Good” points for Apollo are very strong and outweigh the bad, in our opinion; it’s a non-trivial operation to get your application to run natively on OSX, but fixing a weird font transparency issue or adding systray icon support can easily come in time. Our biggest concern at this point is the ambiguity that we’d introduce by providing Trillian users two ways to install the same application, one of which was the obvious weaker offering (no plugins, less preferences, etc). If Trillian Astra itself is able to store most of your data server-side to ensure full client mobility, and we can keep the main installer reasonably lightweight, what’s the point of installing something else? This is our current thinking, anyhow. We’ll continue to evaluate the technology as we move forward and figure out what makes the most sense for our customers.
March 21st, 2007 at 11:14 am
I must admit this is interesting, but I still think that the vast majority of OSX users will continue to use iChat or AdiumX when you consider (as you mentioned) that this is essentially a “lite” version of Trillian which is lacking some of the important features that make Trillian so powerful.
Apollo looks quite impressive, I think I’ll have to spend some serious time working with it this summer.
March 21st, 2007 at 11:18 am
Yeah, that’s definitely our concern too. The trick is to find the balance between the implied “convenience” of the app and the lack of full-scale functionality. The other consideration is that alot of people end up just using basic IM features anyways, so at the very least we have an immediate “semi-native” OSX port.
March 21st, 2007 at 11:36 am
I think what desmus mentioned is true on basis, after all this “lite” version of astra is meant to be exactly that.
I don’t think its reasonable to expect a fully functional duplicate of the main program through technologies like this, especially if you want it working on various bandwidths across the world (which I believe is the aim of this “lite” version? Access anywhere at any time?).
I think if you want complete control over your web app, it’s better to stick with in-house technology, but of course its all about getting the balance between development time of this “lite” version and the full blown program, the main advantage of using someone elses technology is that generally the hardest work is done for you (without taking into consideration learning the API of Apollo)…
I generally believe however, you should do what you feel safest with, maybe at first release a version based on apollo, then when astra is released work further on an in-house one that works the way you want it to? I think people would be happy with an apollo based version, but then again I may be wrong?
Keep up the good work.
March 21st, 2007 at 11:40 am
Aside from the mentioned benifits of using Apollo you have the added benifit some pooled code may then be possible between the web version and the ‘desktop lite’ version. I do however think the point about requiring an install is a very good one. If ‘desktop lite’ is something of a work or on the run type application then requiring install rights is a harsh requirement. Even trillian is able to run without requiring administrative privileges so requiring more rights to install the lite version seems quite counter productive.
If the current runtime is something that can be just downloaded and run without admin requirements then I think it has a great benifit over the Apollo for the target market. If the target market however is really towards porting to OSX and Mac this might be a bit different.
Finally I think its a great point that you are limited to adobe’s requirements, and if you find some really cool tie you would like to do in OSX they don’t support or something like that you are SOL with Adobe obviously.
March 21st, 2007 at 11:46 am
So long as it isn’t a resource hog, i’m happy.
March 21st, 2007 at 12:01 pm
Looks really cool, but to be totally honest I will always use AdiumX on my mac. It is the best solution for any mac user.
I may have to give it a try if it is something Trillian Astra will have, but I can’t say it will cause me to switch.
The better thing for Trillian Astra to have is a native OS X version. Not sure if this is in the cards for the future, but thats the best way in my opinion to do Trillian for Mac users.
March 21st, 2007 at 2:11 pm
I agree with nova, I thought the point of having a flash version was to be able to run it on machines without having admin/install privileges. It doesn’t sound like Apollo fits that requirement.
March 21st, 2007 at 2:14 pm
this is cool. I am excited about the new version being avaliable anywhere you can get flash to work and my contact list folowing me around. I dont use iChat but I am looking at getting a intel Mac and dual booting between Win and OS X but I would like to see the same chat program on both. I belive alot of people that use windows will be switching to mac over the next 3-5 years. So I think OS X support is very important.
March 21st, 2007 at 3:21 pm
I knew that when Apollo was released publicly, that Trillian had the potential of being run in it. I’m glad the CS is experimenting with all technologies at it’s disposal and I cannot wait to see the finished product.
March 21st, 2007 at 3:29 pm
@j3rm
Highly unlikely. Mac’s user base would be lucky to break 10% in 3-5 years, and even that is incredibely unlikely. Macs will always be “specialty” hardware unless they enable the OS to be installed on other hardware (which will never happen for several reasons).
In conclusion, Mac support would be a nice idea, but I think Cerulean has plenty of other work on the table for themselves right now (by only focusing on the Windows/web-based platform).
March 21st, 2007 at 4:34 pm
@xxdesmus:
so 10% is nothing? i think Mac (and Linux!) users are important for Cerulean Studios for several reasons. first of all CS is trying to establish some kind of an own Trillian community which is a whole new concept behind Astra compared to Trillian 3.x.
if they want that community thing to work, they can’t leave 10% of the potential users out.
the other thing is that Mac users in general are more willing to pay for software than windows users. so they’d make good money with a Mac version, because they’d still sell a lot of pro versions.
i think Mac users and CS both would benefit from a Mac version, although i (as a Mac user) am not interested in Trillian for Mac at all. i just hope CS will launch a Jabber gateway on their Astra server some time in the future, so Astra users can chat to Jabber (and Gtalk) users without signing up for an extra account. actually i don’t understand why they had to develop their own protocol instead of using XMPP for the “native” Astra messaging features…
March 21st, 2007 at 4:47 pm
[...] Read the full review… [...]
March 21st, 2007 at 10:47 pm
Who do I have to blow to become a tester?
March 22nd, 2007 at 6:18 am
I just wanted to mention that you guys shouldn’t underestimate the inconvenience of having to install a separate package to use the “lite” version…that means:
1) I can’t use it at work, where I have no admin rights
2) I can’t use it when I am on vacation, and on the net via Internet Cafe
3) If the new features do eventually show up (systray, etc), you will have to perform some interesting version checking methods to make sure the user can take advantage of the new features, and also hope that most of them update. Imagine the testing nightmare if you have to regression test all your changes with all possible releases of Apollo. Yuck.
4) If Apollo doesn’t “take” (ie. Adobe drops it next year cause no one used it), you’ll have to completely redo your app.
I think I would definitely stick with the standalone lite version, rather than depending on Adobe.
March 22nd, 2007 at 7:14 am
lonevvolf: All true, but remember that we will always have the standard web version to address your particular points (no admin rights, Internet Cafe, etc). We’re basically testing the waters to see if we can come up with a reasonable solution for the middleground between full desktop access and web access – maybe you’re at a family members house for the holidays, you *can* install a small plugin, but you don’t want to flood their computer with a full Trillian install.
March 22nd, 2007 at 12:20 pm
[...] clipped from blog.ceruleanstudios.com [...]
March 22nd, 2007 at 8:46 pm
I am curious about the market for this middle ground between full desktop access and web access. I mean, wouldn’t it be easier to just use a non-installed or portable version of Trillian (a la TrillianAnywhere)? Running Trillian from a USB stick at a family member’s house or even downloading the non-installation version of Trillian (please allow for this) both seem much easier and less intrusive than having to download and install a whole runtime package (Adobe Apollo) and finally running the reduced functionality version of Trillian. The way I see it, since, like you mention, the user data will be stored server side anyways, a portable “thick” version of Trillian is the best of both worlds: you get full plug-in support and you don’t need to install anything.
In my opinion, the only benefit of the Apollo-based (or similar technology) solution is that you get a semi-functional OS X version. Just my two cents…
March 22nd, 2007 at 10:41 pm
[...] they posted some of their thoughts on Apollo. In order to do some of the OS-layer parts, they’ve created their own runtime (if you can [...]
March 23rd, 2007 at 7:02 am
Please don’t forget your corporate customers. It’s rough enough not having a full-fleded MSI file for installing programs. Please don’t force Apollo on us — us IT admins have enough to worry about than adding even *more* programs and more layers of things that could go wrong on a client workstation.
Unless you’re using Apollo only for OSX/Linux, then, by all means, continue as you were.
I do hope you are planning to target corporate customers. Even a few medium-sized installs could be worth many thousands (at $25 a pop, my office alone is worth a few hundred, not even counting our outside offices, and I’d be able to kill MSN Messenger at the same time! Hooray!).
March 23rd, 2007 at 7:08 am
DaCypher: Yes, OSX is the strong selling point for us right now. I’d rather do a real port, but time being what it is…
dq: The standard version of Trillian isn’t going anywhere, and an MSI is probably a good idea and not too much trouble for us.
March 23rd, 2007 at 10:33 pm
OMG! Please quit screwing with features that the majority of your paying customers don’t need right away or won’t use! Notice I said “need”. Design a platform that will support those features in the future – you’ve probably already done that. Then make a new client available in the traditional sense. Get some income from it and build/fund the cool bells and whistles with that. Reading about pissing away a week on this thing is irritating – there hasn’t been a Trillian update to add support for new service features since 3.0 and there are still problems with that. File transfers are slow as hell compared to the real clients. Also, when I move from my desktop to my laptop, if I don’t take Trillian off-line on the desktop, they fight over connections. With Yahoo that’s a big problem because I can’t get a connection on my laptop. AIM shoots irritating messages at me. MSN is quirky. I’d be much happier if I read that you’d wasted a week trying to come up with a solution for that, even if you failed. There are many other problems and I’ve even resorted to moving back to the real clients for some accounts to gain the funcitonality (file xfers that don’t take 10x as long). The real clients for all services have left Trillian in their dust as they release new versions with cool new features periodically – Trillian has been the same for years. That sucks and Trillian is fast becoming obsolete – the only advantage it has at this point is a combined list and Yahoo and MSN allow that now.
BTW: I wouldn’t even consider Apollo – I could imagine desiring access to Trillian Web at an internet cafe or while on-site at a customer and if they don’t have Apollo runtime installed, I’m screwed.
March 24th, 2007 at 5:04 pm
gizmobits … you forgot to take your medication this morning. It is their program and they will develop it at whatever rate they feel like. Do I also think they should work on this web end stuff after they have the desktop client version of Astra much further along… yes I do… but you are just nuts. Relax.
March 24th, 2007 at 5:41 pm
Nuts? No, sick of using an old client that doesn’t do half of what I need it to anymore. Times change, feature needs change. The transparent development process is fine, but blogging about feature after feature that are not part of the main client is irritating. I want a newer client, not all the bells and whistles. I’m sure they will make their money on the real client, so get it out the door. If they take too long (at their rate), they will lose the market. I’ve switched to other clients in order to get the features and performance I need and that really sucks. I want to give them my money to switch back, but if it takes much longer, I’m just going to give up and continue using the real clients – they aren’t as bad as they used to be.
Come on guys – give me a reason to give you some money!
March 26th, 2007 at 12:27 pm
As a learning Mac developer, my major problems with this app is it’s user interface. One of the major reasons people switch and use Mac OS X is because of it’s Aqua user interface. Aqua is clean, simple, and accessible. Looking at screenshots of Astra on OS X, makes it seem like an outcast application. I know there is skinning capability, but how far can someone take that into making it look and feel like a Mac app? Skype and Yahoo took the Aqua UI into consideration when they released their major revisions for the platform. They both look, feel, and function like Mac apps. The went as far as the preferences window to icons, and even to integration of third party applications like Growl. The beauty of aqua is that you can develop an app with lot’s of features and functionality like Astra has and make it look simple, nice, and easy to use. Astra’s UI certainly fits with Vista, but not OS X. I would highly recommend that you take an Aqua UI approach into heavy consideration.
March 27th, 2007 at 2:17 pm
umm. if this is the kind of issue you’re finally dealing with now.. what have you folks been working on the past 2-3 years?
good grief.. is this a company or a science lab.
March 30th, 2007 at 2:13 pm
[...] you doubt the impact, and believe that Adobe Apollo is dead on arrival, then you should check out what the gang at Cerulean Studios did with a couple days and the Apollo [...]
April 30th, 2007 at 9:30 am
If it’s not too late to improve on cross-platform development, what about .NET? I’ll admit I don’t know a great deal about .NET, but as I’ve posted elsewhere, this is what I do know:
1. If it’s written for .NET, then there’s a pretty decent chance it’ll work on Mono. (I don’t have the reference handy for this.)
2. http://www.regdeveloper.co.uk/2007/02/21/visual_basic_mono_linux/
3. Here’s a quote from Linux Format Feb 2007, p.40:
–Quote:
.NET vs Java
The cross-platform nature of .NET is made possible by the fact that programs are compiled into a special form known as common intermediate language (CIL), which isn’t tied to any particular CPU. When the program is first run, Mono converts the CIL code into optimised machine code for the CPU that it’s running on, which is how one executable file can be put on to any machine you lke and be optimised for each situation.
This probably sounds a lot like Java, in that developers write their code once and it can run anywhere. And actually that’s correct – .NET and Java are very similar. The difference is that the Java platform was primarily designed to be used with the Java programming language, whereas .NET was designed to be used with any language. The most common .NET language is called C#, and is heavily based on Java and C++. But you can also use Visual Basic, C++, Cobol, Eiffel, Perl, PHP, Python, Ruby, Tcl and even Java itself – they all compile to the same CIL code, and are completely interoperable.
This means that a team of developers can all work on the same project, with each programmer choosing which language suits them most – a PHP programmer can build on top of a C# codebase written by someone else, which in turn inherited from some Visual Basic code that someone else wrote.
–End Quote
May 18th, 2007 at 8:36 pm
Hi there, please leave it as it is working now. Please don’t use Apollo from Adobe and don’t use Silverlight (WPF/E) from MS..! I don’t want to download and install an huge runtime for this! Apollo runtime is about 6-10 MB, Silverlight runtime is about 2 MB, smaller than Apollo yes, but still not that great like your “os layer” (runtime) below 100 kb..! Even if your “os layer” for Linux, MacOS and Windows is in the final version below 500 kb in size, this would be much better than 2, or even 6-10 MB from the others..
Flash 9 is already enough with 2 MB runtime and I already don’t like the JAVA runtime environment with more than 13 MB of download size..!
(Even they (Sun) knows that this is too big for consumers and so they will develop an smaller Java RE which is modularized (http://weblogs.java.net/blog/enicholas/archive/2007/05/announcing_the.html) and only 3-4 MB in it’s core download..!)
So save time, leave your great working solution.
best regards,
PSchuetz
May 18th, 2007 at 8:37 pm
Hmm, your comment system/script is really strange.. o.O Sometimes multi line comments with wraps works, but sometimes not.. -.-