It's Singleton, not Simpleton...dummy!

Monday, November 24, 2008

Bulky Data Transfer with Single Hit vs Light Data Transfer with Multiple Hits

This is a classic dilemma. What is a better model for browser based clients and back-end services to interact? Should there be as little dialogue as possible with maximum data transfer or as much dialogue as possible with minimum data transfer in each exchange of request-response. The problem is not as simple to solve as the problem statement makes it sound.

There are various parameters that need to be considered for answering this question. And the solution varies as per the requirements.

Let's start with considering a revolutionary example: Gmail!

As we are aware, Google employed the AJAX philosophy and created the first ever AJAX based email application that changed the paradigm of web mails, by increasing the performance of reading, composing and sending emails over the internet. The browsers were same as before, the bandwidth was the same but the application architecture had changed drastically, making more possible with the same set of resources.

However, it was not just about using a new technology but identifying the appropriate problem that this technology could solve. In an email type web application, a user generally performs units of tasks with every click.

  • Open a mail for reading,
  • Compose a mail/reply,
  • Add / Remove the attachments and
  • Send the mail.
It never happens that a user is reading a mail that is being modified by the sender simultaneously. So, there is no real time change in an email's content.

If at all there is a modification required to the content of an email that was already sent/delivered, one needs to re-send the mail with the modifications. In this scenario, fetching each mail's content as and when the header of the mail is clicked makes sense, and doing it asynchronously (i.e. without refreshing the whole page) makes the usability far more intuitive and elegant.

On the other hand, is an application that shows data that is highly likely to be modified at the same time when a user is viewing the information, such a model of conversation may not really work.

Say, you have an application that displays data in the grid where rows and columns are collapsible and contain levels of information (something like a hierarchical data set). See the example.

The grid's cells don't enjoy absolute independence from the other rows and columns of data surrounding it. In other words, each cell of information is not just an atomic information in itself, but also forms a part of the information that is at a level higher than it. For instance, Physical Supply of 100 could mean there is a PO of 50, POK of 30 and TO of 20, which are all displayed as the child levels of Physical Supply. Now, in case there was a new PO of 20 created by some user, while the data mentioned above is on display in the SCP, by showing an additional 20 for PO i.e. PO of 70 would not be enough to represent the actual state of Supply Chain because, the sum of quantities for different Documents (70+30+20 = 120) would be incosistent with the total being shown for the Physical Supply (50+30+20 = 100).

With this problem at hand the requirement would be to update all the cells in the row and column that contain the modified cell, as part of calculating the summary for that row and column respectively. This requirement in turn requires us to keep a track of all the cells in the grid because the probability of any cell getting modified at any given time is almost equal, therefore any row and column could be required to be refreshed with the latest data.

Essentially, each cell update leads to an update of almost all the cells in that section (sections here refer to the parent rows viz. Demand, Suppply, Recommendations etc.) We could therefore limit the updates of a cell leading to the update of just the section in which it lies. This in turn would lead to a different kind of inconsistency. For instnace, a Demand of 30 and a Supply or 20 leads to a Recommendation of 10 and a Projected Inventory of -10. This means that even the sections within the SCP grid are interdependent therefore any cell that has to show updated data, would require all the other cells in the grid to update the data, directly or indirectly.

So, it is pretty clear that the data in the entire grid has to be treated as a whole in order to view a consistent information in the Supply Chain Profile at any given time. The rendering of data, however, doesn't need to happen in a single shot because like viewing a section or a particular row or column or a cell in particular, is quite similar to checking one's inbox for a specific email. And once that email is located, all one cares about is reading the information within. Similarly, a user will only follow a single path for drilling down information about the SCP at any given time. This in turn leads to a simple requirement of rendering data (cells, rows, columns) only for the particular paths.

The conclusion or the solution for our problem is to fetch the entire data in a Single Hit to the server, and then use selective and efficient rendering of the data based on where user clicks on the UI. We can and have tried to make the cell specific information (which is shown in the pop-ups) asynchronous, but that leads to holding the state of the data object that was transported to the client earlier. This leads to additional memory and state management requirements on the back end. Therefore, we chose to send the information in a bulk to the front end. This might be slightly slower but it represents the state of SCP accurately and consistently always and everytime.

Wednesday, November 5, 2008

Calendar getDisplayName() JDK 6.0 vs JDK 1.5.0

If you have somehow used jdk6.0 while developing your application that uses Calendar API of java.util.Calendar, and have used getDisplayName method to extract the display names for fields of the calendar, specific to your desired style and locale, and then had to compile your application with jdk1.5.0 only to realize that compiler spits swear words at you...Here is quick fix for you!

This is what you did in jdk6.0:

//get your application locale
Locale userLocale = getContext().getLocale();

//define a calendar
Calendar calendarInstance = Calendar.getInstance();

//Extract the month name in SHORT format (viz. "Jan","Feb" etc.) for the context locale.
calendarInstance.getDisplayName(calendarInstance.get(Calendar.MONTH),Calendar.SHORT,userLocale);


Here is what you can do to achieve the same getDisplayName functionality in jdk 5.0:

//import the following class
import java.text.DateFormatSymbols;

//declare variable.
DateFormatSymbols dateFormatSymbols = new DateFormatSymbols();

//Get the short names for months in a Calendar
String[] months = dateFormatSymbols.getShortMonths();

//Use the month field of Calendar to fetch the short name of month for cell label.
months[calendarInstance.get(Calendar.MONTH)];



Once you acquire the SHORT name for the field, you can use it for your labels, or column headers etc. based on where you require it.

Ideally, you shouldn't have to fall back on the previous version of jdk, yet sometimes the project requirements can't be altered even for better things in life.

Hope this tip helps!

Tuesday, April 22, 2008

Flex Builder 3 - LiveCycle Data Services - Libs

I would never have been writing this post in addition to so many others that are already there talking about how to build, compile, deploy, run your flex applications that use Live Cycle Data Service, had I not spent last five days trying to figure out why my application wouldn't compile when I was following all the steps mentioned everywhere.

I might be dumb for not having known something that was obvious; that one must know in order to build applications in flex, so I concede. However, there might be my other dumb brethren out there who might be struggling with the same things, so this one is for you fellas!

After migrating the flex app that was built on Flex Builder 2 by my associate, some time last year, around October/November, I was facing a few issues in getting the application to compile.

Some of the errors were as follows:

Type 1:
1172: Definition mx.data.utils:Managed could not be found.
or
1172: Definition mx.data:IManaged could not be found.

Type 2:
Unable to resolve resource bundle "data" for locale "en_US".

Now first of all when you start Googling, you come across the following links (that are relevant):

http://bugs.adobe.com/jira/browse/ASC-2815

http://www.mail-archive.com/flexcoders@yahoogroups.com/msg38973.html

http://www.mail-archive.com/flexcoders@yahoogroups.com/msg66002.html


And even though these have been written with the intention to help out the newbies in the flex world, they don't really shed light on what might be the cause of this problem and/or how to fix it. The problem is indeed far simpler than the complicated discussions on the "Known Issues" and "Hot Fixes".

All I need to know is, where is that goddamn missing library that I could include in my build path to resolve these issues.

If you have been following the instructions elsewhere, you probably already have gone through all the treacheries that I have gone through so you can relate to the frustration I am talking out of.

Well having said and done all that I have, here is what you need to do in order to get those libraries into your classpath.

The location where you installed your Live Cycle Data Services, let's call it [lcds-install-path].

Under [lcds-install-path] you will find a war file called samples.war. If you can't see it, download the Data Services afresh from an authentic source and install it.

Now the reason I referred to this samples guy was because I wanted to make sure if anybody had ever tried to accomplish what I had set out for with the Flex SDK3.0 and Data Services. (I realized later that what I was trying to do was not something that was rarely used, but something that is used so often that it is taken for granted that people who can't get it right, like me, are just too dumb to work on Flex Applications.)

Procedure for alleviation:
  1. Create the following directory [lcds-install-path]/flex/libs
  2. Create the following directory [lcds-install-path]/flex/locale
  3. Create the following directory [lcds-install-path]/flex/jars **
  4. Expand or explode (suit yourself) [lcds-install-path] /samples.war to [lcds-install-path]/samples
  5. Go to [lcds-install-path]/samples/WEB-INF/flex/libs and copy everything.
  6. Paste the files copied into [lcds-install-path]/flex/libs
  7. Go to [lcds-install-path]/samples/WEB-INF/flex/locale and copy everything.
  8. Past the files copied into [lcds-install-path]/flex/locale
  9. Go to [lcds-install-path]/samples/WEB-INF/flex/jars and copy everything. **
  10. Past the files copied into [lcds-install-path]/flex/jars **
  11. Go to flex builder, and edit the build-path.
  12. Add [lcds-install-path]/flex/libs as an SWC folder.
  13. Add [lcds-install-path]/flex/locale as an SWC folder.
  14. Add [lcds-install-path]/flex/locale/en_US/fds_rb.swc as an SWC
  15. And now your application should compile!
** - optional for now, may be needed for something in future, who knows?

If this doesn't work still, you need to take a break and hire someone smarter to help you out.

The reason I copied all the files to a custom location was that it will keep me aware of where I need to make changes in future and also might give some hint to Adobe Team to include a separate folder in the LCDS distribution that contains all the mandatory libraries.

Hope that help you my dumb-friends. If it doesn't you can mail me at remotemethod@gmail.com and I will try to help you out with some more "Flex for Dummies" tips if I can.

Here are some related links that might help:
http://www.adobe.com/devnet/coldfusion/articles/data_app.html

Wednesday, April 16, 2008

Pitfalls In Java Development and More

Hi guys, here is a super cool blog recently launched by my friends and colleagues at Pramati.

http://pitfalls.wordpress.com

The blog is named as Pitfalls in Java Development, but it doesn't limit the content or the description to just the pitfalls; there are amazingly new and refreshing facts about Java Technology and all its associated open source technologies.

You will also find quite a few interesting debates on DOs and NOT TO DOs in the Application Development world of Open Source and Java/J2EE. All of the authors on the blog are experts in their respective domains and technologies and share the most recent issues they encounter while working on their current assignments.

In less than two weeks since it was launched, it has reached a hit count of 3000 approx. Which in itself is an indication of how techies about the value of information shared by this blog. And to those of you for whom it matters, the CTO at Spring Source Adrian Colyer has already commented on one of the posts on this blog.

I am sure you are going to learn a lot from this single link. So check it out now!