SmartfFoxClient AS3 Gotchas

[vizio]

This is more of a general info Topic.

As i'm approaching a new project and we've choosen SmartFox as our Server Side technology, I started Unit Testing the SmartFoxClient API for AS3 and while doing that I found the following gotchas that could create big delays when trying to track them down.


Logout
if you try to logout without being logged in you won't receive any event or error.

RoomList
The roomlist is defined as an Array but it's meant to be used as an hashmap.
If you check the lenght of the roomList it will always be one greater than the actual lenght this is because the roomList is 1 based.

BuddyList
When you remove all the buddies from the buddyList the buddyList array lenght is not set to 0, it stays set at 1 but no elements
are in the array.

Join Room
If you try to join a room that doesn't exist you won't receive any feedback.

Create Room
If you want to create a room you need to be already in a room.
You cannot create a room by just logging in into the zone.
This is not mentioned on the documentation.

sendModeratorMessage
If you try to send a moderator message from a user that is not a moderator you won't receive any feedback.


In general I think you should get some feedback (throw errors) when something goes wrong so that it will be easy to track down if any problem occurs.

Are you guys (Smartfox Team) working on a new AS3 Client API for SmartFox?

if so here are my thoughts on how I would like it to be

http://blog.vizio360.co.uk/2009/10/interface-segregation-principle-and-smartfoxclient/

hope this helps

[Lapo]

Can you please tell us which version of the API are you referring to?

Logout
if you try to logout without being logged in you won't receive any event or error.

Sure, it also doesn't make sense to do so.
We don't allow the server to respond to "illogical" requests as this is common in hacked clients who can steal resources by flooding with malicious or useless messages.

RoomList
The roomlist is defined as an Array but it's meant to be used as an hashmap.
If you check the lenght of the roomList it will always be one greater than the actual lenght this is because the roomList is 1 based.

Sure. Each room is stored in the Array with its roomId as the key.
Unfortunately arrays in Actionscript are very ambiguos to say the least and their length parameter is not based on real count of the elements but simply on the highest index available.Simply use a for in loop instead.

BuddyList
When you remove all the buddies from the buddyList the buddyList array lenght is not set to 0, it stays set at 1 but no elements
are in the array.

I have never heard of this problem before. I will add it to our bug tracker for further investigation. I have to say that all the examples based on the buddy list work correctly when removing all the elements, so I suppose that even if the problem exists it doesn't actually affect anything. I might be wrong. Anyways thanks for reporting.

Join Room
If you try to join a room that doesn't exist you won't receive any feedback.

The API will signal that the room doesn't exist at development time.
The server won't respond to the client to avoid hackers using this as flooding tool. The same goes for non-existing Zones.

In general I think you should get some feedback (throw errors) when something goes wrong so that it will be easy to track down if any problem occurs.

The problem with exceptions is that if the developer forgets to handle them
it will "hijack" their code flow. As a difference from Java, Actionscript does not support compile time exceptions.
While someone finds checked exceptions annoying they are indeed very useful because they allow the API designer to force the handling of critical exceptions and separate them from runtime problems that don't represent a major "threat" to the code flow.

Also there are many different cases in which exceptions are very arguable. Logging into a Zone or joining a Room are both good examples.
The only way in which your application can attempt to log into a wrong Zone is when the developer has written the wrong Zone name in the application code or configuration.
We presume that the developer run tests on their application, hence they will notice the server side error.

The same goes for joining a Room.
The API will complain about the target Room not existing in the local Room List. Again these errors should be found during testing, locally and they are unlikely to happen at runtime.
And I would also add that the only source for Rooms to join is the room list so it's even more unlikely that your code will make up a roomId on its own unless its badly flawed, in which case testing will reveal it.


Hope it helps

[vizio]

Hi Lapo,

first of all I would like to apologies if you got this post as an attack to the API. It wasn't meant to be. I was just sharing my opinions about it as I'm using it in my current project.

Can you please tell us which version of the API are you referring to?

I'm gonna check it on Monday and let you know.

Logout
if you try to logout without being logged in you won't receive any event or error.

Sure, it also doesn't make sense to do so.
We don't allow the server to respond to "illogical" requests as this is common in hacked clients who can steal resources by flooding with malicious or useless messages.

Maybe we are seeing it in a different way, I was talking about the client API so no need to send "illogical" requests to the server, it will just be a simple isLoggedIn boolean tracked in the SmartfoxClient.as which if is set to false and you try to logout you'll get an exception.

RoomList
The roomlist is defined as an Array but it's meant to be used as an hashmap.
If you check the lenght of the roomList it will always be one greater than the actual lenght this is because the roomList is 1 based.

Sure. Each room is stored in the Array with its roomId as the key.
Unfortunately arrays in Actionscript are very ambiguos to say the least and their length parameter is not based on real count of the elements but simply on the highest index available.Simply use a for in loop instead.

Sure I can use a for in but I'm handling an Array so I would expect that its length is equal to the number of rooms. I think these kind of things can slow down your productivity as you always need to remember that that is defined as an Array but it's not used as an Array.

BuddyList
When you remove all the buddies from the buddyList the buddyList array lenght is not set to 0, it stays set at 1 but no elements
are in the array.

I have never heard of this problem before. I will add it to our bug tracker for further investigation. I have to say that all the examples based on the buddy list work correctly when removing all the elements, so I suppose that even if the problem exists it doesn't actually affect anything. I might be wrong. Anyways thanks for reporting.

This is the same problem as for the roomList, it's an Array but it's used as an hasmap.

Join Room
If you try to join a room that doesn't exist you won't receive any feedback.

The API will signal that the room doesn't exist at development time.
The server won't respond to the client to avoid hackers using this as flooding tool. The same goes for non-existing Zones.

Yeah I found the configuration for that. But I think there was something else, I'll need to double check on Monday.

In general I think you should get some feedback (throw errors) when something goes wrong so that it will be easy to track down if any problem occurs.

The problem with exceptions is that if the developer forgets to handle them
it will "hijack" their code flow. As a difference from Java, Actionscript does not support compile time exceptions.

from your quote below : "We presume that developers run tests on their applications," hence they will notice the exceptions.

While someone finds checked exceptions annoying they are indeed very useful because they allow the API designer to force the handling of critical exceptions and separate them from runtime problems that don't represent a major "threat" to the code flow.

I completely agree with you, and I love exceptions.

Also there are many different cases in which exceptions are very arguable. Logging into a Zone or joining a Room are both good examples.
The only way in which your application can attempt to log into a wrong Zone is when the developer has written the wrong Zone name in the application code or configuration.
We presume that the developer run tests on their application, hence they will notice the server side error.

yeah I presume that as well, but still while developing the application it will be useful to get a feedback straight away, as human error can always strike.

The same goes for joining a Room.
The API will complain about the target Room not existing in the local Room List. Again these errors should be found during testing, locally and they are unlikely to happen at runtime.
And I would also add that the only source for Rooms to join is the room list so it's even more unlikely that your code will make up a roomId on its own unless its badly flawed, in which case testing will reveal it.

Still I think that during development and to avoid endless debugging sessions you should get a feedback to know what went wrong.

Hope it helps

yes.

cheers
Simone

[vizio]

Hi Lapo,

ok I've been using the client API version 1.5.4 and now I'm trying version 1.5.8 using my UnitTests for it.

The server version is 1.6.6.

with version 1.5.8 this is traced when you try to ask for the activeRoom when you are not in a room yet.

****************************************************************
Warning:
You haven't joined any rooms!
In order to interact with the server you should join at least one room.
Please consult the documentation for more infos.
****************************************************************

I think this could be an alternative way of giving feedback to the developers instead of using exceptions but I still prefer exceptions

Are you planning to put out a new version of the API soon?

[Lapo]

New version has been released with update 1.6.7
viewtopic.php?t=6006

[AlecMcE]

Hi Lapo,

Before I say anything, we use Smartfox Server because it's a really good socket server application that makes development easier. This isn't a criticism, but an attempt to offer developer feedback to hopefully improve the product!

Anyway, I agree with Vizio about the problem with the usage of Arrays in the Smartfox client code.

If you're intending to use the list as a hash-map, why not just use an Object? That way you are not exposing a misleading length property. You don't lose any functionality and can still use an integer as key.

Developers can still use the for...in / for...each structures as before, but can't use the for (var i:int = 0; i < list.length; i++) structure, which would avoid some of these potential pitfalls.

Regards,

Alec

[Lapo]

Constructive criticism is always welcome, that's why we keep this board so active, to get comments and feedback, suggestions and ultimately improve the product.

As regards the Object/Array thing I perfectly understand. This is a legacy of AS1 and AS2 code which was the codebase we used for the AS3 porting.

Among the many missing things in Actionscript 3 the lack of real collections is probably the most annoying. The language aspires to follow the path of it's "bigger cousins" like Java and C# but it fails to provide essential tools like Lists (array based lists, linked and doubly linked lists), Sets, Maps and so on...

Finally some generous developers have started creating a set of open-source collections that mimic the java.util package in Java. Too bad at the time we were porting our code those didn't exist and we didn't have time to start a parallel project to create them.

I understand your criticism as regards the usage of Object vs Array. I have always found the Array class to be very ambiguous because it can work with any index rendering the length property completely unusable (unless you just use push/pop)

Example:

Code: Select all

var ar:Array = []
ar[10] = 10
ar[250] = 250
ar[750] = 750
trace("LEN: " + ar.length)


This will output -> LEN: 751

For example when we create the User lists we use an Array because it seems to make sense. But we don't use push() and pop(), we use the User Id as the index, which is perfectly legitimate.
Unfortunately this breaks the length property, and yet I am using the Array as an array Or at least... the Array allows me to use it with non adjacent indexes.

Also the same Array class not only supports int values as the key (allowing "holes" in the structure) but it also works with Strings or any other Object reference as well. So the the fine line between Array an Object blurs even more.
An index-based for loop should be used with Arrays exclusively if your data uses adjacent indexes otherwise you are wasting precious cycles to go through null references.

If we want to get really technical at this we should also note that Actionscript 3 is a strange frankenstein-like language that fuses elements of statically typed languages (Java,C#) with elements of dynamic languages such as Javascript and Python.

Dynamic languages always enforce the use of iterators over index-based looping. This is because the index-based looping is a very old-school, low-level approache inherited from C language.
If you think about it you always start with index = 0
This makes little sense actually because when you start counting any element in real life you start from 1 not from zero!
So why is that?
It's because in the good old days of C programming the index-based loop was used to go through memory locations... not something we do so much today, with VM-based languages that forbid direct memory access
Anyways, for some reason, the habit of the for (int i = 0, i < x; x++) is still rooted in most developers that come from C-based languages, even with the introduction of Iterators in mainstream languages, back in the early 90's

Oook, enough ranting

Now for the positive note:
We're currently working on the next major SFS update, it will be a very big one with new APIs and tons of new things. All secret for now
AS3 API are re-written from scratch using AS3 best practices, collections etc... abandoning the dynamic/ambiguous aspects where possible. (Unfortunately AS3 still misses polymorphism, abstract classes, generics and more...)

Hope it helps

[AlecMcE]

I'm not entirely sure I needed the lesson Lapo, but thank you for it anyway, except for the point where you said "dynamic languages always enforce the use of iterators" which is an odd thing to say.

I was just agreeing with the point that there's no utility in using Array when you're not exploiting the functionality of Array, and you could just as well use Object, so it's odd therefore that you used Array not Object.

I get the impression everything written on this forum is seen as some kind of attack, though I don't know why; we are only trying to offer our experience to improve a product we pay you to use! Professionail courtesy ought to be extended.

[Lapo]

I'm not entirely sure I needed the lesson Lapo, but thank you for it anyway, except for the point where you said "dynamic languages always enforce the use of iterators" which is an odd thing to say.

Those were just comments, I am sorry it sounds like a lesson. I said I perfectly understand your criticism and I expanded on some of the background behind it.

I get the impression everything written on this forum is seen as some kind of attack, though I don't know why; we are only trying to offer our experience to improve a product we pay you to use! Professionai l courtesy ought to be extended.

Really?
If I say that I understand your point of view, and that we're working to improve it ... I am confused. Anyways we try to take care of any constructive feedback that we get, and I guess that the frequent updates are a good proof of it.

As regards courtesy, I hope that the many smiling faces in my comments enforce the concept of friendliness.

Hope it helps
Sorry again for the rant

[Lapo]

I'm not entirely sure I needed the lesson Lapo, but thank you for it anyway, except for the point where you said "dynamic languages always enforce the use of iterators" which is an odd thing to say.

How dare you contradict me?
Now seriously... take a look at Python, Ruby, Scala, Erlang... they really really do enforce the use of iterators

[AlecMcE]

OK. I felt like the point I made was brushed aside by the history lesson! Glad the point is well-made. Sorry for over-reacting

[Lapo]

No problem
Btw, the classes I was mentioning are these: http://code.google.com/p/as3ds/

[vizio]

As I started the topic I would like to thank you Lapo and Alec for the replies and I'm looking forward to see the new API.

For now I'll use my wrapper with the fixes for the issues above

cheers
Simone

[daperson]

On a related topic, another little thing I've run into is that, while the joinRoom function will by default automaticially remove you from your current room, the autoJoin function always does not. This is not mentioned anywhere in the documentation.
A minor thing, and easy to diagnose, just wouldn't it make sense for both functions to behave the same in this way?

[hadrien]

Now for the positive note:
We're currently working on the next major SFS update, it will be a very big one with new APIs and tons of new things. All secret for now
AS3 API are re-written from scratch using AS3 best practices, collections etc... abandoning the dynamic/ambiguous aspects where possible. (Unfortunately AS3 still misses polymorphism, abstract classes, generics and more...)
Hope it helps

Hi!
Is there any roadmap?
Thank you.