I notice that there are two Android methods with the same names and parameters:
Android.app.Activity.onConfigurationChanged(Configuration)
Android.app.Application.onConfigurationChanged(Configuration)
All of the documentation I can find (such as Handling Runtime Changes) seems to refer to the method in the Activity class. What is the relation between the two methods? For example, if an Activity is specified in the manifest as handling configuration changes, is the Activity's onConfigurationChange method called, then the Application one, or vice versa?
Since the documentation doesn't indicate the order of the calls, you shouldn't rely on the order of the calls.
You could look at the source code for Android to determine this, but since it isn't documented it could change in the future, therefore you shouldn't rely on this.
Related
I am digging into the Rest API methods. In my experience I always use/see four methods in my projects, Methods are - GET, POST,PUT, DELETE
Refer:
I have try to understand the methods and below is my understanding
COPY - this will copy an resource, like if I want to copy an object or
entity on server I can use it.
HEAD - This method returns no body and provide the activeness of
endpoint/resource
OPTIONS - This method basically show which API method is allow on
current endpoint, this we can see in header -> ALLOW key
LINK - This method link one object to another object. Basically
establish an relationship between two entity/object
UNLINK - This method unlink one object to another object. remove
relationship between objects.
PURGE - No clue
PROPFIND - No clue
VIEW - No clue
Kindly correct me if my understanding is not correct on any above method, please add if I missed anything and kindly explain method like PURGE, PROPFIND , VIEW
REST (the architectural style) doesn't specify any methods -- it only says that the interface of resources should be uniform, meaning that all resources share the same understanding of the semantics of the methods.
HTTP defines an application for transferring documents over a network; that specification describes a number of methods that are included in the uniform interface of HTTP resources.
It also defines procedures for extending the vocabulary of methods.
The Hypertext Transfer Protocol (HTTP) Method Registry documents the standardized methods, and includes links to the documents in which the semantics of registered methods are defined.
There's a good history of the registered methods here.
PURGE seems to be an unstandardized method discussed in the context of squid and varnish.
I used #subcomponent mostly for case activities need to use some shared objects from application component, or fragments components want to use some objects provided by container activity.
Now I am wondering if I can make some activity components be subcomponent of another activity component. For example, the TaskDetailActivity has a task object and want to provide to some other activities such as TaskParticipantActivity, TaskProgressActivity and some fragments.
The traditional way to provide task object to other activities is set it into intent object, but how about if we want to use Dagger2 for this case?
Update: my sistuation similar with the case of UserScope in this article http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/, but instead of saving the user component in Application class, can I save in an activity, i.e TaskDetailActivity?
Components are for grouping objects of a similar lifecycle. While Components may happen to correspond to a particular set of functionality (like a TaskComponent for injecting a TaskActivity and a TaskPresenter) it is not always possible or desirable to insist on only one Component per set of functionality (for instance, insisting on only one TaskComponent for all task related activities and dependencies).
Instead, in Dagger 2 re-usability is available through Modules which you can very easily swap in and out of Components. Within the constraints of the advice for organising your Modules for testability in the Dagger 2 official documentation you are able to organise Modules congruent with your functionality (e.g., a TaskModule for all-task related dependencies). Then, because Components are so lightweight, you can make as many as you like to deal with the different lifecycles of your Activities and so on. Remember also that you can compose Modules using the Class<?> [] includes() method inside the Module #interface.
In your particular scenario, you want to share the Task object from a TaskDetailActivity. If you held a reference to the Task within your TaskDetailActivity then that reference will no longer be available when TaskDetailActivity is destroyed. While you could try some solution of holding binding the Task in a Module and then maintaining a reference to that Module at the app-scope level, you would essentially be doing the same as the UserScope at the app-scoped level in the article you have linked. Any kind of solution for sharing the Task object between Activity using Dagger 2 would necessarily involve maintaining a reference to the object at the app-scoped level.
Using Dagger 2 doesn't mean that the new keyword or serialization/deserialization of Parcelables is now wrong and so if your first intuition is to use Intent to communicate then I would say that you are right. If you need a more robust solution than directly communicating the Task, then you could extract a TaskRepository and transmit an Intent between Activity that contains the id of the Task you wish to retrieve. Indeed, some of the Google Android Architecture Blueprints have a solution just like this.
I'm thinking about a platform-neutral (i.e. not .NET MEF) technique of implementing chain-of-responsibliity pattern using web services as the handlers. I want to be able to add more CoR handlers by deploying new services and not compiling new CoR code, just change configuration info. It seems the challenge will be managing the metadata about available handlers and ensuring the handlers are conforming to the interface.
My question: any ideas on how I can safely ensure:
1. The web services are implementing the interface
2. The web services are implementing the base class behavior, like calling the successor
Because, in compiled code, I can have type-safety and therefore know that any handlers have derived from the abstract base class that ensures the interface and behavior I want. That seems to be missing in the world of services.
This seems like a valid question, but a rather simple one.
You are still afforded the protection of the typing system, even if you are loading code later, at runtime, that the original code never saw before.
I would think the preferred approach here would be to have something like a properties file with a list of implementers (your chain). Then in the code, you are going to have to have a way to instantiate an instance of each handler at runtime to construct the chain. When you construct the instance, you will have to check its type. In Java, for instance, that would take the form of instanceof (abomination ordinarily, but you get a pass for loading scenarios), or isAssignableFrom. In Objective C, it's conformsToProtocol.
If it doesn't, it can't be used and you can spit an error out to the console.
One requirement in our application is to implement "dual control" for everything, including CRUD operations.
Just to be clear, "dual control" is a feature that requires a change in the data to be approved by someone other than the change requestor. So when a user make changes to data, it's not directly committed to production tables. I'm aware of several ways to implement this (e.g. staging tables) but thats for other time.
The question, with such requirement, do you think we should follow the standard "data centric" way of generated Roo + GWT (which uses RequestFactory) ?
Or we'll better off implementing our own "command pattern" based framework to support dual control?
I'm inclined toward the latter. My intuition (which based on 3 days play-around with Roo+GWT) says that RequestFactory is not designed with dual control in mind, and we'll hit a wall if we try to force our way in. Would be more than happy to be proven wrong here.
Have you looked at RequestFactory's ServiceLayerDecorator? It mediates all interaction between the payload processing and your domain objects and code. As an example, you could override the getProperty and setProperty methods to read from and write into some kind of "shadow" log that holds pending mutations.
If you need to implement ACLs for objects, methods, or properties, the loadDomainObject and resolveX methods can be used to control which server-side classes any given request can interact with.
To wire in a custom decorator, you can subclass RequestFactoryServlet and call the two-arg constructor. Alternatively, you can just instantiate a SimpleRequestProcessor using the object returned from ServiceLayer.create().
Implementation note: all of RequestFactory's default domain-interaction behavior is built using a series of ServiceLayerDecorators; check out the GWT source if you want to see example code for building a ServiceLayerDecorator. One thing to note is that if your decorator calls any methods defined in the ServiceLayer API, it should use the instance provided by getTop(). ServiceLayerDecorator instances are expected to be stateless and reusable, so if you need to maintain state across method calls, consider using ThreadLocal variables, similar to RequestFactoryServlet.getThreadLocalX().
It really depends what "user experience" you want, and particularly whether you want users to validate "diffs" of what has been changed, or approve the "new version" (snapshot).
If you want diffs, because RequestFactory only sends diffs (i.e. the actual changes the user, or you code, made to the objects) to the server, then intercepting setProperty calls as suggested by Bob is certainly one way to do it (to make Bob suggestion a bit clearer: you'd "store" the diff in a static ThreadLocal so you can retrieve it from your service call). You could also use "smarter" domain objects, that build an internal diff when their setters are called; the diff would then be accessible for each object on the object itself.
If you want snapshots, then you simply have to implement your services to store the modified objects in "staging tables" or whatever rather than in the "production tables"; and then "move" them to the "production tables" when the "approve" service is called.
One thing that's clear (to me), is that you have to model your services and/or objects around "dual control" and not try to do it within "simple CRUD" operations (i.e. the "save" is not a "save", it's a "send for approval"; and there's a separate "approve" operation).
#BeanProperty generates simple get/set methods. Is there a way to automatically generate such methods with support for firing property change events (e.g. I want to use it with JFace Databinding?)
I've had the same question, and have been keeping a close eye out for possible answers. I think I've just stumbled across one (although I haven't tried it yet). Scala 2.9 has a feature for handling dynamic calls (meant for integration with dynamic languages, I suspect). Essentially, calls to methods which don't exist are routed to a method called applyDynamic. An implementation of that method could use reflection to check that the method signature matches a property (possibly one with an annotation similar to #BeanProperty). If there is a match, it could handle firing the event.
Maybe that's something where a custom compiler plugin can do the trick.
Sadly I have no idea about how to write such a plugin. But at least thought I give you this pointer.
I would be very interested, if you'd come up with something along that line.