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?
Related
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 have an application that works on the basic theme "Blank Activity" and what i would like to do is to change it to a "Master/Detail Flow" theme. I do know that this will make my application work on android SDK 11 + (android 3.0 Honeycomb +), that is OK with me. The issue is i don't know where to start from, what are the basic steps to make this BIG conversion? I couldn't find any example to help me out with this issue. What should i be looking for. i am sure this has been done, can you at least please give me some pointer on how to do this?
my Application is not that complicated it uses activities, async tasks, DB, custom lists,... it is very basic. I use the custom list to display data and when i click on it it displays much more details, so I thought what better way to do this in a more professorial matter than the "Master/Detail Flow". If you have any tutorial regarding the "Master/Detail Flow" that you can hook me up with that might help.
I have an application that works on the basic theme "Blank Activity"
and what i would like to do is to change it to a Master/Detail Flow"
theme.
I think a change of the application flow would be more appropriate then a change of theme. Two obvious questions that would appear are why do you suddenly want to make this change and are sure your app makes sense in a master/detail flow? The answer would most likely be positive but you should answer them nonetheless.
I do know that this will make my application work on android SDK 11 +
(android 3.0 Honeycomb +), that is OK with me
I don't see why you're app couldn't run on versions below with the new master/detail stuff.
The issue is i don't know where to start from, what are the basic
steps to make this BIG conversion? I couldn't find any example to help
me out with this issue. What should i be looking for. i am sure this
has been done, can you at least please give me some pointer on how to
do this?
You haven't provided details about how is your app implemented. The change would revolve around fragments so a BIG question would be if the current single pane version is built using the fragments framework.
If your app is built using fragments then making the change shouldn't be too hard. You'd need to:
establish which parts(fragments) should be combined in an activity(from your old ones) to make the master/detail(when the space would allow it)
change the multi pane activity to accommodate the new fragment(s). This should be easy to do but it would depend on the size of the features exposed by each of those fragments.
modify the rest of the activities(for when the app will not run in the multi pane mode), this would be small changes as the activities would mainly remain as the current version
If your app isn't built using fragments, then what I said above still applies but you'd need to also actually make the required fragments wrapping whatever functionality your app has. This would most likely result in a big code refactoring.
Here is a tutorial about the Master/Detail template in Android - An Android Master/Detail Flow Tutorial.
As far as I understand your application is up and running - so I'm not sure whether it is worth it to try rewriting it, unless you are experiencing some problems of course. :)
In general the master/details flow requires the following steps:
Implement a ListFragment showing basic information of your items
Implement a Fragment showing detailed information about a particular item
Make an xml layout file for large devices (located in layout-sw600dp folder for example). In this layout you have to put both your fragments.
Write a general version of this layout file (i.e. file with the same name but located in the layout folder), which contains only the ListFragment.
Let your activity handle onItemClick event from the ListFragment. Each time an item is clicked, you have to check if the activity is showing both fragments or only the ListFragment. If both are visible, you have to notify the details fragment that new item is selected so it can show its data. Otherwise you have to create new details fragment (you reuse it of course), pass it some information about the selected item (so it can show the item's data) and replace the ListFragment with the new one.
That a basic overview, but it should be enough to give you some idea about this flow. If you need any more details - just let me know. :)
Master/detail flow and blank activity is not same as you want to change by only changing app theme or app base theme. It will be better, if you first design master/detail flow template using UI fragments, then according integrate you blank activity with the master template making necessary changes. And for master/detail flow tutorial just google it, you will find lots of example there.
Here are some links from developer.android.com fragment-ui and adaptui
These are some guidelines about fragments but they are told using a master/Detail app.
Also dont forget to checkout the news reader app provided as sample in the second link.
If you have a recent version of the Android SDK, you should be able to create a new Android application and during that process you can elect to have the wizard create a Master/Detail Flow app for you. It will create a basic working app so that you can look through the code and understand the necessary parts.
Then, depending on how simple your app is, you may want to move all your present code to the new application or vise versa.
Macro changes that will happen:
Change all your current Activities to extend Fragment instead.
You will have to create a FragmentActivity to call your Fragments. This will basically be the boilerplate code, with just the names of your Fragments added to it.
Don't forget to double check your Manifest!
In your converted Fragments that previously extended Activity:
Everywhere you needed a Context, switch that with getActivty() (or create a global variable so that it is only called once)
Change onCreate() to
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
mView = inflater.inflate(R.layout.fragment_signals, container, false);
setHasOptionsMenu(true); // Add if you want to display a Menu
// Your initiation code here
return mView;
}
If you have a menu, change it to
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
inflater.inflate(R.menu.activity_main, menu);
super.onCreateOptionsMenu(menu, inflater);
}
And that's it for basic applications. When you first change Activities to Fragments, there will be many errors. But, they are all easy to fix.
I'm fairly new to Android programming and I've got this project I need to finish and I'm currently stuck.
I've got a standard listview in a Menu class with an array containing around 20 different elements. So what I want to do is load images in an imageview depending on which item in the listview I click, and since I'm a beginner the only idea I had was to make a new activity for each imageview which seems like a pretty bad way to do it since I'd need about 20-30 new activities..
To sum things up what I want is:
Code for making ONE activity that will display a different image depending on which item in the listview I click, probably pretty basic coding I want as simple solution as possible.
If possible I'm also looking for a solution that includes an SQLite database that stores the URL of an image and then display it in a single activity, also depending on which item I press in my current listview.
(I hope you understand my needs, and if you need I can also post my current code for the Menu class if it helps you help me) Or you can just show me a different way to make this work, I appreciate every answer! Thanks in advance!
NOTE
And please keep in mind, I'm a noob at Java and Android so keep it rather simple or at least explain what you do.
When you click on a list item, display the image in another view in the same layout, unless you want the image to take up the entire screen real estate. If you want it in the entire screen, go to a new Activity by sending the activity an Intent.
Activities are the "controller" of your application. They interact with the visible UI and the input from the user. You don't need a separate activity for each image, just an activity that's associated with a "place" in the UI (an ImageView) where you'll display the image.
I'd start by adding the images as resources under res/drawable before going on to databases.
You are going to have to do most of this yourself. There really isn't any substitute for taking the time to learn Java and Android. There are several tutorials and Android University classes under the Resources tab in the Developers Guide; I suggest you do all of them.
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.
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.