I'm cleaning up a flutter app and learning to use the dart profiler.
In my initial analysis I noted that the developers have created FirebaseAuth.instace almost everywhere in the app wherever data is streamed or fetched. Does this affect the app/memory/performance in any tangible way?
Also, isn't it better to create a single instance of FirebaseAuth or others like Firestore and use provider/riverpod/bloc to pass that instance rather than invoke it everywhere individually?
Does this affect the app/memory/performance in any tangible way?
No.
Also, isn't it better to create a single instance of FirebaseAuth or others like Firestore and use provider/riverpod/bloc to pass that instance rather than invoke it everywhere individually?
No. Each returned instance is a singleton. There is only one actual instance per initialized app returned every time you call it.
It just doesn't matter much whether you "invoke" the instance or use a stored object from the call. Do whatever you prefer.
Related
I have a Unity3D app backed by a Firebase/Firestore database.
Firebase provides a Local Emulator Suite for testing, but it is not supported on Unity.
It seems the only way to test logic which uses Firestore is to either:
Use a real, test-only database and clear it on each SetUp
Mock out all usages of Firestore
(2) seems error-prone and like I'm reinventing the wheel. (1) seems both dangerous and slow. Is there another widely-supported option I'm missing?
The emulator suite is now supported. See https://github.com/firebase/quickstart-unity/issues/719#issuecomment-938759588
To use the emulator, run
FirebaseFirestore firestore = FirebaseFirestore.DefaultInstance;
firestore.Settings.Host = "localhost:8080";
firestore.Settings.SslEnabled = false;
Make sure you use this code in each assembly used. Many tutorials have the tests run in a separate assembly as the rest of your code. If your architecture is similar, you will need the above code in each assembly. Specifically, be sure to call this code both in your test assembly when accessing FirebaseFirestore.DefaultInstance, and in your game code, since FirebaseFirestore.DefaultInstance exists once per process (i.e. once per assembly).
My Grails 4.0.10 app needs to call an external service. The call may take up to 3 minutes, so it has to be async'ed. After reading the doco I wrote a non-blocking service method to perform the call using a Promise without too much trouble.
The documentation describes how async outcome can be displayed.
In my case the outcome affects the database. I must create new domain objects, modify existing domain objects and persist the result in the onComplete closure. The doco is rather quiet on how to do this.
These are my assumptions about the onComplete closure. My question is: Are the assumptions valid? Is this the proper way to do it?
No injected stuff is available, neither services nor (for example) log -- things you normally expect in a service
Database logic must be enclosed first within Tenants.withId if multitenancy is used, and then within withTransaction
withTransaction is prefixed with a domain name. However, other domains may freely be manipulated and persisted in the same closure
Domain instances picked up before the async call may be attached to the current session like this instance.attach() and then modified and saved
If logging is needed, create a new log instance
I was looking through an old project and wanted to see if anyone had a suggestion on how to hide certain methods from being called by various layers. This was a 3 tier project, webapplication -> web service -> database
In the application there is a User object for example. When a User was being updated, the webapplication would create a User object and pass it to the webservice. The webservice would use the DataAccessLayer to save the User object to the database. After looking at this I was wondering if instead I should have made a Save method in the User class. This way the service and simply call the Save on the User object which would trigger the db update.
However doing it this way would expose the Save to be called from the webapplication as well, correct? Since the webapplication also has access to the same User object.
Is there anyway around this, or is it better to avoid this altogether?
There is a separation of concerns by keepeing the User object as object that only holds data with no logic in it. you better keep it separated for the following reasons:
As you stated, it is a bad practice since the Save' functionality will be exposed to other places/classes where it is irrelevant for them (This is an important for programming generally).
Modifying the service layer - I guess you are using WCF web service as you can transfer a .NET object (c#/VB) to the service via SOAP. If you put the saving logic in the 'User' object, you can't replace it another webservice that receives a simple textual data structures like JSON or XML or simply doesn't support .NET objects.
Modifying the data storage layer - If you want, for example, to store the data inside a different place like other database such as MongoDB, RavenDB, Redis or what ever you want, you will have to reimplement each class that responsible for updating the data. This is also relevant for Unit Testing and Mocking, making them more complicated to interrogate.
We are mixing workflows, a workflow using receive activity's more at the end. But at the start we want to pass in some arguments (not using a receive activity!)
Our workflows are already being created and resumed using a dynamic endpoint with IWorkflowCreation and a class derived from WorkflowHostingEndpoint. In the OnGetCreationContext the creationgContext is filled with WorkflowArguments and the workflow runs. At a later part the receive activity's are creating a bookmark which can be resumed with a message. All seems nice.
But in a xamlx there are no WorkflowArguments, i understand why, except that i want them anyway. I though about an activity in which i can write some code to get the Arguments myself, but i do need some help here.
Or is there another way to pass along the WorkflowArguments into a xamls without using Messaging?
You can't pass arguments into a starting workflow service except through the SOAP message that starts it. But there is nothing preventing you from reading any properties in your workflow service. So it is perfectly fine to do read settings or something similar instead of passing them in at startup.
We have solved this exact situation by creating another WCF service which sits alongside our xamlx service on a slightly different url (e.g. /WorkflowMetadata) and this is where we implement a service method that returns a dictionary of string, type.
In the implementation of this service we simply read the xamlx and determine the arguments.
This is what we use to interrogate a target workflow in an activity designer when creating something like a launch-workflow activity.
Creating an activity will not work as that activity will need an instance in order to run. All you want is some metadata about the xamlx service. And if you are using a WorkflowCreationEndpoint to construct a creation context then you are probably only allowing a dictionary of string, object as the start parameters. Therefore standard metadata will not work. This left us with the only option being to provide another service beside the workflow which serves metadata.
Background here: http://blog.petegoo.com/index.php/2011/09/02/building-an-enterprise-workflow-system-with-wf4/
I have a app that pass through a web service to access data in database.
For performance purpose, I store all apps parameters in cache, otherwise I would call the web service on each page requests.
Some examples of these parameters are the number of search result to display, or wich info should be displayed or not.
The parameters are stored in database because they are edited through a windows management application.
So here comes my question, since these parameters don't have to expire (I store them for a couple of hours), would it be more efficent to store them in a static variable, like a singleton?
What do you think?
I don't think there'd be a noticeable performance difference in storing your parameters in the HttpCache versus a Singleton object. Either way, you need to load the parameters when the app starts up.
The advantage of using the HttpCache is that it is already built to handle an expiration and refresh, which I assume you would want. If you never want to refresh the parameters, then I suppose you could use a Singleton due to the simplicity.
The advantage of building your own custom class is that you can get some static typing for your parameters, since everything you fetch from HttpCache will be an object. However, it would be trivial to build your own wrapper for the HttpCache that will return a strongly typed object.