I was able to achieve same using other layout (e.g. LinearLayout) by adding clickListener to child LinearLayout.
<LinearLayout>
<LinearLayout>
<ImageView>
<TextView>
</LinearLayout>
<LinearLayout>
<ImageView>
<TextView>
</LinearLayout>
</LinearLayout>
How to achieve same using ConstraintLayout? Is there any way to avoid nesting w less performance overhead?
Related
I have a N-layer solution that works correctly in my dev environment. Apparently it works also on production environment, but sometime the execution fails. I do not understand why. I just know that nothing changes on database, no usefull error is visible and no log is written.
My supposition is a concurrency problem. I think that something fails when I try to do more than one select once the entity framework context has been initialized.
Here how my solution is structured
In the facade I inject the entity framework context. Here the configuration on my web.config of the service interface:
<containers>
<container>
<types>
<register type="it.MC.IContext.IDataContext, IContext"
mapTo="it.MC.EntityFrameworkContext.PublicAreaContext, EntityFrameworkContext">
<lifetime type="singleton" />
</register>
<register type="it.MC.IFacade.IPublicAreaFacade, IFacade"
mapTo="it.MC.Facade.PublicAreaFacade, Facade">
<interceptor type="TransparentProxyInterceptor" />
<lifetime type="singleton" />
<constructor>
<param name="context" type="it.MC.IContext.IDataContext, IContext"/>
</constructor>
</register>
</types>
</container>
</containers>
As you can see, my context and the facade are singleton. I think both are really wrong. I think that both Facade that the entity Framewrk context should be instanciate per request. I think this will solve the problem of the concurrency too.
Can anyone help me to correct my code please?
Thank you
I know that your question is:
Can anyone help me to correct my code please?
I read it like this:
Can anyone help me change this code so that IContext and IFacade will be re-initialized per request.
With that said... Yes, I also doubt that you want to keep your IContext as a singleton.
Why you shouldn't use singleton DataContexts in Entity Framework
Here's how you can change the lifetimemanager to PerRequestLifetimeManager, if that's what you want. Note that you probably need the Unity.Mvc NuGet-package.
<containers>
<container>
<types>
<register type="it.MC.IContext.IDataContext, IContext"
mapTo="it.MC.EntityFrameworkContext.PublicAreaContext, EntityFrameworkContext">
<lifetime type="Microsoft.Practices.Unity.PerRequestLifetimeManager, Microsoft.Practices.Unity.Mvc" />
</register>
<register type="it.MC.IFacade.IPublicAreaFacade, IFacade"
mapTo="it.MC.Facade.PublicAreaFacade, Facade">
<interceptor type="TransparentProxyInterceptor" />
<lifetime type="Microsoft.Practices.Unity.PerRequestLifetimeManager, Microsoft.Practices.Unity.Mvc" />
<constructor>
<param name="context" type="it.MC.IContext.IDataContext, IContext"/>
</constructor>
</register>
</types>
</container>
</containers>
Before moving to production I suggest you read this post about the PerRequestLifetimeManager.
Its purpose would be to only instantiate one instance per request,
which could (for example) prevent redundant operations and lookups
during the course of a single request.
The danger is if someone assumes that the object created is a good
place to store state during the request. The idea of dependency
injection is that a class receives a dependency (commonly an
interface) and doesn't "know" anything about it at all except that it
implements that interface.
Also, think about the Facade you got, and how it will work if it's re-initated every request. Does it perform any heavy operations at initialization? You might want to think about the lifetimemanager for that one.
UPDATE
Since you're using WebAPI you should be able to use HierarchicalLifetimeManager instead.
http://www.asp.net/web-api/overview/advanced/dependency-injection
The dependency resolver attached to the HttpConfiguration object has
global scope. When Web API creates a controller, it calls BeginScope.
This method returns an IDependencyScope that represents a child scope.
Web API then calls GetService on the child scope to create the
controller. When request is complete, Web API calls Dispose on the
child scope. Use the Dispose method to dispose of the controller’s
dependencies.
http://www.devtrends.co.uk/blog/introducing-the-unity.webapi-nuget-package
If you are registering any components that implement IDisposable such
as Entity Framework's DbContext, you will want to make sure that these
components get disposed of at the end of the request. This is achieved
by registering these components with a HierarchicalLifetimeManager.
is it possible to override the deferred binding configuration of a inherit module?
Here is a example:
In the module, I want to use, a deferred binding is declared as follows moduleA.gwt.xml:
<replace-with class="A1Impl">
<when-type-is class="A"/>
</replace-with>
<replace-with class="A2Impl">
<when-type-is class="A"/>
<when-property-is name="p" value="1"/>
</replace-with>
The declaration says: Use A1Impl class as default and A2Impl class, if property p has the value 1.
Now, in my app I want to use that module and want P to be 1 (because this controls the above shown, but also a lot of other deferred binding configurations) mymodule.gwt.xml:
<inherits name='moduleA'/>
<set-property name="p" value="1" />
But additionally I want to override the deferred binding configuration of the inherit module to use my own implementation of A. I tried something like this in my module, but it didn't work:
<replace-with class="B1Impl">
<when-type-is class="A"/>
<when-property-is name="p" value="1"/>
</replace-with>
It should say something like this: Do not use A2Impl (declared in inherit module) if property p has the value 1 but use my own implementation B1Impl instead.
Is this possible?
Thanks in advance for any help.
In short, yes, you can redefine any rebind rules that have already been set. Simply inherit the module you are changing, then make your changes after that rebind rule.
<inherits name="package.to.ModuleA" />
<set-property name="p" value="1" />
With the code above, p is always 1, so setting specific rules about what p will be is a little bit silly. Unless p is ever able to be something other than 1, you really don't even need the when-property-is rule.
Your replace-with looks correct as long as it is listed after your inherits statements. For this reason, I always encourage developers to list all inherits rules first, and then go on to any replace-with and generate-with or set-property rules.
For more detail than that, you'll need to post something a little more concrete.
I am using latest mybatis release i.e. mybatis3.2.2.
I have converted our old application which was on EJB CMP to mybatis, in which the newly converted mybatis code performance was much worse than the old code with EJB CMP.
Configuration settings of mybatis is as follows:
<settings>
<setting name="cacheEnabled" value="false"/>
<setting name="aggressiveLazyLoading" value="false" />
<setting name="lazyLoadingEnabled" value="true" />
<setting name="jdbcTypeForNull" value="VARCHAR"/>
<setting name="defaultExecutorType" value="REUSE"/>
<setting name="defaultStatementTimeout" value="25000"/>
</settings>
While analyzing performance issue through YJP profiler, I realized that HashTable.put(<mybatis returned Pojo>, <value>) methods were taking most of the time and seemed to be the only bottoleneck.
In the HashTable.put() method, we are putting Pojo returned from mybatis as a key. In which call, in turn it calls hashCode of that pojo, and from YJP I could see that in 'hashCode' method, it is calling 'org.apache.ibatis.executor.loader.CglibProxyFactory$EnhancedResultObjectProxyImpl.intercept(Object, Method, Object[], MethodProxy)', which is actually seemed like calling jdbc drivers and loading this pojo properties and those are the once taking all of the time.
Can any please help and guide me as in why mybatis is trying to load the Pojo while putting into HashTable in its hashCode method? Also, how can we improve its performance if at all we can.
Also, I tried to override 'hashCode' & 'equals' methods into my Pojo and used/compared only primary key properties, but it seems to have no effect, it is still calling 'executor.loader' of ibatis and doing same thing.
Ok, I have finally found the solution.
The 'lazyLoadTriggerMethods' setting configures the methods that trigger lazy loading.
By default it triggers lazy loading for 'equals,clone,hashCode,toString' methods.
I configured this property in SqlMapConfig.xml and removed 'equals,hashCode,toString' methods from it, as:
<settings>
<!-- below both entry required to achieve on-demand lazy loading -->
<setting name="aggressiveLazyLoading" value="false" />
<setting name="lazyLoadingEnabled" value="false" />
<setting name="jdbcTypeForNull" value="VARCHAR" />
<setting name="defaultExecutorType" value="REUSE"/>
<setting name="defaultStatementTimeout" value="25000"/>
<setting name="lazyLoadTriggerMethods" value="clone"/>
</settings>
Note: You should only do this when you are sure that the hashCode and equals implementation does not use lazy-loaded properties or uses the accessor methods for reading lazy-loaded properties.
It dramatically increased performance.
Thanks,
Parag
Is it possible to dynamically add and register new attributes to mbean
eg :
<server>
<mbean code="org.jboss.example.MyMbean" name="jboss:service=myMbean,name=MyMbeanExample">
<attribute name="attribute1">value1</attribute>
<attribute name="attribute2">value2</attribute>
<attribute name="attribute3">value3</attribute>
<attribute name="attribute4">value5</attribute>
<attribute name="attribute5">value5</attribute>...
</mbean>
</server>
A new attribute added in jboss-service.xml should be registered in MyMbean dynamically with making any code change in Mbean, can this be done?
Thanks in Advance.
It's hard to answer your question without seeing the code of your DynamicMBean, but I suspect the answer to your question, with the proviso that there be no code changes in the MBean, is no. However, here's an overall approach (taking some liberal assumptions about your code):
A DynamicMBean like this will usually have some sort of map, keyed by the attribute name, and and containing either the value of the attribute (easy), or a value object containing some or all of the following intended to acquire/set the value of the attribute:
a target invocation object,
a method
an array of arguments to the method
When the MBeanInfo of the MBean is requested, the supplied MBeanAttributeInfos should reference the keys in this map (as well as the data type, mutability etc.) You can either generate these on the fly every time MBeanInfo is requested, or keep an updated collection of MBeanAttributeInfo which is updated whenever you add a new attribute.
The methods setAttribute and setAttributes should create a new attribute (by inserting the new key and value into the attribute map) if the set references an attribute that does not already exist.
Since you're using JBoss, if you feel you might want to implement something like this, consider extending JBoss's ServiceDynamicMBeanSupport. It does some, but not all, of the legwork for you.
How do you architect the CF backend model w/ NoSQL that are simple, flexible, efficient and clean?
Since NoSQL doc has no fixed schema like SQL row, it doesn't really fit well with Objects which are rather static. Therefore the typical Bean+DAO+Service OOP architecture doesn't seem to fit well.
I'm thinking of using plain old Struct's, but then I cannot add behavior onto it and it's going to make the whole project very procedural, which may not be a bad thing?
However, if I just use plain old struct, the DB implementations is leaked everywhere including the View layer...
Or... shall I translate the array's into CF's Query object for the View layer?
Comment? Idea? Suggestion?
Thanks!
I've written a couple applications in CF that use NoSQL datastores - one uses the Google App Engine datastore, and another with MongoDB.
In both cases, I made CFCs to act as my objects. But, I used a homegrown object "framework" that uses onMissingMethod for accessors, and cfproperty with lots of custom metadata to define properties of the objects.
For instance, this is all I NEED to define for a model, unless it has custom business logic:
<cfcomponent output="false" persistentLayer="GAE" persistentClass="asana" extends="com.bespokelogic.framework.BaseModel">
<cfproperty name="id" type="string" persistentDatatype="string" settable="true" gettable="true" required="true">
<cfproperty name="deckSet" type="string" persistentDatatype="string" settable="true" gettable="true" default="basic">
<cfproperty name="englishName" type="string" persistentDatatype="string" settable="true" gettable="true">
<cfproperty name="traditionalName" type="string" persistentDatatype="string" settable="true" gettable="true">
<cfproperty name="pronunciation" type="string" persistentDatatype="string" settable="true" gettable="true">
<cfproperty name="anatomicalFocus" type="array" persistentDatatype="array" settable="true" gettable="true" default="#arrayNew(1)#">
<cfproperty name="therapeuticFocus" type="array" persistentDatatype="array" settable="true" gettable="true" default="#arrayNew(1)#">
<cfproperty name="benefits" type="string" persistentDatatype="string" settable="true" gettable="true">
<cfproperty name="variations" type="string" persistentDatatype="string" settable="true" gettable="true">
<cfproperty name="contraindications" type="array" persistentDatatype="array" settable="true" gettable="true" default="#arrayNew(1)#">
<cfproperty name="skill" type="string" persistentDatatype="string" settable="true" gettable="true">
<cfproperty name="instructions" type="string" persistentDatatype="string" settable="true" gettable="true">
</cfcomponent>
The CFCs all extend a base model which has validate, serialize, deserialize, and virtual getter/setter methods.
Then, I have a persistence layer that knows how to get and put objects from/into the datastore.
I would then write a service for each of the models which utilize the persistence layer.
The upshot is that the models know how to serialize their property data, and the persistencelayer knows how to put that into the datastore.
So, in a sense, its not an object-relational manager, but more of an object-document manager.
The framework's a lot more full featured in reality, as my design was that I take some models, and persist them in SQL, some in NoSQL, all in the same application - and I could swap out the underlying datastore with no recoding of the app. It was a partial success.
In your case, if you're using a single datastore, you can skip all that complicated stuff.
You just need a base object which knows how to serialize and deserialize models, and you getter/setter stuff. Decide how you want to store property data in the CFC. I used a struct called "variables.instance._properties{}"
Then write a service for your model(s) that has "put" and "fetch" methods. The "put" method, for instance, takes a model, calls the "serialize" method on it to turn it into JSON, then stuffs it into Mongo. The "fetch" method gets the Mongo record, creates a new instance of the CFC, and passes the Mongo record to the deserialize method.
That was pretty rambling...
TL;DR: "Objects in CF (such as they are) are not really all that static. Use CFCs. Use onMissingMethod to allow dynamic properties. Store properties in a way that allows you to serialize and deserialize them into a format (usually JSON) that is easily digestible by your datastore. Write a simple persistence layer that gets and puts documents to/from the datastore. Write simple services which implement your persistence layer and take and return you dynamic models.
CF's pretty well suited for NoSQL in my opinion.
I've settled with Proxy object (that has an embed 'instance' struct). The DAO layer just use getMemento() & setMemento()
I also used an Iterator object for iterating through an array of results.