Developing in Flash

Here are some major steps once the specs are established with the client. Stuff here is applicable to every client/server devel context, not only Flash.


1. Making the technical specs. The specs included in the contract and the specs for the devel team are not the same. Same spirit, different form.

2. Making the app architecture starting with the client interface, then client logic, client objects, client/server comm, data objects, server logic, databases.
This paradigm of client over server is quite young, only 10 years of so, before that was common to start with database design and make your way through to user interface. This is still the modus operandi in some companies.

3. There are various development styles, two approaches that I like are cascade cycles and extreme programming. However these are applicable only on large apps. Every module should be tested using unit testing before committing into repository.

4. Testing.


What I really wanted to talk about is the client/server interface. Once at this phase, an API - Application Programming Interface - should be worked out between the client and server teams. If the approach is thin client/heavy server, the data structures most convenient to the client should have priority.

If the server load must be minimal, as often the case with small hardware budgets, costs migrate to the client. This includes for processing power, connections to other services, etc. Nowadays, when the costs for server clusters are quite affordable, and everyone seeks a broader customer base, I think thin client/heavy server is the way to go.

Although I worked server-side a few years ago (C# and Oracle) and liked it, currently I work client side only. Every part has its own advantages. server side has its heavy algorithmic thrills (data structuring, data processing, optimizing) while client side has the ergonomics, - the part that makes the human experience enjoyable -, and availability. Through connectivity you can deploy a client everywhere: mainframes, desktops, laptops, pdas, mobile phones. Flash included. Would you have considered remoting on a phone a few years ago?

Up until now my apps had a server connector that could be replaced at any time with another for another type of server. These connectors must be clever enough to handle synchronous (server-side scripts, LocalConnection, ExternalInterface) and asynchronous comm (socket), and still implementing a comfortable API with the main module. That is, the main should not care if the comm is synchronous or not.

Furthermore, the main should not care if the server is C, C#, Java, ASP, PHP, Perl or whatever. It should not care about database either, how some token data is named within the database. Having a client/server comm API, you should not rewrite your client when the server side changes something or gets changed altogether.

Should the server change when the client changes? You might know the answer already. It doesn't when the client changes involve only minor data restructuring. However this does not happen often. As changes comes from the customer, the large majority of cases requires server modules being rewritten and sometimes database restructuring.


All this comes from my experience, not from books. It may seem obvious and childish to some, but I know quite a few people who would like to contradict me. You're invited to comment ;)