I've been seeing a bit of a better demand lately on my site for information on FCS. It seems FCS is picking up a bit better now in Japan which of course leads to lots of questions... And boy do I have answers! well.. most of the time. :)
Currently I have about 19 tutes up on FCS, but because it's not such a hit yet here (lack of japanese hosts, high cost, and no info anywhere.. a bit on MM Japan's site) I haven't posted anything coming close to "advanced material". Though I'd like to change that, and it finally seems like there is a demand for it coming through.
The latest question I got was how to call a function that is in another client's movie. Of course being able to do that brings all kinds of options to the board, the most basic being maybe a URL opener, to something more along of lines of letting the user know that somebody (passing the username too) is trying to get a hold of them and to open up their video window to have a conference. Or something along those lines :)
I'm not sure exactly what the user is going to use it for, but the goal is quite clear I think. So how do you teach something like this? There are of course a series of steps to take to acquire this ability to send commands to a particular user and not all or a group. It wouldn't do to send a request to a user, to find out that it got sent to the wrong user, let alone to all users!
I originally explained on the forum to the user the steps that are required to accomplish this.
1. Give the user a unique ID that you can use later to pinpoint them
2. Setup an event handler to know when you have chosen a user and want to send them a command
3. Setup a receiving function in the movie so that when somebody calls it, it will do something.
There are more points but this is where it gets a bit sticky because there are at least two ways to do this. There are good points and bad points to them too. I'll try to explain the main two ways here:
The first way that we have is to setup functions on the caller side to send the call with the callee ID, receive that on the server side and then send it off to the callee but matching up the ID to one of the connected users. This is the best way. Why? because now you have control over what is happening. If you wanted to, you could even log that in a central location! I've explained this bonus in this post. The down side? well.. you have to be able to use server side script. It requires a server side script to run and requires processing power of the server (which maybe isn't so bad).
The other option we have is to have all connect to a "command" shared object. Using the send() method you can send calls to functions that are connected to the shared object on all users. The upside of this? well, it's all done on the client side. You don't even need to use server side script. If I was going to hijack somebody's account (which I wouldn't) I would use this method :D . You don't need to know SSAS and there is no need for a server side file. The bad side? besides the fact that it's not controllable centrally, the function get's called to everybody. If all receive the call, they all have to check if they are being called or if it's for someone else, if so then ignore it. This takes up cycles on the client side (not good) and sucks up more bandwidth in the end.
It so happened that last night the user that was wondering on the above issue popped into the on-site chat app I have up and asked another interesting question on how to get his video to show up on somebody elses screen. This surprised me a bit as it isn't so tough and ended up taking out about 10 minutes to explain it in detail of what to publish and play. Using the "shared notepad" I have hooked up to the chat, I wrote out the required script for him as he watched on hmming and hrmming ;). It's cool to see people grow and realize new things when you can give them some info on whatever they wanted to know. You can almost see their eyes light up in recognition of what is going on, and off they go to try out this new idea.
I ended up writing a tute on using the server side script style and am waiting patiently for questions that I hope come so I can delve into it a bit more. We'll see where it leads to.
What the heck? Going through blogs lately you'd think that FCS pretty much disappeared off of MM's radar or something, they haven't posted a new resource, technote, tutorial or advertised ANYTHING for it for quite some time now. Neither have any of the other bloggers. Not only that, it's pretty much the only product that they DON'T have a link to on their home page...
Mike Chambers is hard at work pushing Central, Ben Forta is all over the place pushing Flex, FlashMX2004 is getting a lot of attention, lots of CF stuff... but NOTHING on FCS.. Do people know something I don't? Is it because FCS is in wonderland sitting at version 1 and a half? Yes thats 1 and 1/2. Looks different from 1.5 but it's the same thing. It's halfway from somewhere and halfway to nowhere as there hasn't been any notice whatsoever as to what is going on...
Well, if MM won't push it I will. This software is cool, and I really hope they don't discontinue it anytime soon... though with the lack of PR lately..
Here are some great resources on FCS. There aren't many and I will update this post as I find more, or if you have any that I have missed please feel free to post it, but here goes.
Biggest and newest on the list is:
Flashcomguru - This site currently has 16 tutorials on FCS with a lot more to come. I've written 4 of them with other top FCS developers out there like Fernando, Stefan, and not seen lately Gani. There is also a very active forum there for all that have questions or comments on FCS. Thanks to Stefan for putting this site up and supporting it.
Peldi.com - Everybody has heard of Peldi's site. The major FCS god out there in MM. He usually posts some great pieces of code that you can take advantage of in your own apps. The great thing is the other two gods of FCS in MM, Srivanias and Pritham also donate some great snippets or small apps that really help out.
Flashcom figgyleaf mailing list - A superb place to get info on FCS. There are a lot of people on this list that know what they are doing with FCS and most questions do not go unanswered on here. MM watches it too, so every once in a while they will pop in with some comments or help. Very appreciated.
Brian Lesser's site - Soon to get a book out (I haven't read it of course, but I would already fully recommend it. Brian is one of the most knowledgable people I have had the pleasure of arguing with on figgyleaf ;) Excellent skills with FCS
Fernando's site - A blog with snippets and components for FCS. What a wiz! He doesn't post so often but it's quality not quantity for him I think.
Last and pretty much least is MM's site. OK, it's not that bad :) although lack of new info and articles is quite disappointing but with any luck it's just that they are really busy with.... something... they don't even watch their own forum..
I love it. I use it as much as I can whenever and wherever I can. Why? Well that's something I'd like to help others understand, so I'll write a couple of paragraphs on it (another topic I've wanted to write up on for a while now..)
The biggest "immediate" bonus I have found using SSAS (server side actionscript) is that nobody can see it but me. In other words, even if you steal my code with ASV or some other decompiling program, you'll most likely not get it to work properly, mainly because I hide most of the meat in the server side and just make calls to it. There are a lot of discussions going on right now on this topic and I really wanted to point out that if you plan and design your apps right in the beginning, your FCS apps can stay reasonably safe. That's a major bonus, but it's only if you are worried about your app getting ripped off by some swf thief out there. If that's not a big deal then this bonus isn't so great.
What's the best bonus though? I have found that putting most of my "controlling" functions server side, I have central command of what is going on in my app. This is extremely important as I actually mentioned in a past post here when talking about debugging FCS apps.
If you ever have an application where a user's properties, for example their status (busy, away, here, sleeping...) needs changing, you should never ever "set" the value on the client side. Send that value to the server where the server will take it and set the value. This isn't so much a big deal where only one user can set one value as it is when you have a lot of users who have the chance to set one value (or more). If you don't control this server side, you are going to see mayhem in your app, and nothing will work as you wanted it to (depending on the app of course, but in my experience... ) This is the absolute beauty of SSAS. I recommend sitting down and learning it, using it, making mistakes, fixing them, all kinds of things. Play with it, learn tricks that will be useful in future apps. There are a lot of functions you can create that can be used throughout many many apps you build now and in the future. ID creating, password changing, status changing, kicking users off your app... stuff like that.
Safe, easy (reasonably), effective, reusable.. what more could you want?
Here's a topic that I've wanted to write something up on for a while now. Working in Japan I've had a lot of chances working in teams or the head of team developing and designing multilingual applications. Thinking of just one language for an app is not so bad I think. You accomodate in the design the right amount of space to put in the text you want to show. All your strings are relatively static so you don't have to put too much thought into what's going to be placed in and it's quite easy to get a decent layout going. This is where the difficulty of multilingual applications come in.
The one thing I have found up until this point is incompatibility with a certain language of an OS, or applications that only support one language (which are only too often...) If any of you have used After Effects, you would know that you can choose which language you want to install it in. This is close to my idea of an ideal multilingual application. To make it one step better, it would be best if you could change languages on the fly. FlashMX2004 is absolutely horrible in this way as you can't install 2 versions of the app anymore (even if you have licenses) on one computer which means it is FOREVER English or Japanese or whatever language you have bought. From what I understand, even if you uninstall one and install the other it won't work but I haven't tested this myself. This is the third worse situation, the second worst would be that there just isn't the language your are looking for so you settle for English (this sucks..). Last of all, the worst would be that there isn't anything but English, so you settle for it, but it doesn't read 2 byte characters so you only have the alphabet to work with, which means you can't even render out text in your own language...
While working on a new application we had decided that the application must support language changing on the fly. The world is too closely knitted together now, thanks to the internet, to only support English. If you do that, you have already cut out a HUGE chunk of customers that don't want to work with English apps (there are a lot of people who disdain English apps... trust me) If you want to use it in English, you change it to English, need it in Japanese, then just change it over. The interface changes up nicely, all the fonts change and the font size adjusts to a new size to fit the font that has been set up for that language. This is where Flash excels! I can't imagine doing something like this in html as just messing with the fonts alone would cause the page to reload... either way this isn't a web based app. But the ability to just change a language up at the push of a button is a nice feature I think.
To do this, we took advantage of the textFormat method and just made sure to set the fonts and sizes properly. Then it's just a matter of telling all the text boxes to switch over to the new language and then subsitute the strings with the appropriate words. With the ability to read in XML as well, it's simple enough to keep on adding languages for when the user base grows out of your own locale.
If you have never worked on an app that uses more than one language in it's interface, I stronly suggest giving it a try. Find a team you can join or come up with your own application maybe. There is a lot of knowledge that can be gained from the experience and it makes you look at application des/dev in a completely new way. Though the one thing I have found hardest is conforming things to match up grammatically correct. Though with some heavy planning in the beginning it's not too big of hurdle to jump over.
Definitely worth the experience though, and not only that, going back to one language apps is almost boring in a way because you have no need to implement different types of tricks and fixes to get around the interface going all weird on you when you switch over.
I've beta'd for a lot of companies I think. Checking software, seeing where it is going wrong, making sure to post as many details as I can with my PC specs and how the heck I made it mess up. These things are very important to a developing team. If the team is large enough, the bug itself get's sent to certain section of the team and they ponder away on it. So now we are in beta testing world. Not that I have never built an app before, or been part of a team that has, but this is my biggest so far I think. Got an app built, we played with it, had fun, didn't find any real bugs and let the testers go at it. In one day there are already over 20 bugs and suggestions of improvement (all put together).
This doesn't really amaze me as much as overwhelm me. Bug squishing is not a fun job, unless you're the type that really likes it... I'm not. But I do like to solve puzzles and riddles so it's not so bad. The biggest problem I have found so far is that it's sometimes hard to figure out if it's your own bug or the software you are using to build the app.
We currently are using Flash and Screenweaver (tried Flash Studio Pro but it sucks badly..the built app crashes everytime it's launched...I do not suggest using this software) for a desktop app. It's fun to put together and harness the power of both pieces of software (combined with FCS of course :D ) but there sure are some weird quirky things that go on depending on the settings you use.
One thing that I'll mention here, is to never set the cursor to anything. If you do that, it'll never go back. For example, you set the cursor to the help cursor (little question mark next to the arrow) when rolling over a button maybe. When rolling off you set it back to the arrow right? The problem is that it never changes back to the little hand when rolling over buttons... bummer.. thought we could add in some neat cursor work. Instead that'll have to be done inside of flash I suppose.
This has definitely given me a much greater respect of the hard working fellows taking a look at beta remarks and implementing them into the application. Can't wait to get this app out, lots of work but seeing a high quality application go out your door into the world is a very neat feeling.
I make a lot of chat apps with flash. Lobby chats, one on one chats, group chats, presentation chats... in the end they are really the same thing I guess and whenever I make a chat I start with a text box on the stage. I then press the little "render as HTML" button in the properties window (gotta have colors and sizes and links and stuff), and proceed to put in my code and run it.
Here's the problem. Everytime the chat starts from the second line in the text box, not the first line, so there is a weird one line space at the top. But only in the beginning. Since this annoyed me I used to solve the problem by initializing the app with a chat_txt.text=""; and the line feed would go away and it would be normal again. But this didn't go well with me and I was really looking for a way to find out why or how I could not have this happen.
It turns out, if you have a text object on the stage and you press the little icon to render it out to html, a line of html code automatically gets put in the text box. It has a
in it and this causes a line feed and gives me my problem. Though, if you set the text field to normal again, and go to the actions panel and enter chat_txt.html=true; it doesn't put the line feed in, and the text object is rendered out as html. This is the proper way it should work... Is it a bug? Don't know, and since it's only FlashMX then I'm sure nobody really cares, but I'm quite curious if the same problem (problem? or is it supposed to act like this?) happens in flashMX2004. If I'm the last guy on this earth to actually realize something so basic then so be it, but I'm sure there are a couple of you going "really? hmm"... or something along those lines :)
If you haven't caught wind of this site, www.flashcomguru.com yet (being on Figgy's FCS list.. you probably already have) then hop on over there! It's only just started (less than 24 hours ago) but I've never seen a bigger faster growing community site for FCS yet and there is a LOT of talent there. You got questions about FCS? They'll get answered. Combine that with a whole bunch of tutorials on how to mess with FCS, and it's a full blown virtual knowledge base for a software that has been left a little out in the cold concerning tutes and reliable information. (unless I'm missing a site or two in my favorites... let me know if I am)
Anybody on the Figgyleaf Flashcomm mailing list has heard these stories before and especially now of how some connection lines are getting jacked, or even the whole applicaton! Poor Peldi has had his whole swf taken into a frame of another site and used to the hackers discretion. Why does this happen? Who's responsiblity is it to secure the FCS apps? What can we do to not have this happen?
Read on for more on my thoughts on the security of FCS.
Well there is a mighty force brewing in the FCS developing world right now. All kinds of ideas of how to "get the hackers" and whatnot if they try and come to take your app away to their own world. This is all cool, as there are tons of ideas out there of how to check where the swf is being read from, the html file, and where to direct them if they aren't in the right place. It's cool to see a community come together on something.
So what's the problem anyways? Well, to get an answer for that you have to take a look at the security for FCS and how it can be manipulated. How can you protect your apps straight out of the box? (or straight after the DL from MM's site). By default, there is no security set up for FCS, you have to change up some of the files a bit yourself (which is quite normal) There is one way to secure things right away. That would be to go into the vHost.xml file and change up the Allow tag down near the bottom of the file. There is also one in the adaptor.xml file, but for most who don't have their own server, the adaptor.xml file will not be available for you to change.
There's a server side script that can be created for this type of thing too if you can't set the vhost or adaptor file to limit domains, and that is to get the referrer of the app, but this is a poor way to implement security in a Flashcom app as it can be faked by just writing the name of the domain as the name of the directory or file, and it can be got around just a little too easily for my liking.
BUT, as we have seen with Peldi's app, neither of the above help. What happened with him is that the hackers took his swf, not to put on their site, but to just link to in their own frame and used his app freely. That's easy! So, even if Peldi had his security up on his app, which supposedly he did, it doesn't make a dif in this case as the file is literally still on his own site... and the referrer is pointing to his site.
So what is a true fix, and good security? Well of course implementing the above works well for most situations like when somebody rips off your connection string (which is simple with ASV), but how about when they want your whole app, and not just the connection string? This seems so weird though... maybe put a big logo on there? Welcome to MY (substitute your name or site name) CHAT APP.
First off use a DB, and create a proper logon sequence to the page. Make sure the user is a registered user of your app, then let them connect up to the swf. Of course if somebody registers for your app and they make it in and then steal your connection string.... well you may be hooped but not if you combine the above with some proper server side script and remoting. So far, the best combination I have found is to make sure you pass over the username and password to the FCS server (over https), and have remoting (if you have it) on there check a DB if the user is a registered user. This can all be done in the server side of the FCS app asc file. If they aren't a registered user, you can tell them so (maybe they got the PW wrong) At the same time, you can keep a record of how many times they messed up with logging in, and lock them out, but that's getting a bit indepth for this post.
What do you do when a registered user rips off your app then?? setting it up so that anybody can log into the app with the registered user's username.. Well, then it's a matter of making sure the file is not being put in a frame on somebody elses site. There are multiple ways to do this depending on the server side language you are using.
I'll try to post more on this soon, but what a headache this is for all FCS developers. It sucks that there isn't an easy way to protect our apps, but the technology is young and I'm sure MM will think of something to combat these new style of hackers. If anybody has more ideas, or things that worked for them, I'd be glad to hear about them along with the rest of the FCS dev community I think.