What is the proper way of handling an orientation change in Android? When I researched this question there are two methods that came up.
1st Method
Use the methods onSaveInstanceState(Bundle savedInstanceState) and onRestoreInstanceState(Bundle savedInstanceState) to store and restore your Activity after being killed by the Android OS after the orientation change.
2nd Method
Added android:configChanges="orientation|keyboardHidden" to your AndroidManifest.xml so the Activity will not be destroyed when the orientation is changed.
I have tried both methods and they both work, however the first method takes a lot longer to implement. While I do see posts about the 2nd method, I want to know if this is an "accepted" and "proper" way of handling an orientation change. And what are the advantages and disadvantages for each method? Thanks!
The second method will not allow you to do certain orientation specific stuff such as load a different layout for when the screen is rotated or not (I'm thinking of resource suffixes here). I have not encountered any other ill effects, however the docs state that: "Using this attribute should be avoided and used only as a last-resort."
More info here: http://developer.android.com/guide/topics/resources/runtime-changes.html
See http://developer.android.com/guide/topics/resources/runtime-changes.html where they explain both methods and give the pros and cons and best solution.
Related
I'm working on an android game that will have several levels and since each level will have the same code, I thought it would be good idea to create that code in a separate class and then using object of that class to use the code. However, all of my current code inside the main activity uses findViewById() to refer to different view in my app but I'm unfortunately unable to use this function outside of an activity inside just a normal class file. Are there any alternative ways of referring to views that I may be able to use in other classes?
Thanks
You have several options to do so, maybe you can pass the view itself as parameter but be careful to check if this view is in the correct context and if the view exists in the current screen to avoid some null pointer exceptions.
It's difficult to decide if this solution can even work without seeing your code
I am working on an application in which there are some fragment classes, which can be open by two ways in the application. The first way is Main Flow , the second way is through the Navigation Drawer.
So when the fragment is called from the Navigation Drawer than it will perform some task, and if it's call from the Main Flow than it will perform another task.
How can I check the context? Is there possibility through the use of Enum class.
Note:
I don't want to send the hardcoded value through the Intent.
Firstly, you should avoid using enums in Android environment. Prefer to use #IntDef, #StringDef. The main reasoning behind this is the waste of resources. Enums take much more memory.
As Colt McAnlis shows in this perfmatters episode enums take 13x more space on rather trivial example.
Secondly, what you want to achieve may be done via Intents or Bundles, passing a boolean value from one component to another.
I'm new in the development with Android. For a school project, I'm currently working on an application for children to help them learn writing.
The app will contain many levels that use the same concept, only the background changes. I have made a level that works fine and now to finish the work, I want to add levels using the code of the first one.
So what is a good/usual way to do that ?
I thought that I could create as many activities as levels. In each new activity, I could start the first one and give it the new background as parameter. But with 50+ levels, it seems a bit strange to me to have so many activities.
Thank you for your help :)
If changing to a new background is all a change of levels will trigger, I would just add a level member variable to the activity and (for instance) listen for the next level in order to change the background. If it turns out that you will have to change more than the background, #Vucko s answer seems viable.
Definitely do not repeat the same code fifty times in fifty different activities!
You can use fragments, particularly 1 type of Fragment called 'LevelFragment' which will have a few arguments that you can pass to it so that each level is different, those arguments should refer to the content of the level (background or whatever). This way you're reusing the same layout and the same logic, just changing some of it's behavior based on the arguments you have.
Now all you need to do is to swap out fragments in your container, while still staying in one Activity only. Since your question was kinda vague, I cannot offer any implementation tips at this point, but rather a basic guideline and a direction to consider.
You can use a BaseActivity that will be extended from all other activities for code centralization. Otherwise you can use always the same activity and start it with a parameter in the intent (for example, level number) and make your own logics according parameter value. Finally, you can give a look to fragments too, keeping central logic in the same activity.
Fragment is your solution, you can simply pass the background assets name (throw intent).
I'm a little confused about the Activity being destroyed and recreated when the user's device is rotated.
I've been reading around, and I understand the rationale for doing so (it basically 'forces' the developer to make sure they haven't 'missed' anything upon rotation/language/other changes)
I'm happy to respect best practice if it is seen as such, however it begs the question:
How do I 'remember' the state of the game/app, so that when the screen is rotated I have something from which to re-generate what the user was looking at?
From what I can see, absolutely everything is destroyed, the base class constructor runs and all variables in the Activity are 'null'.
I suspect the 'savedInstanceState' (Bundle class) is where I would collect that data, but reading around it only seems to be used for when the app is closed from lack of resources (and a few other extremely fringe cases)
Am I misinformed or misunderstanding the purpose of savedInstanceState? Is it wise to abandon best practice (letting the Activity be destroyed) if I'm mindful enough to not miss anything upon rotation? Thanks in advance for any advice.
I should note this question applies to game programming (I'm not using a layout XML)
Do you need your activity to be recreated? Is there work you want to do on rotation? savedInstanceState is where you would store data to be passed to the recreation of the Activity, but since you aren't using XML layouts you may consider just adding android:configChanges="orientation" to your activity in the manifest. This will give you manual control over what happens during rotation change.
In additional to my original comment, I would override config changes for keyboard being show as well:
android:configChanges="orientation|keyboardHidden"
If there is work you want to do on rotation change you can override onConfigChange and do anything you need there.
It's hard to say that there is a time when you should always override config changes, but I often do it when I have no dependency on resource folders that are size or orientation specific and I'm doing a lot of work that would take too much time to recreate.
There are other best practices to store data while activitiy config changes.1. Developer Doc Handling Runtime Changes2. Alex Lockwood : Handling Configuration Changes with Fragments, This will answer all your questions reagarding config change and storing data.
Impt:
Fragment file to store data. You must set setRetainInstace(true) in order to store data and retrieve while your activity config changes.
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// retain this fragment
setRetainInstance(true);
}
so i am trying to programmatically change the alpha value of a view based on the position of a seekbar. this is what i originally had: view.setAlpha(x); with that i get this error The method setAlpha(int) is undefined for the type View. so i looked up on the interwebs and stackoverflow and saw a few posts that looked promising. so next i tried checkBoxTest.this.view.setAlpha(1); where checkBoxTest is my activity. and got the same result. on both occasions it asks me if i want to either change to onSetAlpha() or cast the receiver. neither solution solves the problem. According to the docs (Android Developers Reference) the method setAlpha() is used to set the transparency of a view. so my question: has anyone ever gotten setAlpha() to work? and if so how would i go about implementing it? (ps i would prefer a solution that uses setAlpha as opposed to overriding onSetAlpha(), but if that is the only way to make it work then i'll use it)
View.setAlpha() is available since API level 11 (docs). Perhaps you are building against lower API level?