I have some simple questions for Android Users.
If I use Single XML for Multiple Activity, What issues might come ??
How it ll help in Application PERFORMANCE, if we use this kind of approach ??
for example : If have same XML layouts A,B,C for A,B,C Activity, Instead of using multiple layout I want to use only single Layout i.e. A XML Layout for A,B,C Activity.
Note: I have tried this, works fine. But I want to know that any issues or problem using this kind of approach. Gone through some sites but din't get cleared picture
Suggestions or help will be appreciated.
Many Thanks ..!!
There's no problem at all. The XML will get inflated as separate instances for each Activity.
Note that because they are separate instances, any data on those forms won't be shared between them, though; you would need to pass data between activities as extras on an intent or through a persistence mechanism (databases, shared prefs, etc)
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 am very in doubt of the structuring of my application. When to use Fragments is a big question for me still. I understand the concept of fragment, but I would like to know how more experienced programmers use them. Is it really only when there is a specific task the fragment should do?
For instance, POP-UPs, what layout would be better used?
And back to the fragments, do you usually have a skelleton fragment that can be used for more than one thing, and then reshape it to different final forms (minor changes) or would you just use different fragments if the layout changes?
You should use fragments in a few situations but its going to depend on your app really.
If you have a layout that is going to be used in multiple places and the code is relatively the same, that is a very good candidate for a fragment so you can keep code down.
If you are making an app where the layout changes based on orientation or device type (tablet vs phone) then fragments are highly recommended to hold different layouts. It makes it easier to change or show multiple layouts if need be on a tablet.
I'm sure there are more scenarios but I would say these are the basics for fragment decision
The most common way I use them is as a kind of plugin layout for my activities. Let's say I have several activities and all of them need to display an address, phone number and some buttons (call number, launch navigation/gps, etc). I pass the fragment the id and the fragment does the legwork of grabbing the information and populating fields for my activities. This way, if I need to add anything, say an email address, I just need to modify one section of code rather than each activity and layout file.
OK, I get the concept of Fragments being modular/ interchangeable "sub-activities" but given that fragments have their own lifecycle much like the one of an activity and can pretty much do anything that an activity can, from a best-practice standpoint, does that mean we are to start coding a single activity for the whole app (say, the main_activity) and simply adding/ replacing/ removing fragments within that single activity?
If not, then how do I know when it's time to create a new activity instead of continuing to push new fragments into the same old activity?
Just trying to understand how to best organize my app's features into activities and frags. A practical example would help (no code necessary, just the concepts).
Cheers,
No, I does not mean that you should use single activity.
Fragments are to help you organize ui elements (especially on big screens (like tablets)).
They also introduce new layer of reusability (using fragments for loaders, simple views) across your projects.
I recomend you check Google NewsReader SDK example which is a great way to see how to implement activity/fragment patterns depending on what type of screen it is launched on
http://developer.android.com/training/multiscreen/adaptui.html
Download sample button is on the right
No fragments are just one way to reuse parts of an application. For instance you can use a fragment in several activities. On the other hand you can of course have several activities that use different fragments or do not use fragments at all.
So summary: no you don't need to. Fragments are helpful, if you build up multiple activities that use a similar or equal component as a part of their layout.
I am using setContentView(R.layout.main) to switch the views in the same activity. I am calling some asynchronous task and populating the data on the main layout file after that I am changing the view by calling setContentView(R.layout.main) method.
I came to know that we should not use setContentView method multiple times for same activity. Though it is working fine for me.
Can anyone explain why we should not use setContentView method multiple times for the same activity to change the views?
Will it create any memory related exceptions? Could someone please clarify?
I think switching Views is not a good idea, because android platform already have strong framework to handle the transition in between the views and maintaining the state of each view associated with the Activity its always better to stick with the existing framework instead of thinking of some complex implementation that you have to go through to do all these things. If you do not need any of these things to taken care in your application and if only if you have only two or three screen in your entire application you can try switching the views. That even based on how your views are structured if you have complex logic and lot of data needed to create these views this wont be a good way of doing it.One more thing if you are adding more views say functionality to your application the load that need to be handled by the Activity will go high. In this case you will be declaring and initializing all views inside that particular Activity so maintaining all these views instances is heavy. If you want to know more about the Activty and Task kindly refer this link
Well every time you call setContentView() you'll have to find all the layouts again besides that I think you "can" do it. But as discussed here this is ill adviced as it clearly goes against the android guidelines. Also Commonsware have some very important points here one of the most important being that you will be prone to leak memory as you forget to clean up stuff from your views etc. which Android normally would handle for you.
In short you should follow Android guidelines and use Fragments or start a new Activity.
According to the developer docs setContentView(int layoutResID) is used to
Set the activity content from a layout resource. The resource will be inflated, adding all top-level views to the activity.
In best practice this method is used to Inflate your Activity layout on start up. This does not mean that it will cause issues in the future if you keep using this method. To quote a answer in this question
The setContentView on your Activity actually calls the setContentView on the Window used by the activity, which itself does a lot more than just inflating the layout.
I suggest that you find a alternative way to switch layouts like using a ViewPager with Fragments or some other Tabbing approach but in the end it all comes down to what you want to do.
This question might also give you what you're looking for.
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