I try to access my Application from a ContentProvider but it seems that it is being created after the ContentProvider, or at least it's having its onCreate() called after my provider. Which begs the question: in what order are these things initialized? Is it defined?
Thanks
Which begs the question: in what order are these things initialized? Is it defined?
ContentProviders are initialized before your Application instance is. After that will come whatever it is that is triggering your process to exist (e.g., the code to start one of your activities).
Alas, IIRC, this behavior is not well documented.
Related
I'm currently restructuring my LibGDX-Projekt to fit an ECS-Structure using Ashley.
At the moment I have the following System-Structure:
InputSystem (handles Player-Input)
PhysicSystem (applies velocity to entities, does collisiondetection and moves them)
CameraSystem (adjusts the camera to the camera-focus)
RenderingSystem (transforms the SpriteBatch with the camera-information and draws all entities)
Now I know that each System is supposed to contains all the logic it needs and is encapsuled to reduce complixity.
But I need the camera in the CameraSystem to adjust it, I need it in the RenderSystem to apply the camera-transformation and I need it in the InputSystem to see where the mouse is pointing at. How do you solve this with the ECS-Approach? Can Systems communicate with one another? Should I just use a Singleton called "SharedData" where I dump all the stuff that multiple systems need? Seems a little ugly to me.
Thanks in advance :)
Yes, using a singleton would defeat the purpose of using an ECS in the first place. In an ECS, the approach used is that all shared data is expressed using entities. It is perfectly fine to have an Entity type for which there will only be once instance of it during the lifetime of the game.
These could then be accessed directly from the Engine when the EntiySystem is added to it. An alternative approach could be to pass commonly accessed entities to the constructor of the systems if it is frequently accessed, in the past I have used this for passing a Box2D World entity.
I believe my code does a better job of explaining my reasoning so you can have a look at one of my previous games using Ashley. https://github.com/basimkhajwal/LSD
P.S - My project also includes an event queue for messaging between different entity systems (without passing data, all the data is still encapsulated in Entity classes) which I found to be extremely useful.
I've got a Biztalk solution that I'm trying to break apart into the recommended deployment artifacts (Schemas, Maps, and Orchestrations each in a separate DLL), and I'm having a little trouble with one schema in particular.
The orchestration in which I'm using the schema has a single message defined using the schema type. In orchestration view, this message has the error icon (!) beside it. When I hover over the icon, I see "Message Type 'BiztalkPilot.MyMessageType' does not exist or is invalid."
If I change the type's compilation instruction so that it resides in, say, the BiztalkPilotSchema namespace, then the whole thing works. Every other schema in the project is in the BiztalkPilot namespace and they all function correctly.
Obviously I could just switch namespaces and have done with it, but I would like to not have to go there if possible. Does anyone have any idea why this might be happening?
I discovered the root cause here. The orchestration shared the same name as the schema. I'm not sure why that worked when they were in a common project, but once I changed the typename of the orchestration everything worked correctly.
I have an application that uses Remote SharedObjects and I am seeing some strange behaviour. I am writing an ActionScript application in AS3 using Flash Builder and connecting to Wowza Media Server 2.
My application is working just fine but I am now trying to write unit tests for it using FlexUnit. My unit tests involve creating multiple connections to the same remote SharedObject and making sure that I am getting updates correctly. Everything seems to be working well except that I am not getting any of the SyncEvent.SYNC events with an info.code of "delete". When I run my applications independently in separate tabs or even separate swfs embedded in the same page it works fine. For some reason though it does not work when inside a unit test. I have also found that if I load the swfs using a Loader inside the same SWF then I get the same behaviour. It seems to me to be something strange about the way multiples of the same SharedObject behave within the same SWF. I have had to work around other strange behaviour in the unit tests such as oldValues not being set properly in the onSync events too.
Anyone have any ideas how I can work around this? Is this a known issue? Am I crazy? :)
Would appreciate any help!
I also faced this problem before when I was working on some Flex application using some coding frameworks like Cairngorm, and connecting to AMFPHP with multi remote objects.
At that time what I come up with to resolve the issue is to make sure that those remote objects won't be fired at the same time. That is trying to make some so called "sequential chain" to fire those remote objects one after another.
In order to achieve this it may be difficult if you do it from scratch, you may consider making use of those modern ActionScript framework 2.0 to help you (e.g. SWIZ or Robotlegs). This may be too complex to handle in the very beginning. I suggest you can just place the remote object parts to be handled by the framework while keeping other things intact.
To get your sharedObject instance, you are using the static method SharedObject.getRemote(). I believe this method will always return the same instance for a given name (and if the persistence parameter has the same value).
You can have the same kind of issue when you remove a SharedObject from your app (mySO = null) and you reinstantiate it before the garbage collector did its job).
This kind of behavior makes sense to me, but it can sometimes be a problem I must admit. Anyway it should be easy to test in a debug session (Have a look at your objects instance number).
Now talking about unit tests, what are you testing? The SharedObjects behavior? If so, I believe there is some misconception here. It you really want to test this kind of behavior (and I would be interested in the reason behind), then I guess you will need some more complex tests that run two separate applications.
Hope it helps!
We had similar behavior with deletes in our project.
When we call so.close(). Then delete some key in shared object. Then connect SO again - it still see deleted key alive.
Workarounds: do not close SO or update deleted keys with some constants values (-2 for example) to mark them deleted.
Wowza 3 was used.
I'm currently trying out a few of the new C++0x features, namely std::function and std::bind. These two functions seem rather suitable for a event-delegate-system for C++ that works like in C♯. I've tried myself to create something like delegates before, but the Hacks I would have needed for member-function-pointers were to much for me…
During my tests I noticed that std::bind copies every object you bind. While that surely enhances safety - can't delete a still registered eventhandler :) - it's also a problem with stateful objects. Is there a way to deactivate the copying - or at least a way to obtain the encapsulated object from the std::function again?
PS: Is there a reference for the features that are going to be included in C++0x (hopefully C++11!) In the end it's at major parts of TR1 and a few additions…
I tried cppreference.org, but they are still at an early stage at documentation, cplusplus.com on the other seems to not even have started on covering C++0x.
If you want to avoid copying use std::ref and/or std::cref. They wrap the object into a pseudoreference
It isn't quite right that:
I noticed that std::bind copies every
object you bind.
At least that isn't the intended specification. You should be able to move a non-copyable object into a bind:
std::bind(f, std::unique_ptr<int>(new int(3)))
However, now that the move-only object is stored in the binder, it is an lvalue. Therefore you can only call it if f accepts an lvalue move-only object (say by lvalue reference). If this is not acceptable, and if the source object outlives the binder, then use of std::ref is another good solution (as mentioned by Armen).
If you need to copy the bound object, then all of its bound arguments must be copyable. But if you only move construct the bound object, then it will only move construct its bound arguments.
The best reference is N3242. There isn't a good and comprehensive tutorial that I'm aware of yet. I might start with the boost documentation with the understanding that std::bind has been adapted to work with rvalue-refs as much as possible.
I have created a move compatable version of bind. there are still lots of problems with it like the binders constructor and a few buggylines here and there etc but it seems to work
check it out here
http://code-slim-jim.blogspot.jp/2012/11/perfect-forwarding-bind-compatable-with.html
In all my projects till now, I use to use singleton pattern to access Application configuration throughout the application. Lately I see lot of articles taking about not to use singleton pattern , because this pattern does not promote of testability also it hides the Component dependency.
My question is what is the best way to store Application configuration, which is easily accessible throughout the application without passing the configuration object all over the application ?.
Thanks in Advance
Madhu
I think an application configuration is an excellent use of the Singleton pattern. I tend to use it myself to prevent having to reread the configuration each time I want to access it and because I like to have the configuration be strongly typed (i.e, not have to convert non-string values each time). I usually build in some backdoor methods to my Singleton to support testability -- i.e., the ability to inject an XML configuration so I can set it in my test and the ability to destroy the Singleton so that it gets recreated when needed. Typically these are private methods that I access via reflection so that they are hidden from the public interface.
EDIT We live and learn. While I think application configuration is one of the few places to use a Singleton, I don't do this any more. Typically, now, I will create an interface and a standard class implementation using static, Lazy<T> backing fields for the configuration properties. This allows me to have the "initialize once" behavior for each property with a better design for testability.
Use dependency injection to inject the single configuration object into any classes that need it. This way you can use a mock configuration for testing or whatever you want... you're not explicitly going out and getting something that needs to be initialized with configuration files. With dependency injection, you are not passing the object around either.
For that specific situation I would create one configuration object and pass it around to those who need it.
Since it is the configuration it should be used only in certain parts of the app and not necessarily should be Omnipresent.
However if you haven't had problems using them, and don't want to test it that hard, you should keep going as you did until today.
Read the discussion about why are they considered harmful. I think most of the problems come when a lot of resources are being held by the singleton.
For the app configuration I think it would be safe to keep it like it is.
The singleton pattern seems to be the way to go. Here's a Setting class that I wrote that works well for me.
If any component relies on configuration that can be changed at runtime (for example theme support for widgets), you need to provide some callback or signaling mechanism to notify about the changed config. That's why it is not enough to pass only the needed parameters to the component at creation time (like color).
You also need to provide access to the config from inside of the component (pass complete config to component), or make a component factory that stores references to the config and all its created components so it can eventually apply the changes.
The former has the big downside that it clutters the constructors or blows up the interface, though it is maybe fastest for prototyping. If you take the "Law of Demeter" into account this is a big no because it violates encapsulation.
The latter has the advantage that components keep their specific interface where components only take what they need, and as a bonus gives you a central place for refactoring (the factory). In the long run code maintenance will likely benefit from the factory pattern.
Also, even if the factory was a singleton, it would likely be used in far fewer places than a configuration singleton would have been.
Here is an example done using Castale.Core >> DictionaryAdapter and StructureMap