I have a GameActivity. I also have a transparent ChatActivity running on top if the user presses the Chat options from the Menu (onOptionsItemSelected). The problem is, when a player starts the ChatActivity before I start the game, an odd behavior occurs and the game won't start.
Is there any way I can keep GameActivity active while ChatActivity is visible?
I fired up the ChatActivity using the normal way:
startActivity(new Intent(GameActivity.this, ChatActivity.class));
Thanks for your help.
You can't have two activities in one activity. However; one design you could possibly achieve is introduce a design that allows the user to swipe the screen to bring up the chat view and swipe in the opposite direction to hide the view.
Have the main Activity that is running maintain that view via an async process so that it can be updated as necessary and does NOT interrupt the user.
You could take a look at FLAG_NOT_TOUCH_MODAL (and maybe FLAG_NOT_TOUCHABLE), using 2 activities on top of each other, making the top one transparant and give it that flag/those flags (not sure if you can actually touch windows you create within that activity, didn't try that yet)
you could also take a look at this. It's not exactly the same thing, but maybe you could rework it a bit to fit your needs
I know this is very very late,but this answer could be of use of anyone new.
For achieving the kind of design mentioned here, you could implement fragments instead of having two activities.
Related
I'm trying to make an app and I have made a blueprint for a specific activity, but I don't know how to implement it. The layout contains few buttons at the top of the activity, and each button features some information, which is displayed inside the view. The view which needs to be updated is present under the buttons. I don't want the activity to be changed, instead it should update the contents of the View, which is different for each category/button.
By doing some research I have realised that the "Tab Layout" can be used to achieve my requirements, but I don't want the tabs and I need some stylish buttons as a replacement.
I know I'm not the best at describing, so I have looked upon Dribble and found one design which is 100% similar to blueprint.
I want to achieve this using XML and Java using Android Studio! Every suggestion will be a great support foy my app.
Thanks a lot.
As far as I know, you could achieve that by using fragments (which is the same concept you would have used on TabLayout). I don't really know how much knowleadge you have on Android, but if you know what a Fragment is, it should be easy for you to recreate the idea.
You have 3 buttons for 3 different fragments, so you must design every fragment by separate and change it depending the button you click.
I have realised an NFC reader application
So i have 3 activities :
MainActivity, which is an activity who contains a Button. If button is clicked, the scan is activated and the user can put his NFC tag against the device to detect it.
WebActivity, who is launched if the NFC tag contains and URL (and open a WebView) or if the user want to launch WebActivity by himself
HistoryActivity, who gonna contains a list of every scans.
Now, I would like to swipe activity with a finger gesture. according to my research on Internet. I need fragments and ViewPager.
But every example that I saw is bases on ONE activity and multiple fragments.
But in my case, I have to create 3 fragments (one per activity), right ?
And I really don't know how to manage my fragment. I mean, what to put inside ?
All I want to do is create a transition/animation while changing activity... That's crazy
This is too broad of a question but hopefully my answer will steer you in right direction.
You should definitely go with single activity/multiple fragments model. Aside of recommendations by Google, you could use navigation components, deep linking much easier then without single activity.
Yes you should be using ViewPager for the purpose (and likely your implementation of FragmentPagerAdapter as well) however I do not understand what kind of swiping will you be doing
Reading your setup, I would suggest to use bottom view with 2 items (good example is here https://github.com/android/architecture-components-samples/tree/master/NavigationAdvancedSample/app/src/main/java/com/example/android/navigationadvancedsample). 2nd one would show history, first one would offer a button that activates your action, and then displays fragment with your WebView.
As a side effect of such implementation, you'd be able to go back from 2nd bottom view item to whatever first one holds - by pressing system back button - which I think is nice touch.
UPDATE to "swiping takes place anytime. " comment:
You could have single activity, ViewPager with 2 fragments. First fragment would display a button, 2nd fragment would display a history. You could freely swipe between them, as you want to. However to me it does not make sense to put WebView screen into this. WebView screen is result of action (NFC detection) and it should probably display as full screen, without any chance of swiping between main/history and itself. Hope it helps or I'm missing some important piece of info you did not share.
I'm fairly new to android, and have been working on an app for a few weeks. I want the app to run on handhelds and tablets. I decided to implement fragments after running things on my tablet and am having trouble getting my head around it to get the ball rolling. My app is like most: The first page you see is a menu list of various activities you can navigate to, some of which call other activities. I've read countless tutorials, but still have a few questions, I'm hoping someone can help with. I haven't had any luck finding the answers on the internet.
1) Should the main menu be in a fragment or just remain an activity that calls fragments?
(I'm thinking it should be a fragment as well)
2) I've read that the activities are just a portal to the fragment, so in the main menu all of my logic should go in the fragment?
3) Why does eclipse throw a dummy class into the wizard setup? Shouldn't this package just be deleted and the array adapter or whatever be put into the logic of the main menu or do I require another class for a good reason?
4) I also read somewhere that the Main activity must be called Main.java is this true? I don't see why it would be.
I realize these are all probably pretty simple questions to someone that has a grasp on fragments, but I don't!
Thanks for any answers
Ken
1) Yes, if you are handling logic and ui, and you are attempting to do your best and want to have a structure that you can easily support multiple screen sizes, your menu should be a fragment.
I think the activity is the mechanism to handle what fragments to display.
So on a phone the first activity just displays the menu fragment and launches a new activity to handle the selection.
While on a tablet you might have the menu fragment on the left side of the screen and do a fragment transition for the right side of the screen upon user selection
2) Your activity still has work to do to coordinate those fragments as my example in 1.
3) You don't need that class
4) You can name anything at all, anything at all. Pay attention to what's specified in your manifest. Your app can even have multiple starting points / icons in the launcher if you specify it as such in the manifest.
1) If you want different layouts depending on device and/or orientation then yes. Maybe you want the main menu to be located in a pane on the left on a tablet while it's a full screen list on a phone.
2) This is a bit more tricky to answer. It all depends on how you design your application, and there really is not right or wrong here. You could opt for an MVC like approach where you put the actual logic in a controller. You could let your Activity deal with what happens when a menu item is selected. You could use an eventbus (Otto or Guava) to communicate between fragments. It's up to you.
3) Not needed
4) No, you don't have to name it Main.java. I think you may be confusing this with the public static void main(String[] args) entry point of a standard J2SE program?
Hi i am working with android , and i have a problem with the activity stack. As i know, when someone uses the back button, reload the back activity. But in the case i have many layouts shown from one activity, how can i go back to them.
Here is the deal, i am using a listview filled with categories, and when i press an item, i reuse the activity and the layout, to show its subcategories. So what i need is to came back no to the back activity, not to the back layout, but to the back "state".
Well, the idea is simple, first i show all the categories with no parent, then when i pressed an item, i show its subcategories.
The easiest way is creating two Activities - for categories and for subcategories. If you try to implement all the logic in a single Activity you won't earn nothing and just end up totally confused. Using Activities simplifies things a lot just because it handles problems such as yours. Hope this helps.
Check out Fragments, they are the stepping stone between a view and an activity. An activity can have multiple fragments and will manage their back stack (if you tell it to).
http://developer.android.com/guide/components/fragments.html
You'll have to use the support library to used them on pre honeycomb devices.
I'm making a game in Android and I'm trying to add a set of menu screens. Each screen takes up the whole display and has various transitions available to other screens. As a rough summary, the menu screens are:
Start screen
Difficult select screen
Game screen.
Pause screen.
Game over screen.
And there are several different ways you can transition between screen:
1 -> 2
2 -> 3
3 -> 4 (pause game)
4 -> 1 (exit game)
4 -> 3 (resume game)
3 -> 5 (game ends)
Obviously, I need some stored state when moving between screens, such as the difficulty level select when starting a game and what the player's score is when the game over screen is shown.
Can anyone give me some advice for the easiest way to implement the above screens and transitions in Android? All the create/destroy/pause/resume methods make me nervous about writing brittle code if I'm not careful.
I'm not fond of using an Activity for each screen. It seems too heavy weight, having to pass data around using intents seems like a real pain and each screen isn't a useful module by itself. As the "back" button doesn't always go back to the previous screen either, my menu layout doesn't seem to fit the activity model well.
At the moment, I'm representing each screen as an XML layout file and
I have one activity. I set the different buttons on each layout to call setContentView to update the screen the main activity is showing (e.g. the pause button changes the layout to the pause screen). The activity holds onto all the state needed (e.g. the current difficulty level and the game high score), which makes it easy to share data between screens. This seems roughly similar to the LunarLander sample, except I'm using multiple screens.
Does what I have at the moment sound OK or am I not doing things the typical Android way? Is there a class I can use (e.g. something like ViewFlipper) that could make my life easier?
By the way, my game screen is implemented as a SurfaceView that stores the game state. I need the state in this view to persist between calls to setContentView (e.g. to resume from paused). Is the right idea to create the game view when the activity starts, keep a reference to it and then use this reference with setContentView whenever I want the game screen to appear?
This question has been asked a lot. Did you read these other posts?
Android: What is better - multiple activities or switching views manually?. This link in particular talks about the Android Design Guidelines which "don't mention switching Views at all; it's centered around an Activity-as-View design."
Android - Should I use multiple activities or multiple content views
Android app with multiple activities
How to pass the values from one activity to previous activity
I'm not sure what you mean by the back button not always going back to the right screen correctly. I've got a game with a similar structure to yours, and the back button always takes the user correctly up the chain of activities.
Furthermore, using the onResume, onPause etc is somewhat necessary. What happens to your application if the phone rings? (Yes I know, some people still do strange things like using their phone to receive calls! :P) The OS tries to call the onPause method in your activity, but if that isn't implemented then your application won't act as expected. Another useful thing with onResume is it lets you update your tables as soon as the user returns to the view. For example, your player has just completed a level and is then brought back to the select difficulty screen. If you simply recover the previous screen from memory, it might not have been updated to take into account that a the level was just completed. However, if you put some code in onResume to handle that, then that will always be executed before the player sees the screen.
Lastly, you say transferring data around activities is a pain with intents - yes, that's probably true. But I usually find transferring any kind of complex data a pain, no matter how you do it. Are intents really that much worse, or is it just that things aren't as easy as you'd hoped? I don't mean any offense with that; I also often find things which intuitively seem easy to be rather frustrating to implement in code.