I'm working on an app where basically i have X different activities but everyone has a layout equals to the rest. To let you understand better let me do an example:
Suppose i have a game where you have to guess 10 words each level, and I have 5 levels, basically I have in every view 10 question.
So is better to have 5 different activities or only one activity and 5 layouts, one for every level ?
Looking around on the web i did not find a good answer, someone told that Android is based on activity, so 10 different ones is the way to go, but was only a guessing, nothing technical.
Don't make 10 Activities. Don't make 5 layouts. All questions look the same except for the text, right? Don't Repeat Yourself.
Simplify your life reuse the same Activity and Layout for every single question.
When you start the activity, you can pass in data using the .putExtra() methods. Use that to pass in the things that change, like the question text, the correct answer, and the current level.
I would do 1 layout and then program the levels onto it.
Doing a brick breaker game, or tetris, or puzzle game wouldnt want you to have a million diff activity options, but more like 1 layout and 1 activity will populate accordingly.
Usually you can do something like
[home] -> {play, options, exit}
[play] -> {new game, level select}
[options] -> ....derp...
[exit] -> ....derp...
[newgame] --> start activityA where level = 1
[level select] -> click a link which will start activityA with a level = selected.
1 activity which will spawn your information safe and nicely... far far better imo.
Related
I've been reading about the include tag on xml, fragments to use on layout for smartphone and tablets but I'm getting more confused than getting a solution to my problem.
My App has 4 screens.
1 - You login and it download info from a json
2,3,4 - From login, Activity 2 load (A list with custom adapter), where you can click one of 2 images to jump to 3rd and 4th activity.
I need now to create the activity 1, 2, and 3 again with different JSONs being parsed, with 1 and 2 having the same layout of the existent ones and 3 with a different layout.
The code I need for them to work is(or can be) the same (Download Task with AsyncTask, button click listeners, etc) I already have for those activities.
I think it's not a goot pratice to copy basically the same getView method, for example, and paste on a new class, right? The buttons wouldn't work on the second range of screens for example.
So, what approach should I take that isn't copy and paste code and change things manually?
Sorry for the newbie question.
If needed I can provide code.
PS 1: I've already did tests with include on xml and copy code but that doesnt look professional
PS 2: Is fragments only for different screens like tablet or I could make something with it?
That's several questions, so here's several answers, including to some un-asked questions:
To the greatest extent possible, strive to remove as much code as possible from your Activities, Fragments, etc. If it doesn't have anything to do with the Android lifecycle or actually putting something on the screen (e.g. parsing JSON), put it in a "plain old java" class. Also, this way, you can share the functionality among Activities.
IMHO, you should never use an AsyncTask, for any reason. They're used with an Activity or Fragment, but don't respect the Fragment or Activity lifecycle, so are often the cause of crashes that can be difficult to diagnose. Use something synchronized with the lifecycle, like a Loader. Or go the RxJava route, where Subscribers can be canceled at the appropriate point in the Activity/Fragment lifecycle.
Fragments can be good for code re-use, but they have a slightly different lifecycle from Activities, so they can be difficult to work with, so use them sparingly and be careful. If you're doing it just to re-use a bit of UI (but not behavior), a layout "include" is probably better. For behavior, a custom View class can be a good alternative to a Fragment.
Don't do HTTP / REST access yourself, using primitives like HTTPUrlConnection. There are a lot of corner cases that are going to get you into trouble. Use one of the several really good open-source libraries that are built for this purpose. I highly recommend Retrofit.
I have a large Android game in which there is an Activity for each logical screen.
(Splash screen, start screen, level chooser, game screen and Settings are distinct Activities).
Everything is working fine right now.
If I rewrite everything so that there is only one activity and the logical screens are Fragments, Will it reduce RAM or CPU consumption?
After years (two+) of saying "Fragments are the way to go", I would never replace activities with Fragments again.
Using fragments to rehuse certain components is fine. Using fragments for dialogs is also fine, but I have now realized how awful the Fragment implementation is, how awful the Fragment lifecycle is and how unpredictable (and buggy) FragmentManager tends to be under certain circumstances. Go ahead an spend some time googling around and you will find all the "edge but not so edge" cases where hacks have to be implemented to work around a "by design" buggy behavior.
Sometimes you have to extend or copy the source code of these classes from the Android Source Code to modify a private or protected field…
Don't get me wrong, Fragments work. But they are not the solution to all your problems (they are possibly the source of new ones in the mid-long term). If you already have Activities, enjoy that! In fact, the new Transition Frameworks with Shared Elements is a clear indication that Google wants you to use more activities ;)
This is my personal opinion after working in roughly six mid-large sized Android projects (some are popular and you've probably used them!) ;)
As far as I know, no, Fragments have (near to) no impact on RAM or CPU.
An Activity contains certain elements and performs some functionality. A Fragment is loaded onto an sort of base Activity, like an Activity with no more than an ActionBar. The rest is filled by the Fragment.
Also check out:
android - need some clarifications of fragments vs activities and views
Activity or Fragment which is better way to use for performance and reliable?
No, it will probably increase it (as you will have more classes) but only marginally.
The benefit of using fragments is to have reusable "blocks" that you can move around depending on your needs. For example for a specific activity you could have a layout where you have your main window on screen and clicking on an item creates an new activity with some details. With fragments, you could create a layout for tablets where the main window takes only half the screen and the rest is used for the details fragment, witout having to rewrite everything.
The main benefit of fragments to me is easy data sharing. Between two activities, data has to be passed in relatively primitive types...string, int, arrayList, etc.
However between fragment and activity, data can passed back and forth in complex classes.
I'm begining to learn android development, and I'm trying to make an app just to learn the language and philosophy.
This app, has to show an image in the middle of the screen, a button below, and a chronometer in the right side. When the app starts, the chronometer has to begin a countdown. When the user press the button, a blur effect has to be applied to the image, and the seconds left to finish the countdown increase by 10.
I almost know how to program the blur efect to the image, the button press, and the countdown and increase by 10 whenever the button is pressed. But I'm not sure about putting all together.
As far as I know, it should be done by designing an activity, and putting inside the activity the image, the button, and another image or a set of changing images or text for the countdown clock. But as I advance in my studied, today I have read that in order to manage different actions in an activity it is neccesary to do it by using fragments. And I have found much complex programming fragments than activities.
So the question is: can I make what I'm trying to do by a simple activity and defining classes and methods for the image effect and the countdown clock or have I to make it with fragments?
Thank you very much.
today I have read that in order to manage different actions in an activity it is neccesary to do it by using fragments
To be blunt, either you either misunderstood what you read, or you are reading the wrong material.
can I make what I'm trying to do by a simple activity and defining classes and methods for the image effect and the countdown clock
Yes.
have I to make it with fragments?
No. It is possible that the whole UI might be a fragment, particularly if it might be shown alongside something else in some cases (e.g., a tablet) and not in others (e.g., a phone). And there is nothing stopping you from making that UI using several fragments, though that would be rather unusual.
As others have already conveyed, no need to go with fragments.. Activity wud suffice.. As far as putting it together is considered, I guess you need to learn more about layouts.. Layouts are the files which basically help you put things on UI as you want it to look like.. There are plenty of material available online for understanding layouts.. Happy learning.. :)
I have the following requirement:
-----> Showing Five elements of different color and Allow user to select the correct one.
-----> Like that I want to show 16 Kinds(Means 16*5 = 80 elements on 16 Activities)in Random.
===> For that I have created 16 activities and corresponding 16 XML files, and used them Randomly.
&&
First I'l show 5 colors and let the user select one(Say Green), If it is correct, I'l let him select one from another set of 5 colors(This time red)....& so on...Like that I have to make him choose 16 Colors Randomly.And repeat this 16 random colors until he press Back button.That' the exact flow
By the End of the Day, I am in Small Dilemma that, May be there , will be some kind of Logic that winds up the work bit smoothly By reducing the code.
If yes ,Tell me the Logic .
I have all the 80 different elements , to show them in 16 activities, 5 per Activity.
If the elements are the same type, you can have one Activity instead of 16 and choose what to show when creating Activity(or even use Fragments for that).
Any way, you have to be more specific in your question if you want to get complete answer.
Rather than creating 16 different activities, You can create a single activity and 16 different layouts. You can change the layout of activity dynamically and I think it would be good, avoid creating so many activity if there is really no need of it.
I have a very simple 2 screen android app.
Is there any downside to simply switching out the layouts via setContentView or should i be using intents?Don't want to bugger up my app if something is wrong with this.
Another thing to consider is that activities form a stack. If you want to be able to go back to the previous activity via the 'back' button, then you need to use activity. But if it is something simple like a 'loading' screen when your app starts and you don't have to go back to it again, setting content view would be a much better idea.
Well as stated on Android Dev http://developer.android.com/reference/android/content/Intent.html
An Intent provides a facility for
performing late runtime binding
between the code in different
applications. Its most significant use
is in the launching of activities,
where it can be thought of as the glue
between activities. It is basically a
passive data structure holding an
abstract description of an action to
be performed.
Therefore if your two screens are 2 different applications I would say you want to simply use setContentView.
it will simplify your code when you want to pass info from one to the other views
There is nothing wrong with having two views in a single activity. This approach is more light-weight, as you don't need to go through the phase of stopping one activity and then starting another one. However, it will make your activity code bulkier. Consider now if you are going to need more functionality or more views in the future and if the answer is yes, then it would be better to create separate activities.
If the view is light-weight (a bunch of text boxes), then it should not matter. On the other hand, if the two screens are largely independent and heavy, you could use two different activities. The primary advantages with this approach are:
If there is an error in the second screen (an activity in this case), your application will fall back to the first screen whereas in the case of using the view, the whole application crashes
Better readability
Easier to add more functionality in the future