I have 3 classes in my App.
Class A extends Activity
class B extends BroadcastReceiver
Class C extends Service.
When I run the App. which one of this will be called first, I know android doesn't have a entry point. I am blocking the incoming call in class B , and I am calling the service from activity > this service will call BroadcastReceiver > here is where I block the calls.
When I run the code from eclipse to Droid, it is constantly blocking the call, even before I start the App. does any one know the reason. Thank you very much .
Service,
Another application component can start a service and it will continue to run in the background even if the user switches to another application.
So that is how you broadcast receiver is called.
Related
We have Splash extends Activity which is the starting activity of our application. We also have CustomApplication extends Application class which is invoked when the app process in invoked.
Now we have the following requirement. Whenever the app/process is launched, call Utils.doSomeDBWork() function.
For this purpose we have put this function call in onCreate() of Splash and CustomApplication classes. The reason that we have put this call inside CustomApplication is that our application can be launched via deeplinks/notifications in which Splash won't be called. But the problem is that if the app was killed and launched via Splash, then the same function will be called twice. One from CustomApplication and the other through Splash.
So basically my question is that if the function has already been called from CustomApplication, then don't call this function from Splash. I can think of doing it by using some static variable or Shared Preferences. But don't think that this is a clean way. Is there any other way to achieve this, like passing some info through Intents etc?
How to know that Application class was called before Activity launch?
In brief, every time when Android "gets a request" to start any of your app component (Activity, Service, BroadcastReceiver) and your app isn't running yet, it forks the app_process (a.k.a zygote), changes its name to your.package.name defined in AndroidManifest.xml, initializes an Application instance, calls its onCreate() method, then instantiates the component requested and calls its lifecycle methods (Activity's onCreate(), Service's onCreate() or BroadcastReceiver's onReceive()).
For this purpose we have put this function call in onCreate() of splash and CustomApplication classes.
It's redundant. It's enough to call it only from Application's onCreate() which is the earliest "entry point" to an app that is guaranteed to be called before any other component's lifecycle methods. There can be only single instance of Application class which lives untill the app process dies.
You can easily test it by logging each of the lifecycle methods. After that you won't have any doubts left.
EDIT w.r.t the OP's comment:
If the app process was running and the user back presses and exits, and then launches the app again, then CustomApplication class won't be called.
This is only partially true. CustomApplication's onCreate() won't be called unless the system kills the app process while it is in background (simulate the case by, for example, swiping your app from Recents).
But our requirement is that CustomApplication class should be invoked in this case.
It's out of developer's scope. Only the system controls that.
That being said, CustomApplication's onCreate() will be called if Android kills the app in background. If it doesn't, a simple way to achieve the requirement is to have a boolean flag in CustomApplication which would indicate if Utils.doSomeDBWork() was called.
Why don't you call from only applcation's class onCreate?
when App is launched from deeplinks/notifications or Splash, Applcation will always be created first.
Also you can check from static variable.
like below.
class Utils{
public static boolean doneWork = false; // this static variable will be false when app process is killed.
public doSomeDBWork(){
if(!doneWork){
//alreay done..
return;
}
:
:
doneWork = true;
}
}
You could do some controls with ActivityLifeCycleCallbacks on application layer. If using it in splashActivity is a solution for you,track your activities and make call in your callback. I hope it gives an idea.
I need my application to do 2 network calls when ever the app is started for the 1st time, when it has been killed and started again as well as when it has been placed in the background then returned.
I know I can put it in my "MainActivity" onCreate/onResume. I have a class that extends Application which is where I am initialising logging and crash reporting, but I noticed there is no onResume method, which from my understand is the method that is called when the application comes from the background.
Where would be the best place to do these 2 network calls to update certain aspects in my app when the app is started for the 1st time, started when killed and resumed when it comes back from the background.
FYI. The reason I don't want it to go in my "MainActivity" is that I don't want these network calls to be called when ever i return to the MainActivity from another screen in the app, only when the user returns to the app?
Thanks
The use case of calling whenever the app returns from background is by implementing Activity Life Cycle methods in your Application class:
public class myApp extends Application implements Application.ActivityLifecycleCallbacks {
...
}
In this case you make sure that whenever an onPause() is called a corresponding onResume() should also be called (i.e. normal screen switching). If not, then you know that your app is now in background. The next callback to onResume() should mean that it has come to foreground again and you can make your network call.
In my application i start an service from a activity using startService command. This service is used for uploading file so it will take time.
So what i want is my Activity should be finished and srvice should keep on doing its work. For this purpose after calling startService() i call the activity finish also.
Because of this my service stops in between abruptly while if i dont call finish of activity everytihng works fine. I want to know how to make it possible so that service keep doing its work while Activity (who started this service) is finished.
Thanks in advance for help.
You should do your uploads via IntentService because:
•The Service runs in background but it runs on the Main Thread of the application.
•The IntentService runs on a separate worker thread. so it runs your codes even when your application's Activity isn't open
Use something like this:
package com.example.test;
public class MyService extends IntentService{
public DownloadService(){
super("DownloadService");
}
#Override
protected void onHandleIntent(Intent arg0){
// Here is your codes
}
and here is a good sample ;-)
1.
I have 2 Activities,
class A { I have called a service}
class Service {I am running in the background. I was called by Class A, but I want to bring Class B in front and add text to Class B}
Class B { I have a nice GUI}
2.
How can I effectively kill "class Service" (from above question), it has a while loop and listening to incoming messages (sent by myServer) ?
Please provide me example with say, when a Button in Class A is clicked... how to check if there is a service already running?!!!
[cause, if I hit hardware back key, class A goes off, still service is running, which is expected for me.]
Tearing my hairs..
Thank you all...
You can call startActivity() (http://developer.android.com/reference/android/content/Context.html#startActivity%28android.content.Intent%29) using an Intent and then pass the data for Activity B in the Intent's extras package.
See the http://developer.android.com/reference/android/content/Context.html#stopService%28android.content.Intent%29 for details on stopping the service.
I'm trying to refactor/redesign an Android app. Currently, I've one UI activity (Activity 1) that creates a DataThread. This thread is responsible for network I/O and interacts (provides data) with the UI activity via a handler.
Now, I want to add another activity (a new UI screen with Video) - Activity 2. Activity 1 is still the main activity. Activity 2 will be invoked when the user clicks a button on Activity 1. Activity 2's data also comes from the DataThread.
My idea is to put the logic of my DataThread inside an Android Service (DataService). My question is - can more than on activity bind to my DataService at the same time? Is there a way to tell the service to provide data to a specific activity only?
Any other ideas are welcome?
Thanks in advance.
Definitely more than one activity can bind to your service. You will get an onBind() for each one that binds. Your service would then ideally handle the logic of interacting with multiple activities by identifying them using an ID or the intent (with your own IDs for each activities as extras) from onBind() in your service. You could then have the Service spawn off a background thread for each activity that binded to it.
I usually bind my service from the Application class and have some kind of controller class (like a "mediator" I guess...not sure how all these patterns are named) scoped in the application that handles communications between services and whatever the active Activity is.
This would involve writing your own Application class and telling the Manifest to use this one. I went into more detail on this process in a previous thread:
More efficient way of updating UI from Service than intents?
You could keep track of the "currently active" Activity by sending the Application class a reference to itself in onResume (also explained in the example above). This can be accomplished by deriving your Activities from a common base class that has a way of getting your Application class (casting from getApplicationContext), and in this base class' onResume, send a ref of itself to the application. Then, you can register activities by name with your DataServiceController, for example, and send messages to the current Activity only if it's registered with the Controller to receive them.