Personally, I like to open a new activity instead of a dialog because I can control the design easier (such as the layout, different window options, size). Plus I feel it's much simpler to handle all of the component's listeners and such. But is there any benefit to running a dialog instead of an activity? Is it faster and less memory exhausting?
First off you can create a custom Dialog to look basically however you want. However, as a direct answer to your question, the only drawbacks that I can think of are a) the original activity is now in an onStop state which means it could be killed, and b) You are using more resources to add a whole activity, instead of a dialog. That being said, there is a time and a place for everything.
Related
I have a question about the correct logical use of fragments in Android. I know that it was designed to be used to improve tablet experience, but does this imply that fragments should generally ONLY be used for this purpose? Or would it be poor development practice to use fragments as a replacement for a custom compound View?
For example, I am writing an app to keep tally. When the score sheet is produced, it creates a "ScoreCell," a custom compound control, for each player in a ScrollView. What I want to do(but don't see how as a View) is handle internal OnClickListeners that are activated by the containing activity: each ScoreCell has a TextView for the players' name, which I want to long-press to startActivityForResult() to pop open an input dialog to change the name of the ScoreCell. But seeing as the method for OnActivityResult() is unavailable in a View, would it be correct for me to instead make each ScoreCell a fragment?
Here is a picture of the activity to help understand the logic of what I need/am confused about
There are many questions in here, let me go through them.
No fragments are not meant just for tablet experience, in general they allow you to create more modular and adaptable layouts (think classes). They are extremely helpful in tablet layouts/landscape, but also give you reusable components.
At the same time, a fragment is not the right choice here... It is much easier to use a listview, coupled with a custom cell layout. Instead of using another activity to display a dialog simply call new Dialog() and dialog.show(). An activity should only be used as a dialog if it will be used by the user by a long period of time and provides a new "activity" (action)
Items in a list should not each be their own fragment, no. You can pop up a dialog without creating an entire Activity. Take a look at the documentation on AlertDialogs and DialogFragments for your dialogs and you can get the result from that.
I see many developers choosing to theme their activity as a dialog instead of using the android dialog and customize it.
I searched on the internet for this answer but couldn't find it.
Could someone give me the pro's and con's of the activity theme method? Of course, it gives you more freedom but are there any styling reasons to avoid customizing the standard dialog?
I, myself needed to re-use fragments in dialogs so I created a themed activity to comfort my needs but now I'm running into trouble at retrieving results from the themed activity.
Thanks in advance.
Bram
1) Start your activity using startActivityForResult.
2) Before you close your dialog-styled activity add needed data to intent extras and save it using SetResult(int, intent).
3) To process results add code to anActivityResult of parent activity that will retrieve data from saved intent.
no probs.
Yes, if you need to add heavy custom logic to your "dialog", then usage of styled activity is preferable.
In case of simple alerts - use Dialog.
A custom dialog is easier to create (you don't have to handle onCreate, onPause, screen rotations, ...), and have less overhead.
So you should use a custom dialog whenever you don't want to display something more complex than a dialog.
I'm playing around with Dialog to create some quick views in my app (like login enter name etc)
and I'm wandering what is better: hide or dismiss.
I know what they both do but I keep wandering if it is better to just hide a Dialog and show it again when I need or to dismiss it and recreate it.
my Dialogs are small and are actually static in my code so as such I don't hold tons of instances.
So can somebody give me the pros and cons of using hide over dismiss.
Using hide() could cause a Leaked Window error.
If you choose to use hide() and you exit your application using finish(), this will cause an error message (seen here) about a window being leaked.
So, either dismiss() your dialogs properly before calling finish() or just use dismiss() instead of hide().
It depends on how many time your need it, and if it is expensive to create it. If it is not too expensive to create it, I would personally prefer to dismiss it, to have a "cleaner environment". But if you're not using hundreds of dialogs, I don't think this really matters.
I know that It is a very old post but I've found none of the answers above good enough, so in the simplest way of explaining:
hide() will just change the visibility status of the dialog but the object will be still there and can be shown again using show() method.
dismiss() hides and also destroys the dialog. To show the dialog again it needs to be recreated first.
Then if you need to show and hide a dialog many times better to hide() it. eventually dismiss() it on onDestroy() to avoid the window leak error. Note that leaving the activity when a dialog not dismissed causes the memory leak.
hope it will be useful for feature references.
I assume by 'static' you mean the content is not dynamic, not that you've got static objects in your code. In that case it's probably best to dismiss the dialog and allow the VM to recollect any memory allocated for it. The resources necessary to create a dialog are trivial but holding onto memory when it's not very frequently used is a good way to starve the system of memory.
Consider your app may be one of half a dozen apps running. If they all kept their "cheap" objects hidden instead of dismissing them pretty soon something's going to be forced to close by the VM to reclaim memory.
At the same time we're talking about a Dialog which is not exactly a large object. I'd offer the standard behavior would be to dismiss it unless you can create a convincing argument why it's cheaper to hide it to save resources on re-creation (for example, if you're very frequently displaying this dialog).
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
I am working on an Android app that has multiple screens the user will need to navigate between and I am curious what the best practices are when switching between those screens. I am torn between creating a new Activity for each screen and simply changing the view (setContentView(R.layout.whatever)). The screens all share at least some variable values so I'm leaning toward changing views and using class level variables, but I'm worried a single activity could become very large and confusing with logic for multiple screens in a single file. I'd like to keep the code clean and separated, but I also don't want to be passing several variables around between views if that isn't needed.
Being new to Android development, I'm hoping some more experienced members of the community could share their thoughts and let me know how best to handle it.
Thanks!
Note:
I wasn't planning on using a viewflipper. My thought was to use a button click event and then call setContentView() to a new view for the page I wanted to bring up next.
Example: My application starts up using R.layout.main as it's view. User clicks the Help button and it calls a method that runs setContentView(R.layout.help); to display the help screen as opposed to switching to a help activity.
You should use an activity per screen as this will make the best use of the framework and allow the OS to selectively kill off screens if things get tight.
If you have a single activity and resources get tight the OS has two choices; kill everything or kill nothing, and if the user is not using your app then it's most likely it'll kill everything.
If you use an Activity per screen the OS can kill off some of the screens the user hasn't visited for a while, whilst still allowing others to remain active which allows the user to go back to them quickly.
As for sharing variables and values, you could use the SQLite database or SharedPreferences stores for passing them around if they are widely shared, or use the putExtra methods in Intent if they're only of use from one screen to the next.
If you have variables that you will reuse make a base class for them, that you will extend.
This can be a your custom activity that extends Activity.
As far I can tell you have to create separate activities for each views, only a few situation can be handled by viewflippers.