[ajug-members] Who does client application work?
Summers Pittman ℝ
secondsun at gmail.com
Sat Dec 17 13:50:40 EST 2011
I've done some non enterprise applications at work this past year. Here are
I made a virtual golf game that used an Android phone and computer vision
to line up and make the shot. This application was interesting. First I
wrote a game using JMonkey in Java which would display a 3D miniature golf
course and AR tracking tags. The other half was an Android application.
The phone would determine the angle it was viewing the various tags at and
then send that information to the game server as a "stroke". The game
would hit the ball at the angle and at a force the user had selected.
For April Fools I wrote an application in Java which would monitor a video
stream and take a picture when it noticed someone's face took up a certain
portion of the frame for a while. It would then take this picture and send
it to Twitter. I then set it out with a magic eye photo and let it take
pictures of my coworkers cross-eyed and publish to the company feed.
We also made a Java Applet to facilitate printing coupons with one of our
vendors last year.
>>Phone:912 293 2314
>>Java is my crack.
On Fri, Dec 16, 2011 at 1:43 PM, <acidbriggs at gmail.com> wrote:
> We've developed a rather large, thin-client Swing application for
> The client uses technologies such as Spring (dependency injection, xml
> marshaling, authentication etc), Groovy, SwingLabs components, log4j,
> ActiveMQ etc. It worked out quite well; amazingly well actually.
> One of the biggest issues is deployment. We used Web Start, but the real
> issue is JVM deployment. We have about 1000 machines at a single hospital
> which then requires all of them to have an 'approved' JVM version. We got
> hit really hard about a year and a half ago when Sun updated their
> SwingWorker implementation in a minor update which hosed our entire
> application. I had to go back and use a version from SwingLabs and
> redeploy this to all our clients. Horrible bug in the Sun version which
> caused a deadlock. I refuse to code anything that requires a client to run
> on a specific minor version. Though, we do require anything post JDK
> 1.6u10 since there were significant additions that we relied on (Nimbus
> Look & Feel being one of them).
> Another issue can be finding people who truly understand Swing. I didn't
> know it when I started. About a year after I wished I had known more before
> I started because I did have some design issues which would have been
> mitigated early if I had understood. Having a good architectural design
> for your app is key. It's not as cut-and-dry as a SpringMVC type
> application. I had been unable to find any really good application
> frameworks to get us started. There are some, but... So, be prepared to
> design your application model appropriately. Don't keep your business logic
> embedded in your UI code. If you are creating a fat client, build yourself
> an application that doesn't require a UI. If you can build an command line
> type interface in your application I highly recommend it. I built a debug
> console in ours and it has been extremely helpful in inspecting the
> application's state.
> One major pain, that I would not do again, is incorporate Groovy into it.
> Groovy is just to much overhead for a responsive interface. You don't
> notice this on a server-side application, but you will know it when your
> app is just not responding as fast as you would like. Plus, we had a lot of
> memory leak issues with the Groovy scripting engine at the time. We
> incorporated Groovy because we needed to be able to customize some
> interface components at deployment/run-time. We created our own small DSL
> for this, and it was painful. I think I would now like to try Clojure, but
> that is just 'hey, I'd like to try it'.
> Another major annoyance in Swing (or java development in general) is how
> much code you need to write to do simple tasks, such as responding to a
> button click. You will be writing a lot of anonymous inner classes
> (listeners/delegates) which become very cumbersome since there is just so
> much boilerplate in it. If only I could have had those Lambdas when I
> wrote it! That would have made Swing dev so much nicer. I can't even
> explain how nice that would be.
> Another small annoyance is the lack of Generics in Swing. Some people say
> it's a bad idea, others want it. But, just get use to casting or creating
> your own generic table models. But, that only gets you so far.
> But, that all aside, I like Swing. I would rather do swing than write a
> testable. Keep that in mind. Your interfaces should be isolated from each
> other and communicate via observers. Just about every design pattern you
> have ever read is in Swing. It's an awesome way to learn them.
> Oh, and always remember that all your UI updates should be done on the
> event-dispatching thread!
> SwingUtilities/EventQueue is your friend (when Sun/Oracle doesn't break
> Read the docs on how cell renderers work.
> There is a lot more, but it is fun.
> On Dec 16, 2011, at 11:06 AM, Summers Pittman ℝ wrote:
> > I've noticed that there are many of us who build web applications
> running Java (in my case a gigantic financial app) or work with companies
> who make Java libraries (in Gunnar's case Spring Source) for use in web
> applications. I was wondering if anyone was working on client
> applications? Not web applications but apps which run on the desktop (or
> Android or maybe an Applet) Java applications.
> > What technologies do you use? What problem are you trying to solve? How
> is it working out?
> > Summers Pittman
> > >>Phone:912 293 2314
> > >>Java is my crack.
> > _______________________________________________
> > ajug-members mailing list
> > ajug-members at ajug.org
> > http://www.ajug.org/mailman/listinfo/ajug-members
> ajug-members mailing list
> ajug-members at ajug.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ajug-members