Removal of ArrayCollection

XIFF
1

I have been trying to reduce the size of the XIFF library.

One biggest influence is with the Flex classes such as ArrayCollection.

By testing the following example

http://paazio.nanbudo.fi/tutorials/flash/xiff-chat-part-2-roster

Current trunk: 70.6 KB

ArrayCollection stripped: 33.2 KB

With this one

http://paazio.nanbudo.fi/tutorials/flash/xiff-chat-part-3-chat-room

Current trunk: 75.3 KB

ArrayCollection stripped: 38 KB

etc…

The functionality is kept approximately the same expect of course losing the easiness of ArrayCollection as the data provider.

This in my opinion should be done anyhow at the application level, library should provide only the needs related to XMPP.

The removal of mx classes will enable AS3 only projects and the possibility to use XIFF directly in Flash.

Attached is the patch for the current trunk of writing.

I am hoping this will create some discussion so I would see if this is the direction where the community wishes to go.

The patch also includes some merely cosmetic renames in order to follow more precisely the Flex Coding conventions, which is something we committers have considered to follow.

http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
remove-arraycollection.patch.zip (10660 Bytes)

2

My biggest beef at the beginning with XIFF was that it was dependent on the Flex framework.

Our site is an AS3-only project so I had to work around this issue since I was determined to not include the entire framework.

I went into the Flex SDK directory and pulled out the ArrayCollection class (and all of its dependencies) and added the source into my project.

It ended up being a total of 35 classes. Obviously this isn’t ideal, but it is less than including the entire framework.

Comparing your projects, I got 59k for the first one vs 70.5k and 63k for the second vs 75k.

Still not as good as removing ArrayCollection altogether, but you do keep all of the functionality of ArrayCollection intact.

I actually think we could easily rewrite our own ArrayCollection with most of the functionality in 2 or 3 classes, ArrayCollection, CollectionEvent, and CollectionEventKind. This I think would be the best solution rather than losing the functionality.

While we are in the mindset of removing Flex references, a few other things need to happen:

All [Bindable] tags need to be removed. These pull in the Binding framework which isn’t necessary.

The logging directory that has been added is actually bad if we want to pull away from the Flex framework.

It references many mx.logging classes, at least one of which references mx.managers.SystemManager. This class pulls in most of the framework and can’t be separated out. There’s plenty of good non-Flex loggers that I would suggest we migrate to.

VCard still uses Base64Decoder.

Plain uses Base64Encoder.

I just realized that the reference to HTTPService in XMPPBoshConnection has been removed, that’s nice (that was pulling in quite a bit of Flex rpc classes).

There might be others, but that’s what I’ve got for now.

PS, I’m actively working on XIFF projects, so I would love to help out if you would like.

3

Help is surely welcome.

If you are willing to write those replacement classes, then please do so.

By removing Bindables and mx PropertyChangeEvent from RosterItemVO reduced some 3 KB more. Not much but enough.

In another post I had comparison of using Hurlant Base64…

http://www.igniterealtime.org/community/thread/39413

Anyhow the current (patch version) offers the array of the items which can be used as the source for arraycollection in the application level.

Also if you are interested:

http://www.igniterealtime.org/community/docs/DOC-1873

specially the documenting part.

4

I’ll start looking into writing those classes.

Even though the bindable stuff doesn’t save that much in size, it would be nice to not have any Flex references, so the lib could be used with the Flash IDE as well.

With regard to the Base64 classes, if the Hurlant classes can be included and distributed with the lib, that might be the best solution. So that the lib isn’t dependent on external libraries. I saw that AS3CoreLib pulls in the mx Base64 classes as well, maybe its not that bad, but I still think it would be best to be completely Flex free.

I saw that you mention in the post about Base64 that you removed the logging directory. Are you commiting to a branch? I just looked at the trunk and the logging directory was still there.

5

The usage of logging is removed, the directory is still there. Perhaps will be gone over night…

There has been discussion about adding as3crypto as a dependency as the TLS connection class, which is not yet committed, is using it anyhow.

6

Attached an updated patch with less changes for easier review.
remove-arraycollection2009-08-20.patch.zip (2656 Bytes)

7

Last night I worked on a version of ArrayCollection that is currently only 3 classes (ArrayCollection, CollectionEvent, and CollectionEventKind).

This matches most functionality of ArrayCollection, but I had not built in sort functionality.

I did however notice that in the constructor of Roster it sorts its groups collection based on label.

I’m not sure how important that part is.

If it is important, then I can add a couple more classes to add all of the sorting functionality that Flex’s ArrayCollection has or we can sort the collection’s array directly.

Otherwise, I think we could use it as is, with just a little more testing.

8

Attached is a patch replacing Flex’s ArrayCollection with a custom ArrayCollection.
custom_arraycollection_2009.08.20_patch.zip (4123 Bytes)

9

Issue for the subject created: http://www.igniterealtime.org/issues/browse/XIFF-58

It is probably required that you sign the contributor agreement before the patch can be applied.

http://www.igniterealtime.org/community/docs/DOC-1733

10

Ok… signed and faxed in.

11

Hereby I inform the community that the Flex version of the ArrayCollection class has been removed.

Thanks Mark for the help!

12

It seems that there are some quirks to iron out. My contact list is built as: [Bindable] private var mRoster:Roster; First, in rosterRenderer, I was passed the Roster as data instead of RosterItemVO, a quick fix is to use mRoster.source in dataProvider of List. Second, the list does not refresh any more, it needs to be explicitly invalidated after contact change.

13

Refresh and binding are not supported in this version of ArrayCollection.

Refresh is not supported because the built in Flex sorting and filtering is not added in.

Adding that in, would add more overhead and I was trying to keep the ArrayCollection lean (compared to Flex’s).

Could you just apply your own sort to the collection when you listen to the change event?

Binding has been pulled from the entire library. You can listen to PropertyChangeEvent.CHANGE on the RosterItemVO though.

I’m not sure what you are referring to with rosterRenderer.