I'm explaining what I refer to with "app layout".
I'd like to call another app from android but at the same time staying in my own app, this can be visualized with having a border that would be from my own app and inside that border the app I'd like to call would be executing. New app would be then some sort of activity from original app.
The reason for doing this is that we'd like to keep always our app permanent meanwhile we can take advantage of apps that do perfectly some things that our app should do.
I think that if a web layout is possible so should be this, maybe it's not implemented or it would be pretty complicated to do, but it could be done.
Hope someone can guide me with this.
Out of the box - no, that's not possible.
You can call other app activities with startActivityForResult() and have your app re-invoked with result available in onActivityResult() callback when the activity finishes. The called activity will have its own UI and won't display in your app's frame.
If the called activity is your own and you can modify the code, you can make it dialog style with transparent margins/padding that show parts of your calling activity underneath.
Related
here i want to develop an app that can run a simple quiz for psychology character test, but here i need some advice on how to show the question on the activity. Because i want to showing each question without moving to other activity.
This is my temporary layout (it's still ugly XD), but i want the question can appear on the inside of that red box. And when user press Next button, the question inside that box can changed but before it change the app has been stored the answer of previous question.
I really don't know how to use fragment or something like that.
NB. This is my mainActivity look :
For your app I would recommend not to use fragments at all, it will make your app much slower than it can be.
What I would do in your case, is only load the new question in the textbox on pressing next, and call an asynchronous function (asynctask) to perform the storage of the answer. This way the user sees no delays whatshowever.
If getting the next question required a server connection, use a progress dialog in between to show the user something happens.
Agree with Bas van Stein, using different fragments will slow down the app. What you could do is separate frequently changing part of your screen (e.g. question with answer options) into a fragment and reload it's data on Next/Answer button click. This will separate the code and make it easier to maintain and change it later.
On the other hand you could do it in the activity itself if you don't want to use fragment.
I am using the Android MediaRouter (API 16) and Presentation (API 17) classes to generate & manage a secondary display. I followed the example in ApiDemos to create unique non-mirrored output, and so far it works fine (testing with Nexus 10 connected to HDTV via HDMI cable).
Now, I have a situation where I want the Presentation object created in Activity X to continue running on the secondary display, even if Activity X invokes another Activity Y. In this situation, Activity X is still on the stack, but Activity Y is now on top of it.
The problem is that when Activity Y starts, the physical secondary display reverts to mirroring. When I exit Activity Y, the content of Activity X's Presentation goes back (since I never called dismiss() on it).
So the question is: How can I keep a Presentation attached to a secondary display running on that display, even if a subordinate Activity is running on the local device?
UPDATE: One way I thought of doing this is to instantiate the Presentation object from a background thread; then the subsequent creation of another Activity should not interfere with the content being written by the background thread to its Presentation object. But I'm not sure this will work, as it's generally not allowed to update a UI from a background thread.
Another approach would be to disable the use of secondary displays by the subordinate Activity, if possible, thereby preventing it from reverting the secondary display to mirroring when the new Activity becomes active. But I haven't found a way to do this either. Thanks again for any suggestions.
I implemented one of the approaches suggested by #CommonsWare (and independently by Mark Allison in answer to my question on his blog). Thanks for your suggestions!
In review, THE PROBLEM was I couldn't keep a second screen presentation running in the background across Activity invocations on a local device. This was because the Presentation class is implemented as a subclass of Dialog, and is therefore tied to an Activity instance. So when a new Activity started up, the second screen went back to mirroring (instead of displaying other content I was specifically generating for it).
THE SOLUTION was to refactor all "subordinate" Activities into Fragments of the original Activity (i.e., the one that launched the second screen). Then, instead of calling startActivity(), I start/stop the new Fragments using FragmentTransactions. The net effect is that the Activity that started the Presentation is still running, so the secondary display is no longer interrupted when a new Activity starts.
My case was further complicated by the fact that the top level Activity (which starts the second screen) was actually a SherlockFragmentActivity that uses a ViewPager and FragmentStatePagerAdapter -- so I had to cram all this into a Fragment. It also required explicit management of ActionBar tabs, menu items, and home icon.
Overall, I think the code is a little less transparent ... but it works!
NOTE: It's good that Google has implemented a secondary screen interface. But I'm not sure why they did it the way they did. Rather than shoe-horning the Presentation class into Dialog, it would have been nice if they provided a more general solution that could easily run in the background, i.e., regardless of foreground Activities on the device. A solution like this would have saved me from a lot of code refactoring, as described above.
Bringing this question back from the dead willing to help someone with the same problem somewhere in time,
I've recently came into a far deeper, but similar, problem: I had to display a presentation anywhere on the system (I work with embedded android) and in the main screen any app could be used.
I first thought of creating a Service that managed the display of the presentation and was initialized at the startup of the application. But the problem was that I couldn't show the presentation because, as you mention, it inherits from a Dialog and the same problem that happens when you call getApplicationContext() when building a dialog, occurred.
My solution was:
There is a WindowManager.LayoutParam called TYPE_SYSTEM_ALERT that is used to display alerts like the Low Battery alert Dialog. Using this property you can create a Dialog from a service and display it properly and as the Presentation class is a children of the Dialog, simply setting this property made it work.
The magic happens here:
WindowManager.LayoutParams l = mPresentation.getWindow()
.getAttributes();
l.type = WindowManager.LayoutParams.TYPE_SYSTEM_ALERT;
mPresentation.show();
Just reminding that in order to achieve that your, application XML should have the SYSTEM_ALERT_WINDOW permission.
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
I think that this should solve your issue as well, but it is a little bit delicated and you need a proper treatment to stop the presentation as soon as you needed.
The main activity of my app is defined in the Android manifest file with the following attribute:
android:theme="#style/Theme.Translucent.NoTitleBar"
This makes the activity transparent, which in turn makes it possible to control the transparency of my app in code by manipulating the main View object (e.g., by invoking setVisibility(View.INVISIBLE) on the main view). This works fine.
However, one undesirable consequence of this approach is that when the app is launched there is no visible response until my main View is displayed. Normally, the default black background of an app's main activity is immediately visible when an app is launched, which provides immediate confirmation that the app is starting to run in response to the user tapping its icon in the launcher. But with a transparent background, the user continues to look through the background at the display from which the app is being launched until the main view is displayed, and so it appears (during that interval) as if nothing has occurred.
Even on a device with mediocre performance (e.g., the Motorola Droid) my view comes up in about one second, which is not too bad. However, on a really slow device (e.g., the G1) it can take almost four seconds. While this is not a disaster, I'd prefer an immediate response so that the user is not left wondering whether the app was in fact triggered.
I have tried removing the transparent theme, which results in immediate confirmation via a black background, as usual. However, I've been unable to set the activity background to transparent in code once the app has been initialized.
I've invoked setTheme() on the activity just prior to calling setContentView() for the first time, passing it a transparent theme, but this does not make the activity transparent.
I've also tried this in onCreate() (again, just prior to calling setContentView()):
ColorDrawable transparentDrawable = new ColorDrawable(Color.TRANSPARENT);
getWindow().setBackgroundDrawable(transparentDrawable);
This also appears to have no effect.
I've also tried using a theme in my manifest that has android:windowBackground set to a drawable that is a mostly transparent PNG, but with some text (e.g., the app's name) superimposed on the transparent background that would provide a cue to the user that the app was loading. Unfortunately, the moment I use a drawable as part of the theme, the background fails to display at all until after the main view is initialized.
All time-consuming initializations are already being done in a worker thread, so I'm not looking for advice on how to accomplish that. The view itself just takes a certain amount of time to display, and while it is fairly quick, nothing beats the instantaneous response of seeing the main activity's background as soon as the app is launched.
Even on a device with mediocre performance (e.g., the Motorola Droid) my view comes up in about one second, which is not too bad. However, on a really slow device (e.g., the G1) it can take almost four seconds.
It should come up in milliseconds. Make sure you are not doing excessive work on the main application thread.
The view itself just takes a certain amount of time to display, and while it is fairly quick, nothing beats the instantaneous response of seeing the main activity's background as soon as the app is launched.
Then initially display something else that is cheaper to bring up (e.g., ProgressBar), replacing it with your regular UI when it is ready.
I've upvoted CommonsWare's answer, because he pointed me in the right direction, which is away from trying to change the transparency of the main activity after it is launched (something I'm beginning to suspect cannot be easily done).
However, that advice cannot itself be the accepted answer, given that it is only a pointer in the right direction.
The answer I decided upon, given this guidance, was to create a splash display. However, I could not find a truly good android splash example anywhere. So, I devised one, and it is working very well for me, and completely solves my problem.
Because creating a splash display is a more general question than the one I started out with, I have placed my detailed description of how that can be done as an answer to a question about how to implement a splash screen, and have linked to that answer below:
Create a true splash screen
I have tried and tried to get a transparent, floating Activity to show up (as an overlay), but allow whatever is behind it to still show AND update. Right now it seems that if the Activity behind mine is closed or a new one opens (could be either in this case), the new underneath Activity does not shine through my Activity to the user.
I have tried every combination of Flags I can come up with, and at this point I'm assuming Flags are not the answer. Can anyone help me find the proper code to do such a thing?
Before anyone asks, I have a valid use case for this type of Activity; no, I don't plan to annoy the user with it.
As far as I know, this is not possible. It should be possible to create an activity using the theme Theme.Dialog or Theme.Translucent (see http://developer.android.com/guide/topics/ui/themes.html) to have whatever activity is beneath it still show at least partially. The problem is, is that the Activity below will be Paused (it's onPause will have fired, but it's onStop will not have) and I don't believe it is possible in any way to have it run any code.
I have not investigated in making a transparent Activity but I don't think it's possible in an Activity way. This seems to be logical since even if you have a transparent Activity it's still relying on the View inside it - the View makes the transparent part, not the Activity. This means you're probably gonna end up with a transparent View instead.
If you have a "front" Activity with a transparent View and then a "back" Activity, the "back" Activity would not be visible to the user - and that's because you're in another Activity.
So, the correct way is to use a transparent View.
It is possible to update the activity below by implementing a Broadcast receiver on it, and sending Broadcasts from whenever you want.
I have an NoContentViewActivity which has no Content View (i.e. I did not call setContentView() in the onCreate of my Activity).
My question is how can I keep the content view of the launching activity on the screen? Right now, I am getting a blank screen whenever I launch NoContentViewActivity? I want the content view of the launching activity (the activity which start the NoContentViewActivity) to show on the screen.
Thank you for any help.
Excuse me, people, but my guess is that hap497 wants exactly the thing he wants. There is a bunch of situations where invisible activity would fit while Service will not.
Imaging you want to show a set of dialogs, each next of them is shown after the previous one based on the user choices. And imaging you want to have this (exactly the same) functionality to be available when pressing different buttons on different (lots of them) activities.
To write the same dialog processing logic would be an overkill whether the transparent activity will deal nicely...
Anyway, as stated above, all you need to do is to specify:
android:theme="#android:style/Theme.Translucent"
or
android:theme="#android:style/Theme.Translucent.NoTitleBar"
(if you do not want a titlebar either)
It sounds like you'd be better off using a Service than an Activity. Activities are for code that is to be viewed; Services are for code that runs without a UI, which is what it sounds like you want.
An Activity with no Views assigned is an empty black screen, so it will still obscure the calling Activity. You could make your Activity transparent by assigning it a transparent theme:
android:theme="#style/Theme.Translucent"
Keep in mind though, that your invisible Activity will have focus, so the user won't be able to interact with the Activity underneath.
Why do you want to create a fully transparent Activity? As Daniel suggests, a Service might be a better solution to your problem if you genuinely don't want any user interaction.