I have started learning Android development recently and have some doubts. " What invokes onCreate method to get called automatically when we create new project or create a new activity ? And how is it getting called"
I tried to search it. But not getting the proper answer
I don't know if there's a specific spot in the documentation that explains this clearly, so I can't really cite sources. This is just what I've picked up over time working in Android and looking at source code.
The Android OS is responsible for launching Activities. An Activity is found and launched through an Intent. It could be internally done in your own app. Or if it is the entry point to your app, it could be launched by the home screen launcher app of the device. Or in debugging mode, the OS can be commanded to launch a specific activity (this is what happens when your Run your app from Android Studio).
An Activity must have an empty constructor (a constructor with no arguments) so the OS can create an instance of your Activity using reflection. Since the OS cannot know of all possible Activity classes ahead of time, it must use reflection to find the constructor and call it.
After it has an instance of your Activity, the OS manages its lifecycle. It will call lifecycle functions like onCreate() at the appropriate times in its life. onCreate() is the first time in your Activity's life where you can do Activity- or Context-specific work safely. So, there are restrictions in what you can do in property initializers and init blocks, since these are called before onCreate().
You must never call your Activity's constructor or its lifecycle functions directly yourself. These are reserved for use by the OS.
Related
Is it possible to record all methods called by my Android app without setting any breakpoint? E.g. if I have no clue where to start, but just want to know which methods are called in my app (and the libraries it uses) during the action I perform by using my app. How could I do that?
I've found myself in an interesting position. I currently use the latest Unity container, I'm on asp.net core 2.2, and I use application insights. As such, I have configured DI in my web app to use unity instead of the out of the box DI provider in core. I also use Application Insights and use the IWebHostBuilder.UseApplicationInsights extension to spin up AI for my app.
With all this in mind, I have a piece of code whose constructor takes in IHttpContextAccessor so I can access the HttpContext. It was working great. Then, I had another small app that I was trying to reuse the functionality, and the HttpContext was null coming from IHttpContextAccessor. With a bunch of guess, test, revise, I found that IWebHostBuilder.UseApplicationInsights seems to initialize that Request property (HttpContext) on IHttpContextAccessor. If I commented out that AI extension, I would get null; uncomment it, it worked.
I've started to look through the AI code to figure out what exactly they're doing, but honestly, with all the dependencies and pipelines and all that, it's a pretty daunting task. I was hoping someone could point out where/how AI is doing this so my code doesn't NEED AI in order to work. All help would be incredibly awesome.
Use AddHttpContextAccessor extension to add it to DI. HttpContextAccessor is not added by default due to performance impact.
services.AddHttpContextAccessor();
After some struggle, and hoping this post would enlighten me on the AI ask, I found that I didn't need to replicate the AI mechanism, if there's even one at all.
Originally, I was accessing the IHttpContextAccessor via code in the view (Razor). I have an abstract factory pattern I was using to instantiate IHttpContextAccessor via Unity (this pattern came over from my .Net Frame work days). Once I moved that code back to the controller and used proper .net core DI to get the dependency via the constructor, everything started working.
There must be something there I'm missing, but I have the code working so I'm happy. If someone could shed light on why one way works vs the other, I'd be happy to hear it.
When you enable application insights by calling .UseApplicationInsights(), it adds HttpContextAccessor. There are many components in ApplicationInsights which require HttpContextAccessor injected to it. eg: ClientIpHeaderTelemetryInitializer.
This is the exact line where this is occuring:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/blob/develop/src/Microsoft.ApplicationInsights.AspNetCore/Extensions/ApplicationInsightsExtensions.cs#L137
I am trying to develop Prism 6 UWP Application .
My current problem is I want to register all objects used in Application with Unity Dependency injection container .
But so many UI objects are created by infrastructure(Activator.CreateInstance(type)) and no way to trigger their creation through dependency injection conatiner.I would be fine even if I register created objects with DI conatiner.
I refered Github sample application AdventureWorks.Shopper in Prism samples.
Here I saw views are created by infrastructure ,but some other objects are created by Dependency injection conatiner .
Is there any way to get all objects in applications and register them with DI conatiner ?
Is there any way to get all objects in applications and register them with DI container or trigger all creation through DI conatiner?
Generally you shouldn't try to have your UI objects created by the container, because as you mention, the XAML parsing process (infrastructure as you call it) is responsible for doing that and there is no easy way to get in the loop to take over that construction process.
This is one of the reasons we added the ViewModelLocator to Prism - so that from the ViewModel down through all of its dependencies, you can wire up the SetDefaultViewModelFactory method to use the container to do the construction of all your ViewModels and their dependencies (and their dependency's dependencies, etc.) as long as you use ViewModelLocator to wire the View to the ViewModel.
If you are following the MVVM pattern well, then there should almost never be a need to construct the UI objects themselves through the container because they should not be doing any logic in the code behind that would depend on things injected by the container. But that is not to say you will never need to do that. So for those situations where you need to do that You can either get to the container through the Application.Current as suggested by S Vasudev with some casting. Or if you need to do that a few places and don't want all that casting "noise" in the code, then write a simple helper object with a static property that you can set in the OnInitializeAsync method of the App class and then easily access anywhere.
If you are doing that in more than a few places you should start to question your design. And yes statics (globals) are evil and should be avoided whenever possible. But if it is just a few places in the code behind of a few views, sometimes you need to be a pragmatic programmer who gets things done and not an MVVM purist who overcomplicates things just to avoid a few minor violations of the MVVM guidance.
One way we found :-
You can access unity container like this :-
unityContainer = (UnityContainer)((Prism.Unity.Windows.PrismUnityApplication)Application.Current).Container;
In constructor of objects which are created by Activator.CreateInstance,we can use unity container and register that instance to unity container.
In that way , all objects gets registered with unity conatiner
example:-
unityContainer.RegisterInstance(this);
I'm having some issue setting up unit tests that will work using TFS 2012 and .net 4. Due to IT restrictions of the target users, I can't build against 4.5 until they permit it.
The application in question is a Prism application composed with MEF. It's a plug in application in that we load modules that compose the application via a configuration file. We have certain modules that export themselves to the MEF catalog as an IContent interface that exposes some base behavior that all modules in the application are expected to exhibit.
Each IContent interface implements an Import delegate command and an observable collection of Errors within the module. The errors collection is bound to the UI so it must be updated on the UI thread.
I've created a test class that creates and runs the MEF bootstrapper and loads all of the modules in the application in the ClassInitialize of the test class. The test class can then use the MEF catalog to get all instances of IContent and run the same base unit tests on each module to ensure they pass. As new modules are added to our solution/application, they would automatically be picked up and vetted through the same unit tests.
To further the example, the IContent command has an import Delegate Command as part of its interface. The command executes on a background thread that will load some data add some errors to the errors collection. Since the errors collection is bound to the UI, the updates are done using a checkaccess and begininvoke as needed to ensure that the errors collection is done on the correct thread. At the end of it all, the module will send out an aggregated event to indicate to the shell that the module has done its work.
Everything works fine when running in the context of the WPF application. When running the unit tests, the errors collections are never updated. I believe that the cause is that the main thread which the boot strapper is runs on, creates the observable collections - and since this thread is always running a unit test, its dispatcher never gets to process the additions to the errors collection, so the test will fail. I've verified this as if I change the CheckAccess/BeginInvoke to just invoke to run in line, it will hang at the invoke to update the errors collection. It appears that the execution of a unit test always locks the main thread.
So to sum up:
Is there a way to set up the boot strapper so it runs and processes on a thread different than the main TFS test manager thread?
Can I have the Main thread run, process a test method on a background thread, respond to the necessary events that its dispatcher needs to respond to, then complete my unit tests?
Thanks in advance for any help.
So, after trying something new, the key is in how the bootstrapper creates the shell. I was declaring my shell in the test classes to be based on a Dependancy object not on a wpf window. changing this to a wpf window made everything work. No actual need then to define which runs on what thread. It just works after that.
I have developed a Java ME application for CLDC platform. It works fine when executed in an emulator. But when i deploy it to my N70 phone the application doesn't start at all in the phone. In my application there are some 14 classes and am creating an instance of each and putting them in the vector on application start. The classes just have one variable and 2 methods. Can this creating of lot of instances be the reason for its crashing?
Is there any way I can find out the reason why the application is not able to start in the phone?
Update:
Its running fine on emulator. And one more thing I would like to mention is that- The code stops executing only at the point where am creating those 14 instances and adding them to the vector. Till that point the code executes fine.
It might depend on where in the code you are creating those instances. If you are creating them in your MIDlet constructor or the startApp method try moving the initialization into the run method of your application.
One way of debugging J2ME applications that don't start on the phone is by adding "printf" style debug messages in your code to be written in the record store system and adding another MIDlet to your application to read from RMS and display those messages.
Or you could just comment bits of code and see if it works.
You can debug on device. If the emulator you are using is part of the Nokia SDK then there should be facilities elsewhere to carry out on-device testing and debugging. (I'd post more detail on this but I've only done this with Sony Ericsson phones recently.)
Another option is to use the Nokia tools that allow you to view the standard output and error for your application when it is running on your device (via Bluetooth for example).
The probability that your application is actually crashing the Java Virtual Machine bytecode interpreter thread and terminating the whole native process is very small.
It has happened before but you need to eliminate several other potential issues before being convinced of an actual crash.
It is more likely that either:
Your MIDlet is not created or not started because the MIDP runtime decides it is not correct.
or
Your MIDlet simply throws an exception that you don't catch, which can make it look like it was brutally terminated.
Since the MIDlet installer is supposed to prevent you from installing a bad MIDlet, the uncaught exception issue is more likely.
How to find an uncaught exception:
Start with the simplest HelloWorld MIDlet, using a Form so you can easily insert more StringItems at the top of the screen.
Create and start a new Thread in MIDlet.startApp()
In your override of Thread.run(), add a try{}catch(Throwable){} block.
Inside that block, do whatever your original MIDlet did.
Use the form as your standard output for debugging.
You can use Form logging to make sure you don't enter an infinite loop, to display exception classes and messages, to flag logical milestones, to display variable values...
That's the first step to figuring out what is going on.
I also faced a similar problem and when I recompiled my MIDLET as Midlet 1.0 then it worked fine. It seems like N70 is not able to run the new version of MIDLET. I think you downgrade and re-test your midlet.
Regards
Junaid