Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1]
1  PureMVC Manifold / MultiCore Version / Re: Android: Activity Management in PureMVC on: July 13, 2011, 09:59:34
I've been experimenting a lot lately with this,
so far I have my facade hanging from the androidApplication,
I have proxies connected via a broadcast receiver locally instantiated in my proxy class, to services running in other processes. I tried variously to use the aidl mechanism but it was not reliable from the applicationcontext.
i have mediators(POJO's) that either call startActivity or PendingIntent.send. When an Activity is started the Activity creates
an Observable, then does a lookup from the facade for the current mediator instance and sets itself as the view. it also creates a Pendingintent and hands it to the Mediator.

because the Mediator is not an activity and does not have an Activity context, each time startActivity is called, a new copy of the Activity is created. So the pending intent reduces this pain somewhat. if its not null, then its used to callback to the existing activity directly.

I'm now experimenting with roboguice for context injection instead of directly accessing the ApplicationSingleton. I dont like all the annotations and total incursion of roboguice in my code, but I'm not aware of any other DI options, and roboguice can simplify context management quite a bit. I'm also considering basing my mvcApplication in a service instead of the applicationContext itself, since binding from a service context seems more reliable and more Androidy.
I'm currently toying with injecting the roboguice ActivityProvider directly into my mediator, as this could finally provide a reliable communication mechanism between the mediator and view that does not demand endless recreation of the Activity. Lets see how well it works in practice.
Next step is to get jbpm5 working, I've seen one post online and apparently it only needs a minor tweak to run in android.

2  PureMVC Manifold / MultiCore Version / Re: request for small mod to facade api on: July 13, 2011, 09:25:09
Not really sure why the ordinary startup process of creating and registering mediators doesn't work.

the ordinary startup mechanism is not very DI friendly, with spring at least I'd have to use methodinvokingfactorybeans all over the place, and it would not be worth the trouble or mess, and I'd still have no way to clean up. PureMVC all by itself makes no attempt to call onRemove for components when it shuts down or a core is removed, so if it needs to be done at all, it needs to be done manually for each component.

if anyone has a better/alternate approach I'd love to hear about it.

3  PureMVC Manifold / MultiCore Version / Re: request for small mod to facade api on: July 13, 2011, 09:11:52
1. I want to be able to dependency inject my proxies, commands, mediators.
2. I want to be able to specify an initial configuration/register required components at startup.
2. I want to clean them up again without manually managing the process as much as possible.

so for example I have inside a spring context something like this:
 this MUST be initialised before any mediators
   --><bean  id="applicationFacade" class="com.my.application.ApplicationFacade" factory-method="getInst" init-method="start">
    <property name="app" ref="demoApp"></property>
    <property name="mediators">
        <ref local="appMediator"/>
    <ref local="homeUIMediator"/>
    <property name="models">
    <ref local="propertyProxy"/>
     <property name="commands">
    <ref local="propertyChangeCommand"/>
    <ref local="botStateChangeCommand"/>
        <ref local="startupCommand"/>

  <!-- MVC Command Beans -->
<!--I chose to define my command mappings in code
but could have used a Map structure here instead, or I could have embedded the notification Name in
each of my command classes(not good if u have same command class associated with different notifications in different cores or projects, but otherwise fine).
<property name="commandMappings">
    <entry key="abc" value-ref="myCommand"></entry>
   <bean id="startupCommand" class="com.my.mvc.controller.StartupCommand">
     <constructor-arg value="${multitonControllerKey}"/>
     <property name="propertyChangeCommand" ref="propertyChangeCommand"/>
     <property name="botStateChangeCommand" ref="botStateChangeCommand"/>
     <property name="loadDataCommand" ref="loadDataCommand"/>
     <property name="homeUIView" ref="homeUIView"/>
... etc

then in StartupCommand I have something like :
   ApplicationFacade facade=(ApplicationFacade) getFacade();

       //just register everything
       for (IMediator mediator : facade.getMediators()) {

for (IProxy proxy : facade.getModels()) {
        facade.registerCommand(Command.PROPERTY_CHANGED.name(), propertyChangeCommand);
        facade.registerCommand(Command.STATE_CHANGED.name(), botStateChangeCommand);
        facade.registerCommand(Command.LOAD_USER_DATA.name(), loadDataCommand);

so it makes my code much more manageable, makes the spring config straightforward, and makes puremvc more easily springy/DI-able.
instead of having each of my components aware of a shutdown notification, I override onRemove in each
them (why doesnt ICommand have an onRemove?) in a single Shutdown command, iterate all of the components and remove them.
if I could do this without needing to maintain a separate list, and I could get access to the current list of
registered components it would be quite helpful.

At least like this I can use DI for all my components, inject those into the facade, my code does not require knowledge of spring, my config files are reasonably readable, and I dont have to worry about forgetting to register/unregister something.

I hope this makes sense.

fyi I'm currently using a similar mechanism with roboguice + puremvc in Android. more painful, and more incursion but thats just guice.


4  PureMVC Manifold / Bug Report / Re: onRemove NEVER called on: July 12, 2011, 06:24:24
The fix is of course trivial, and I've fixed my copy, but I guess your build/test process may take some time to sort.
5  PureMVC Manifold / MultiCore Version / request for small mod to facade api on: July 12, 2011, 06:15:53
Hi All,
 I've been using puremvc here and there for a while now and like lots of what it has to offer,
 (dont like all the boiler plate though).
I also use spring a lot, and in order to properly springify things I found it convenient to be able to get/set Lists for registered Proxies, Mediators, and Commands. I end up creating duplicate Lists of each, with getters & setters in my ApplicationFacade, which are injected directly by spring, and then I do something like this in the spring afterPropertiesSet:
   public void afterPropertiesSet() throws Exception {
      for (IMediator mediator : instance.mediators) {
      for (IProxy proxy : instance.models) {

      registerCommand(MVCCommand.STARTUP.name(), startupCommand);


I also then just iterate these lists in a shutdown command which saves boilerplate and ensures I unregister everything.
ie I dont have to maintain a list of stuff like this: getFacade().removeCommand(MVCCommand.SHUTDOWN.name());

It would be easier if the facade had getCommands(), getProxies(), getMediators(), and would be really nice if there were also a
setProxies(List<IProxy> proxies),
setCommands(Map<ICommand,String notification>) etc too so I dont have to create duplicate lists.

6  PureMVC Manifold / Bug Report / Re: onRemove NEVER called on: July 12, 2011, 05:46:57
: Tek link=topic=1921.msg8562#msg8562 date=1310508744

I don't understand how the tests have passed. I do not have time right now but it needs some attention as [url
http://trac.puremvc.org/PureMVC_Java_UnitTests/browser/tags/UnitTests_1_0/src/org/puremvc/java/core/ModelTestProxy.java[/url] is designed to test this.

right, I saw this test too, but double checked both versions to be sure I wasn't delirious.
The test look fine, so I guess they must not be executed, I didn't try it myself because the tests are inconveniently packaged in another download so I just looked over them online.
7  PureMVC Manifold / Bug Report / onRemove NEVER called on: July 11, 2011, 11:17:39
the basic java port of puremvc has been around for years.
Has nobody else noticed that Proxy core Mdel never calls onRemove when proxies are removed?
Same is true of both the Single and MultiCore versions.

8  PureMVC Manifold / MultiCore Version / Re: Why doesnt this port use concurrentHashMaps? on: March 02, 2010, 11:48:04
if the new 'threadsafe' code is blocking though it would be a real shame.
perhaps you need to use the Map interface only, and allow a mechanism for selecting the correct runtime
wiring (GWT, or jvm1.5+) .
alternatively has anyone tried retroweaver for converting modern java bytecode to java 1.4 compat bytecode? ref:http://retroweaver.sourceforge.net (I havent, no idea if it would work)
if it worked you could just add this as a secondary post build target to generate a gwt compatible variant.

9  PureMVC Manifold / MultiCore Version / Re: State Machine utility planned? on: March 02, 2010, 11:38:00
I'm just using jbpm and spring.
I just created a FSMMessageHandlerCommand command, which interacts with jbpm.
config is all spring+jbpm.
works fine.

10  PureMVC Manifold / MultiCore Version / Re: Why doesnt this port use concurrentHashMaps? on: January 31, 2010, 05:16:51

read to the comments at the bottom of the article. cchashMap is safe and works as intended.
it wont fix other problems in your code though of course.
My point here is that the current version blocks unnecessarily, and is also trying to do something that doesn't make any sense. perhaps it should be restructured such that it really is a factory?

incidentally, methods such as  Facade.removeCore are not threadsafe at all, as they are modifying an unmanaged hashmap.

same applies for the controller, model and view classes too!.

11  PureMVC Manifold / MultiCore Version / Why doesnt this port use concurrentHashMaps? on: January 29, 2010, 12:26:57
Hi, I'm wondering why this port doesnt use ConcurrentHashMaps instead of HashMap+synchronized block?

for example in the Facade.getInstance method, its synchronized which has gotta be bad for performance
since its a commonly accessed method.
also, why does it bother to generate a "new Facade(key)" if one isnt provided? if it hasnt been subclassed then the app cant be using puremvc as its intended, and if it has been subclassed then creating this new Facade is a waste of effort.

at any rate to keep existing functionality, wouldn't replacing the instanceMap with a concurrenthashmap and reworking the method something like this make sense?
public static Facade getInstance(String key )
if (key== null) {
            throw new Exception("key cannot be null.");

 Facade facade, newVal;
    do {
      facade= instanceMap.get(name);
      newVal = (facade== null) ? new Facade(key):facade;
    } while (!instanceMap.replace(name, facade, newVal));

        return newVal;


12  PureMVC Manifold / Standard Version / Re: Extending Facade always means 2 facade instances exist on: January 11, 2010, 05:41:54
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.


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? 
13  PureMVC Manifold / Standard Version / Extending Facade always means 2 facade instances exist on: January 07, 2010, 09:29:13
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?
Pages: [1]