Quick flash to java switch

I would like to help out those few sad souls who want to switch from flash/flex to java to create some graphical stuff.

I just want to show the basic idea, let’s draw a simple red square.
In flash its simple, since flash is for creating graphics, the main class has to be a Sprite or a MovieClip, and you can directly access the graphics interface of these two, and can draw directly.

In flash, since the first frame is the main sprite, you simply can write

graphics.beginFill( 0xff0000 , 1 );
graphics.drawRect( 0 , 0 , 100 , 100 );


in flex, it looks like this :

package
{
import flash.display.Sprite;

}
}
}


and there is it.

In java, since its a general purpose programming language, its more complicated.
We need a window, where we can show our graphics, and then we need a component where we can paint our stuff. But still, we can do it quite simply in one class.

To create a window, we simply instantiate java.awt.Frame class, and for drawing we will use the java.awt.Canvas class, which is the simplest component for drawing.

Consider java.awt.Frame as the Stage in flash, and java.awt.Canvas as the main Sprite. So, here we go :

import java.awt.Canvas;
import java.awt.Color;
import java.awt.Frame;
import java.awt.Graphics;

}


The biggest difference that we cannot draw immediately, we have to wait for jvm’s inner call to the paint( Graphics g ) method, altough we can request it by calling the repaint( ) method.

We have an easier job with an applet, because Applet main class is a Panel subclass in which we have the paint method, and its already in a window.

MilGra

Iteration hell

a very common problem in java when you are iterating through some list, and an external thread or the thread itself wants to modify the underlying list

public ArrayList < Object > objectList;

public void onTimer( )
{
for ( Object object : objectList ) object.update( );
}
// ==> this method is invoked while onTimer is running
public void addObject ( Object objectX )
{
objectList.add( objectX );
}


to avoid concurrent modification exception, the most common solution is to use an iterator and add/delete the new element with it, or, if it is safe for the same thread, use synchronization to handle external threads.

my problem is that both solution needs too many cpu cycles.
for most cases, the solution below is the best :

public ArrayList < Object > objectList;
public ArrayList < Object > backingList;
public boolean change = false;

public void onTimer( )
{
if ( change ) { backingList = new ArrayList < Object > ( objectList ); change = false; }
for ( Object object : backingList ) object.update( );
}
// ==> this method is invoked while onTimer is running
public void addObject ( Object objectX )
{
change = true;
objectList.add( objectX );
}


so if the original list is changed, we clone it before iterating through, and modification of the original array won’t affect iteration. but beware, its only good if a plus cycle doesn’t matter on the objects ( no destruction happens before removing the element ).
in those cases good old iterator has to be used.

MilGra

Bit level compression ideas

What is the basic idea behind compression in computer science? To find the largest similar sequences in a byte stream, and replace them with short identifiers.

There are lots of algorythms, but somehow almost all of them are byte-based. So i started to think about a bit level algorythm.

The first idea is very simple. It’s based on a state switcher machine.
A bitstream contains pairs of bits with four possible pairs.

00 01 00 01 11 10 11 10 00


We can find an optimal sequence, where these pairs follow each other in a special order where we can step between all states in two direction.

In the above stream, the ordering looks like :

00 01 11 10


And if we say, that we step left under the code 0, and right under 1, we can describe the starting sequence like

00 -> 1 -> 01 -> 0 -> 00 -> 1 -> 01 -> 1 -> 11 -> 0 -> 10 -> 1 -> 11 -> 0 -> 10 -> 0 -> 00


So if we know the starting order, we can simply describe the starting stream on half size :

10110100


And when we are ready, we can recompress the resulting stream again the same way.
Seems good at first glance, but in real life cases its not really efficient, beacuse for perfect 50% compression we would need four directions, but we can only describe two on one bit. It works good only on special cases. I’ve run a few tests, and the compression rate was around 60-70 percent, while classic byte based routines did 30-50.

So i have to think it further.

MilGra

One of the best programming tools ever made!!!

And that is sdedit. The quick sequence diagram editor. Its awesome, its heaven, its salvation.

Its like a command line uml sequence diagram drawer. There is a descriptor script on the left, and the diagram on the right. Only with a few lines of description you can create complex diagrams, it supports multithreading, and everything possible.

I was in pain in the past four days, i’ve tried a lot of sequence diagram editors, standalone and eclipse-plugins, free and closed source, but they were all so difficult to use, click a lot for a little change, to insert a thread, or it was impossible at all.

And then i found sdedit. I was surprised, is it possible to describe complex diagrams with simple commands? And yes, since it draws sequence diagrams, sequencing elements is straightforward.

Should be industry-standard.

Thank you Marcus Strauch.

MilGra

Data UI component hell

When i was a young programmer, and i had to make some data holder ui component, for example, an userlist, i simply created a component which had two methods for manipulation :

addUserItem( id , nick )
removeUserItem( id , nick )

And the component itself created and stored every item object, and also contained the routines for displaying the wanted region of elements, and listened for click events, and dispatched every added info with these events.

After my application needed more slightly different data UI components, i realized that its not a good idea to make too specialized components, because they have a lot of functionality in common, the only thing what differs are the items, and the data needed for the items.

So i started to think. What if i create a table component which accepts pre-made items, and it just displays and scrolls them, and all item-related stuff is up on me, disconnected from the component logic.

addItem( item )
removeItem( item )

It was much better, but it still was a pain. If i had more items, than i had to iterate trough arrays to add them to the component, or if i had to remove plenty of items, then it was also painful. So i’ve added two more functions

addItems( itemList )
removeItems( itemList )

But it still wasn’t satisfying, after months i knew that it could be simpler. Its not good that i need four functions. I’m adding and removing single and multiple elements, and the component is maintaining an internal array of elements. What if i simply give an array of items to be displayed?

displayItems( itemList )

So the component doesn’t have items any more, it just displays a list of items. I don’t believe in universal classes, components and frameworks, but this is one case which seems to be the perfect solution.

MilGra

When one method does matter!

While keeping method count minimal, we have to keep our code unambiguous and well-readable. And here comes on of the trickiest thing of the streaming industry : state setter methods.

The two most common examples are the pause/resume, and mute/unmute methods for streams. Which is the best approach?

Let’s see what macromedia did in for play/pause :

Flash before player 9

stream.pause( )
stream.resume( )


they added a new method in player 9

stream.togglePause( )

has meaning, but you have to store the present state of the stream, that is additional code

or with muting a component

audio.mute( )
audio.unmute( )

how would a toggle look like?

audio.toggleMute( )

My components choice are the state setter methods :

stream.setPauseState( flag );
audio.setMuteState( flag );


The kickback of state setter methods that you can jumble up states in case of a badly named method. Sometimes separate on/off methods are also good.

It’s up to you

MilGra

Balance of method count and parameter count

As a young and ambitious programmer, i often faced the problem of the fragile balance between methods and parameters, and even parameter complexity.

Let’s say we have to create a server-client application system realizing a chat application with different usertypes. If there are admins and guests, and i want to keep userlist management simple, i can say that i need four functions :

addAdmin( nick )
removeAdmin( nick )
addGuest( nick )
removeGuest( nick ) 


and i also have to invoke them from the server side. So i have to touch my code eight times, which is way too much. And what if our customer wants more usertypes later? We should care about flexibility more. So what if we introduce an additional argument, called userType, and we can make our code and life much simpler.

addUser( type , nick )
removeUser( type , nick )


This seems much better now, and only four touches needed this way. But we shouldn’t be satisfied with this. What if we need more information about a user later? Ip, country, full name, e-mail address, phone number, gender and so on… ? Will we extend our definition with parameters like :

addUser( type , nick , ip , country , name , email, phone, gender );


But then i will always have to be aware of the sequence and types of tremendously lot parameters, and if i switch to server side, even the IDE won’t show me what parameters are needed, this is the perfect place for bugs and magic mistakes.

In my opinion, if a method needs two or more parameters, it’s nearly always a good practice to use a parameter object, which contains everything necessary. Method definition is simpler, and every language gives tools to iterate trough object keys and values easily.

So our present state is

addUser( infoObject )
removeUser( infoObject ) 


Can we advance this? If we have an information object, why don’t we simply put the method identifiers inside, so we will need only one client side method and one server side call. You can say that this is a fall from one extreme to another.

It would be right if we were doing client side or server side code only, but we are talking about a communication link between a server and a client, and we have to keep it clean, fast and simple. If we have one method only, the error possibilites are reduced to this point, we surely get all data on both side, and message sorting and sending to their proper places are on us. And luckily, this can be done with a simple switch..case statement, and we can easily monitor and catch invalid calls and parameters without annoying exceptions.

So our final state is

invokeMethod( infoObject )


where infoObject has

- id - value
- param1 - value1
- param2 - value2
- param3 - value3


so in case of adding an admin, it can be

- id - addUser
- type - admin
- nick - adman
- ip - 0.0.0.0
- email
- etc


One level objects are great. But sometimes you may need more complex information objects for parameters, or for parameters for parameters, well, in this case you have to be careful.

Long story short, keeping method and parameter count minimal is good in most cases. But never forget the golden rule : There is no such thing like universal solution. A new situation needs a new solution.

In the next post i will talk about cases when you may need more methods

MilGra