Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
May 27, 2017, 10:38:55 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: [1]
Print
Author Topic: Extending Facade always means 2 facade instances exist  (Read 4862 times)
jason
Jr. Member
**
Posts: 13


View Profile
« on: January 07, 2010, 09:29:13 PM »

I'm concerned that in this implementation the facade 'singleton' is never a singleton, there are always 2 copies if you extend Facade (which I believe is what one is supposed to do?).
In java you can only hide a static object, so when you create your appFacade extends Facade, you are forced to declare your own static instance variable too. this might be ok, but the Notifier object grabs its copy of the facade object directly from the Facade class

hence it matters in what order you create appFacade and the Notifier object:
in once case it throws an error (RuntimeException("Facade already constructed")),
 and in the other it runs (except that 2 facade objects exist).

either way shouldn't there only be 1 facade instance?

I'm also concerned about thread safety in general. There is another thread here remarking on the hashmaps, but the following pattern is used to create singletons, and its not safe.

      if (instance == null) {
         try {
            instance = new Facade();
         } catch (Exception e) {
         }
      }
      return instance;

is anyone still working on or using this project?
   
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2866



View Profile WWW
« Reply #1 on: January 08, 2010, 10:04:30 AM »

We haven't seen a lot of activity on this port recently. The MultiCore port has had quite a bit of activity, though as it's being used with GWT.

-=Cliff>
Logged
jason
Jr. Member
**
Posts: 13


View Profile
« Reply #2 on: January 11, 2010, 05:41:54 PM »

We haven't seen a lot of activity on this port recently. The MultiCore port has had quite a bit of activity, though as it's being used with GWT.

-=Cliff>

I'm not sure I really understand the reason that multicore exists (it looks like there is just a map of facades instead of a singleton?).
Regardless, does a lack of activity really mean this project is dead? 
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2866



View Profile WWW
« Reply #3 on: January 13, 2010, 12:19:44 PM »

I wouldn't call it dead. It's working code. It could use some community love to crush any bugs and port utilities and demos.

But the thing about PureMVC is that it doesn't rely on lots of tricky platform specifics that cause it to have to be constantly maintained and updated. I've been working with bunch of code from PureMVC code from 2007 and 08 that after quick dusting off of the imports and a few minor best practice improvements is tooling along just fine and is just like the code I write today.

Aside from the very slight implementation differences you were noticing, the benefit of MultiCore is that it allows modular development. It is often useful to break an application into mutiple 'modules' or 'cores' that are each unaware of each other and capable of running in the same VM without conflict.

Independent modules work together to perform a task in the same way your amp, tv, dvd player and speakers work as modules to solve the 'watching a movie' problem.

Consumer wisdom says modules are the obvious way to go for a stereo system. And they can be made by different teams working at different companies. You can still get one of those 'all in one systems' but it stinks when one of the parts becomes obsolete or stops working.

But on the other hand, sometimes there's a big value to the 'all in one' plan. Like a smartphone. You don't want to tote around a separate camara, phone, mp3 player, voice recorder and pda. Smartphones are a great argument for everything in one unit approach.

The point is sometimes you want modularity, sometimes you don't. With PureMVC, you get the choice.

-=Cliff>
Logged
Pages: [1]
Print
Jump to: