I am developing an application and was just curious about the best practice regarding how many fragments to host in an activity.
I have a view that I am going to reuse throughout my application, and I want to continue using it as much as possible to display various fragments. What is the recommended practice? Is it safe from an app performance standpoint to load unlimited fragments in an activity?
In the documentation i dont see a limits about how many fragment you can use, but... its good idea think before declare fragments, if you have a lot fragment you can start with problems about the "logic".
First start with Mockups, Wireframes and Navigation, then you should know how many fragments or activities you need.
Related
I know this question has been asked several times, but I cannot seems to find a suitable answer or there is multiple solutions. I am just trying to find were to look and the best possible solution.
I have an app that has several activities such as Main, Settings, User profile etc and I have different source for information coming into the app such as pulling data from a server, BLE comms, back ground timer etc. The plan would be to have these calling comms functions in separate classes i.e. servercomms, BLEStack, timer etc
The question what is the best way to share the data from these classes to the activity UI? There seems to be different methods such as Intent, Async, Runable but not sure which one should be used? When I look at one it seems create performance issues and will stop running if the device is short on memory.
For example if there is a Timer running in the background, which will update a picture, text on the Main Activity how can I call a function or update the UI from the timer class? I thought run a function in the MainActvity code, but not sure if that is correct as I read it might affect the mobile app performance?
Sorry, I know this question has been answered and I have followed each thread but just cannot work out the best way to make it all work with sharing data and updating the activity UI.
I'd suggest having look at EventBus as per their description:
Event bus for Android and Java that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.
OR
Have a look at the official android documentation Communicating with fragments which shows how to use ViewModels to share data between activities and fragments and fragment to fragment.
In Android land, Fragments are aware of the Android lifecycle and are not destroyed when an activity is recreated. Because of this, I have seen people using empty fragments to get around issues with the Android lifecycle destroying references to background tasks and prevent leaks associated with keeping references to activities.
I was wondering how much overhead is associated with using Fragments as hooks to background tasks? I assume that Android decides not to destroy fragments because they are expensive to recreate (could be wrong).
Bonus question. Is there a way we can measure this cost? (maybe implementing alternate methods and checking resource utilisation).
You should not use a 'headless fragment' for background work.
The correct way is to use a Loader or Service (or Intent Service) depending on the duration and type of work that needs to be done.
In terms of overhead, I don't think there is much. You can create 4 apps with these 4 methods and profile them if you want, but the better approach is to pick a method that works for the problem you are trying to solve.
Do not use Fragments to keep tasks alive!
That will do more harm than use.
If you have tasks running long enough that you have to worry if they get killed, run them in a Service.
This is exactly what a Service (or Loader) is for. Fragments should represent a part of your layout, not be used headless.
There is no reason to hack around if a working and intended solution exists.
I'm a bit confused as to wether I should create a plain activity or a fragmentactivity. My app is displaying an expandableListView and a dialog. Thats it (pretty much).
I cannot find any instance that my app would be better if I used a fragmentActivtiy because first of all my app is not designed for tablets, and second I'm not adding or doing anything to my main activity during runtime to change the views.
My problem is that it seems it is a must to use fragments, because when I checked out Android dev site on dialogs, it only explains how to implement them using fragments. Are plain activities highly un-recommended or I just have to judge my app, and are all features such as dialogs available for plain activities? (And can someone please give me a link to a good source where I can learn about dialogs in a normal activity?)
http://developer.android.com/guide/topics/ui/dialogs.html
It says here that you should use a fragment but does that mean i have to go all out and make my main activity a fragment?
Here is some discussion about using Fragment or Activity for dialog: Show fragment as a dialog or as a usual activity
If you want to make your dialog as Activity, hope this tutorial helps:
How to create Dialog activity in Android?
A FragmentActivity is an Activity because it extends Activity See here. The question the mean to ask is really a question for your self, do you want your app to support API >= 11 (3.0 Honeycomb) or API >= 4?
In API 11 Android introduced the concept of Fragments to deal with creating apps particularly tablets. But to add support for all the devices still running < 11 they created the Support v4 library which is where FragmentActivity lives.
If you are not using Fragments at all then just use Activity because it's available at all API levels. (it just got added functionality in >=11). If you want to support >=4 and may use Fragments then use FragmentActivity and your covered. I noticed things in the v4 library have started to be deprecated (starting to be phased out by Google). Personally, I won't make a new app with API <14 and suggest you stay above 11.
As far as Dialogs go. You don't need to used a DialogFragment but same question above applies to API level. I typically just used Dialog to show mine even if I'm using Fragments.
Hopefully this clears some things up for you. Happy Codin'
I have looked quite a few places but can't seem to find this specific solution. I am interested in creating a menu that will always be visible across every layout/view of the application. This menu would act much like the header/menu of a website that is fixed and always exists across all pages of the site. I assume I can simply create a menu and have it's visibility shown from initialization but I'm not sure if that's the best way. I don't want the user to have to click any other buttons to open the menu, I just want it fixed and constantly visible from the start of the app.
Thank you.
Any help is appreciated.
Fragments, they are a way to define parts of the user interface. They are similar to activities, they have their own lifecycle. They are also closely tied to the life cycle of their parent activity.
You can add them statically by declaring them in your xml manifest and in your layout file
-or-
you can add them dynamically in runtime by creating them as java objects and xml layout files and then add them using the FragmentManager class.
check out the Documentation on the android developer website
https://developer.android.com/guide/components/fragments.html
also, check out some tutorials on youtube, I like these ones especially:
https://www.youtube.com/watch?v=6GyGtCMoR_U&list=PLonJJ3BVjZW4lMlpHgL7UNQSGMERcDzHo
Good Luck!
While working on my Android application, I recently check a task manager to see how memory my application is racking up.
Right now my application has two ad banners being executed by AdMob services and then an interface fragment for a Google Map. Aside from all that I then have a menu in which I utilize a container to which I add views to it in Java code. I prefer this over a list-view as it is more light weight and easier for me to structure what I want to do with the views (and I can use Androids native animation system when adding/removing the views).
The views being added to the container are being added by a loop structure based on conditions. The views in their interface structure also have a small image-view utilizing a small local drawable.
All of this is somehow adding up to my application 44.8 MB in memory which seems abnormally high from previous development numbers. This is also the first time I decided to use the container to add views through a loop rather then the adapter with list-view method.
Can anyone tell right off hand why my application is taking up so much memory right off? This is my first time utilizing all these components: AdMob Banners, Google Maps, and Containers with added Views.
My LogCat shows no warnings of doing anything inefficiently. Just curious to see if I am doing anything wrong. If anyone has any ideas I am open to provide any source code.
I think 44.8Mb is pretty normal for a modern Android application. My bet is on Google Maps since it's very resource-consuming library (both CPU-wise and memory-wise). Anyway, you can try to sequentially remove each of the component out of app and see how it affects memory footprint.
As Andrey have already said, 44.8Mb is not too much for an Android application. But you can use DDMS to track allocations and heap updates to see exactly is taking up this memory. See this: https://developer.android.com/tools/debugging/debugging-memory.html
Besides, I would recommend using a ListView with adapter because items in ListView can be recycled, which can improve performance considerablly (See this tutorial).