I have an application wherein when the user first open's the application he is asked to login with his credentials. So this activity say "Register" is the default activity. But once the user has logged in I want the default activity to change to some other activity say "MainActivity" from there on.
So how can i achieve this programatically?
I know one approach is to create a blank activity and based on a flag to launch the desired activity. Is there any other approach other than this ? And is the previous approach efficient ?
Thanks in advance :)
it is efficient, how ever you dont have to create a new blank activitiy, rather just use your mainActivity and if the user is not registered spawn off the Register activity cause that activity is only going to happen once. and the normal usecase is to stay in main activity.
that is how most people do it:) hope this helps
Related
I'm creating an app and I'm using a library called "SlidingActivity".
[Github Link]
I actually have two activities. One being the main activity of the app and the other one extending SlidingActivity. So when the SlidingActivity is opened, it's still possible to see the main activity in the background (see the images on the Github page).
Is it possible to edit the content/layout of the main activity when the SlidingActivity is opened?
I tried using getParent() but it's returning null.
Edit: As #Hamza Hathoute suggested I've tried overriding onPause() and onDestroy(). I've seen that onPause() is called each time the SlidingActivity is opened.
Thanks in advance. I'm new to StackOverflow so if there is anything I've done wrong please tell me!
The issue you are facing is one of communication. That is, you want the SlidingActivity to tell the MainActivity that it should change its content. While there are a few approaches to this issue the simplest might be to use the LocalBroadcastManager to send a broadcast.
Edit:
An activity that is not in the foreground can be killed by the OS in low memory situations. So you should register your receiver in onCreate and unregister in onDestroy. It is therefore possible that you might miss a broadcast (if your activity was destroyed when the broadcast was sent).
If you want to cover this case then unless you want to deal with persistence (shared prefs, db) then you should probably use the startActivityForResult option mentioned in another answer. The downside of that approach is that the changes to MainActivity aren't immediate. So if the sliding activity isn't full screen then you won't see changes in the MainActivity.
If you want to show the main activity in the background, you can use a transparent background for the sliding activity.
So, you should pass whatever params you needed from the main activity (not the activity object) using intent, use that to populate your sliding activity (designed with a transparent background).
In the sliding activity, you can save the desired params to modify the main activity when you come back to the main activity.
If your sliding activity always returns some results to the main activity, you can use startActivityForResult,
See here for implemantation: How to manage `startActivityForResult` on Android?
is really the other activity still running or is the activity in the background just a clone of the content of the previous one?
You may check this by overriding onPause and onDestroy and adding a Log Message.
If it doesn't display any message then you definitely can edit it, just pay attention to the performance.
I'm making a simple e-book reader app, and an activity can be called by many cases.
I'd like to distinguish callee activity to know its origin action in case of
From my another activity: this can be easily solved by
StartActivityForResult from calling activity.
Called by back button click from other package app after share action ("whoops, I missed to click share button, and then back.").
Switched by user's multitasking choice.
Called by user click at the start screen: this might be known by MAIN entry point at the android manifest.
How to know above cases?
I have no idea why you would need to do this but...
1.From my another activity: this can be easily solved by StartActivityForResult from calling activity.
Yes, as long as the calling Activity is your own as you can't guarantee any 3rd-party code will use startActivityForResult(...). You can, however, use getCallingPackage() and getCallingActivity() in other cases.
2.Called by back button click from other package app after share action ("whoops, I missed to click share button, and then back.").
When the user presses the BACK button your Activity isn't being "called" - it's simply being resumed or re-started. The original calling app/Activity/method will still hold true - there is no way to ascertain that this has happened as the normal Activity life-cycle methods (onStart() and onResume()) are always called even when an Activity is first created.
3.Switched by user's multitasking choice.
If you mean using the "Recent" apps view, the same applies for my answer to 2. above.
4.Called by user click at the start screen: this might be known by MAIN entry point at the android manifest.
In this case onCreate() will be called although if your Activity is simply stopped for whatever reason, it may simply be restarted depending on the launch mode you use.
In short, I can't see you being able to gather much in the way of any accurate information as to how your Activity becomes active.
I am not too sure about the actual way for the above question as I am too a new guy in android.
But to the best of my knowledge... called by back button and switched by user's multitasking leads the activity to enter pause state.
So you can access it from "onPause" method in your activity.
I have an app that will never require more than one instance of an activity. I want it so that when the user comes back to a screen it is in the same state as they left it except for a few places where it doesn't make sense. I've worked out saving the persisted data with onpause onstop updates. However to keep the screen looking the way it did when they left it i use intents specifically setting the flags to Intent.FLAG_ACTIVITY_REORDER_TO_FRONT|Intent.FLAG_ACTIVITY_SINGLE_TOP then startActivity. It seems to work great but does it make sense? Is there a smarter way? Pitfalls doing it this way etc... any feedback will be greatly appreciated.
android:launchMode = "singleTask"
add the above line for every activity in the manifeast file. Adding these launch relaunch the activity instead of creating the activity again.
Refer this link
I'm simply trying to change between xml files/layouts.
In my main activity I have startActivityForResult(new Intent(this,playlist.class), 0);
I've added the class to my manifest, created the class where the package is com.site.mainactivity, and superclass is android.app.Activity.
I didn't "extends playlist" in my main activity
My logcat only shows "showStatusIcon on inactive InputConnection", "InputConnection = android.view.imputmethod.BaseInputConnection#40532b90, active client = false"
When I try to start the new activity/switch layout, my home screen shows, but my app is still running in the background. When I go back to it, the app takes me back to the main screen.
What am I doing wrong?
Thanks
This sounds like a problem with how the Activity stack is being maintained. Specifically this is because based on the Manifest properties, an Activity can have different properties that specify how the Activity should be treated by the manifest ie. if it is included in the Activity stack or not and/or Also this could include where the main entrance of the application is, and whether or not an external intent can go to a specific screen in the application.
With manipulation of this it is easy to control. Look up the ActivityManager and how tasks are retrieved and maintained and analyze the design flow of your application. You must fully understand how you want it to work to fully solve your problem. A flow chart would aid you in this diagnosis.
Learn to control your flow properly.
If you just want to change the layout, you can either:
call setContentView again
use singleTop and launch the same activity but with a different layout
close the first Activity with finish() after launching the second
What I did to bypass this hurdle was simply use getLayoutInflater().inflate(R.layout.main, null); as a View and then setContentView(v)
I just need to reinitialize events, views, etc so that the program runs as it did before it changed the view.
Trying to understand best practice for the lifecycle of my android application, and how activities fit into it.
For example, I have a main activity, sort of the "home" of my application. But, on start-up there are several activities that I 'might' need to run, depending on several cases, one being that it is the first time the app's been run.
Is best practice to call these 'start-up'/house-keeping activities FROM my 'home' activity? Or should the application begin with a 'house-keeping' activities, do the work, then finish() and start the 'home' activity?
Thanks for advice about this,
-- J
For the best user experience (and cleaner code), you really shouldn't chain Activities.
A good best practice for the scenario you describe (needing a particular layout of options on first-launch) is to set a SharedPreference the first time that the "Home" Activity is created. In the same Activity.onCreate() call you should make a decision about what your UI will display based on that saved value (e.g., either set the appropriate View's visibility to View.GONE or choose a different layout.xml altogether).
As an added bonus: You can overload a hypothetical "has been opened" SharedPreference with the version number of the app (e.g., LastOpenedVersion) to be able to present the user with a change log the next time they open your "Home" activity after an upgrade.
I would set your LAUNCHER <intent-filter> on whatever the user will most likely want to go to from their home screen. Presumably, that would be your "home" activity.
In onCreate() of that activity, make the determination if there is some other activity that is needed (e.g., "first-run"), and call startActivity() on it. When the user presses BACK from there (or you finish() that new activity), control will return to your "home" activity.
One possibility is to start from a splash screen Activity (rather than a "home" one), which then determines what to launch next.
You should also consider if your start-up/house-keeping needs to be accomplished via an Activity. If it is not something that the user interacts with, then you can move that functionality into a Service that runs a separate thread.