I have an activity A. Activity B is partially transparent (so I can see activity A below).
Is there an option in Android to allow a user to interact with Activity A while B is still in front?
I want to leave activity B in front the whole time, but allow the user to interact with screen A.
overriding the implementation of onTouch or onClick in B so I can pass the event to activity A?
This is not possible and will not be, because it's a security concern. This on web is called clickjacking. The reason that this is not possible is because you could theoretically manipulate the user to do something unintended like deleting a file or similar, just by guiding them on where to click on a fake screen.
in my experience there is nothing like this. So, you must close activity A and B can be clickable or something.
Related
I have an Android app with multiple activities. The main activity communicates over a network and can launch or dismiss various other activities depending on commands it receives over the network. When an Activity is dismissed I don't want to finish() it, just move it down the stack so it's no longer the top activity. What I really need is a FLAG_ACTIVITY_REORDER_TO_BOTTOM but there is no such thing.
There's an intent flag called FLAG_ACTIVITY_PREVIOUS_IS_TOP and the name implies something like that but I don't understand the description:
"If set and this intent is being used to launch a new activity from an
existing one, the current activity will not be counted as the top
activity for deciding whether the new intent should be delivered to
the top instead of starting a new one. The previous activity will be
used as the top, with the assumption being that the current activity
will finish itself immediately"
Could someone please decode that for me, and if it's not what I want IS there some way to tell an activity to submerge itself below the previous one?
This isn't possible. The activities are stacked and you cant put one back under the other. It sounds like you may want to create a class that extends Android’s android.app.Application.
I found this tutorial online and it looks good. Good luck.
Extending Android's android.app.Application tutorial
You cannot move an activity below a certain activity into the android back Stack. The only way to move a activity in back stack is to open another activity on top of it. You can move an activity on top by creating a single instance of activity using FLAG 'singleTop' in this way your activity will be moved to the top of another activity and only a single instance of activity will be there in stack.
More information about activity back stack and Flags is available here.
Go through this information and all your doubts will get cleared about back stack.
I have two activities A and B. The A has a ListFragment which uses LoaderManager, whereas B activity shows a details about the item selected in the A's ListFragment. I've just noticed that when I use a back button to get from the B back to the A, the position in the ListFragment preserve, but when I use the up button (left-point caret) in the action bar, the A activity is recreated and thus position in list view is lost.
I would like fix this issue, but I am not sure about the best way how to do it right.
I come up with this solutions:
a) Use onBackPressed()
Replace the default implementation for the android.R.id.home (the up action bar button) in the B activity, and instead of the NavUtils.navigateUpFromSameTask(this) function call the onBackPressed() activity method. I've tested it and it works.
b) Keep use NavUtils.navigateUpFromSameTask(this)
But implement the onSaveInstanceState and restore listView position during onCreate method of the ListFragment used by the A activity. (I've not tested this approach yet)
Which of this solutions is better? Or is there any other (much more better) solution?
Solution a) is pretty simple and straight forward, but b) is probably better because the default implementation of the up caret is used.
Any ideas are welcome. Thanks.
Solution c is the correct option. First, though, an explanation of the problem with solution a.
There is absolutely no point in having two back buttons in your Activity. Furthermore, option a actually breaks the up button. The point of the up button is to provide a way for users to stay within your app when they have landed in your app from an outside source. For example, if you land on activity B from an outside activity C and if you are using your option a, then pressing "up" in activity B will result in activity C being shown. The behavior you would want would be for activity A to be shown.
As you can see, solution b is on the right track. You definitely want to go up to A and not back to C. However, simply storing the state in onSaveInstanceState will not cause the state to be retained. This is because onSaveInstanceState only gets called if your application may be killed by the system. It is not guaranteed to be called if your application was destroyed manually, and it certainly won't be called when a new instance of your Activity is created. If the Intent starts a new activity, then it will not have its state restored from the other activity.
There solution, then, is that you must write anything persistent to a shared preference file (or a custom persistent alternative). When doing this you can guarantee that all instances of an Activity share the same state across multiple tasks so long as their onResume (or wherever you restore state) is called. OR:
If you know exactly how you want your navigation to work, you can avoid writing everything to persistent state by using a combination of Intent flags and Activity task affinities. If you want to use the same activity as up even if you navigate into the application from an outside source, then you can leave your Activity A's affinity as default (linked to the application) and use something like Intent.FLAG_ACTIVITY_CLEAR_TOP.
Personally, I'd try the Intent flag approach first and failing that fall back to writing the state persistently. You just don't really want scroll location sitting on persistent storage if you can avoid it..
check out this presentation: https://speakerdeck.com/jgilfelt/this-way-up-implementing-effective-navigation-on-android. It answers to all of your problems.
Sorry for my english.
My "Root" activity (let's call it Activity A) is an activity that asks for a password. If the password is correct it should start another activity (B) with subactivities and so (B, C, D, etc).
When the user presses "back" in the Activity B, the app must exit (and not back to Activity A). To achieve this, I simply "finish()" Activity A after I call Activity B. This process works OK.
The problem is when the user presses "home" and then starts the app again, the app resumes from the last point and not from the Activity A.
I use 'android:clearTaskOnLaunch="true"', but it is not working because the "Root" activity is killed when the password is correct.
What is the best solution for this situation?
Thanks!
There are some tricks I can think of, but people will still be able to get to it through Recent Tasks. You should perhaps rethink your logic of when the user needs to re-enter a password.
You can try merging Activity A with Activity B.
At the first, make the Log In controls visible. After you had validated the user, make the login controls invisible, and make all the other controls visible.
I have not really understood the handling of activities and the stack.
I have 3 activities, A - a splashcreen, B- a menu and C another Activity. I start the splash and exits it after a while when the menu is started.
In code I handle them all like this:
startActivity(new Intent(this, ContactInfoMenu.class));
finish();
Now, if I start the app and goes A-B-C, when I hit "Back" in C screen I jump back to B-the menu. Another "Back" exits the application, just like I want.
BUT .. if I go A-B-C-B-C - the "Back" button in C screen exits the whole app instead of getting me back to the B screen?
Why is that? It does like that in all my "subscreens", I can only enter them once, if I enter them a second time the "Back" button exits the app. And I have not tried to catch the "Back" action anywhere? Shouldn't I always call "finish()" when I start a new activity?
Regards
Finish is good for leaving the current activity and going back to the previous one. Otherwise, try to avoid calling finish() if you can help it.
There are a set of flags that you can pass when you start an activity that do a better job of determining how that activity behaves on the stack. These include:
FLAG_ACTIVITY_NO_HISTORY - your activity will not remain on the stack after another activity covers it.
FLAG_ACTIVITY_CLEAR_TOP - a good way to pop off a bunch of activities when you need to "go back" to a certain activity.
Many of these flags can be set in the manifest. Reading up on them will give you a better idea about "The Android Way".
Basically, You don't need to call finish() every time you go to another activity. If system is low on memory it will close your activity instance by itself.
finish() is more often used when yor are inserting some information in one page and then moving on to some other page. In that case, you might need to fininsh your first activity.
But in case where you need to shuffle between views, you must not use a finish() function, because it will cause the whole application to finish.
Try using back button of your own in your views to shift between activities, where you can move to any other activity of your application or even to the Main Screen.
I'm using a custom Launcher application with Widgets that are used to launch (and provide status updates) for an application.
The application consists of a few Activities - let's call them A, B and C for simplicity.
A is the launched Activity. The user proceeds from A to B and then to C (never in any other order).
At any time the user can press the 'Home' button on the remote control and return to the launcher application.
If the user then presses the 'Back' button on the remote control they always return to the Activity they were last using (A, B, or C).
However, if they click on the widget (rather than pressing back) the Activity that is brought to the front seems inconsistent!
So, here is an example of what happens
From (custom) launcher, use widget to launch application
Activity A appears
User presses a button that launches Activity B
Activity B appears
User presses 'Home'
Launcher appears
From (custom) launcher, use widget to launch application
Activity A appears NOT B
Sometimes I get Activity B instead of Activity A - but I'm not sure under what circumstances. I want to get the Activity at the top of the stack to be displayed and never any other Activity (Activity B in the example above).
I've read Google's documentation about the Activity flags ("single-task", "single-instance", etc...) but nothing seemed to jump out as the solution to my problem.
In my case, Activities A, B, C only make sense when run in that order - and it never makes sense to see a previous activity unless you explicitly go back to it.
I'm not sure if the problem is the way the widget is launching the application or whether there is something I need to specify in my manifest or something else.
Any ideas?
Thanks,
Dan
Isn't that what's supposed to happen? Isn't your widget launching activity A? Would you expect it to launch activity B if you are asking it to launch activity A?
(Althought you say that you get B launched sometimes. Isn't this related to the app being forced out of the memory?)
I'm sorry, but this is not an answer, but rather some additional information related to that same question.
I have found a pattern for Activities when relaunched after home button is pressed.
See my question for all my research:
Android Activity Stack is not working as stated in the docs - last activity in task stack not shown
Hope this can be of help...
I have been reading that the suggested fix for this strange behavior is the use of a "Dispatcher" class as Main that will launch the activity based on the application state...or you can also keep track of all the activities opened that need to be restored...but this can become really cumbersome when having a complex UI application design.