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.
Related
I'm working on an Android app, it's a turn-based game. I have two types of turns (let's say TypeA and TypeB) and UI for TypeA is completely different from UI for TypeB. Also, there are sub-types for TypeB, each of them having their own UI. Every UI is implemented with a Fragment, but for a single game I need to create about 30 fragments, each of them used just a single time.
Currently I create the Fragment, save the data I need, destroy the fragment with
fragmentTransaction.remove(myFragment).commit()
and then I create the next Fragment and so on. Is there a better way to handle this situation?
I think that this is the right way, add fragments only when you need it and remove whose do not need.
Anyway I can suggest you to try Navigation Component to check visually all your fragments flow.
Ref. https://developer.android.com/guide/navigation/navigation-getting-started
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 am now reading the Packages part of Agile Software Development - Principles, Patterns, Practices.
It is a good idea to package by feature.
It is a good idea to package by coherency, reusability and encapsulation.
So I have a MainActivity, which is something like a home screen
I have 5 more features all of which are represented by 5 more activities.
Each feature is in its own package.
From the MainActivity, one can get to all other 5 features by selecting an option from the actionbar or the main navigation.
However, now MainActivity knows about the other 5 packages and its package is highly dependent.
I came up with the idea to create a separate package, an Activity Selector, whose purpose is to know about all packages who contain activities.
And whenever MainActivity needs to call some feature, it should only depend on Activity Selector to call it and tell it what it needs. Then Activity Selector picks it up from there and calls the appropriate feature-activity-package.
This way none of the activities and their respective packages know about each other. Encapsulation is high, reusability is high, independence is high.
Leave out overengineering (I am doing this mainly to practice, not because my project actually needs it), I am concerned about two things:
a. I've never seen anyone do something like that
b. How do I implement it, if it turns out to be a good idea?
1. Implementation idea 1: Activity Factory:
- The factory accepts a Context in its constructor. I use a list of strings, and if Activity A wants to start Activity B, I pass the factory a name that corresponds to Activity B and the factory starts it.
2. Implementation idea 2: Activity Mediator:
- the mediator takes in both activities, and lets one start the other with an intent. But how do I prevent both packages containing both activities from knowing about each other
3. Using a dependency injection framework like Dagger:
- is that going to solve this problem? It will take the fun out of implementing it myself, and I believe that I should be able to write a framework similar to a framework I am considering using it, before actually using it, otherwise I will not learn and gain skills I need.
4. Activity factory using Marker Interfaces
- I create marker interfaces for each feature, and let activities in each feature implement them. Then a call to a factory requires certain feature by its marker interface type, and the factory creates the needed activity
I am designing a android user interface for a sports app.
One of the features of the app is that the text of buttons and menu items changes as
the game state progresses. So you go from setup game -> start first half -> half time -> second half -> game over etc. The buttons and the menu item text change to indicate the next valid actions in the app.
Now so far I am doing that by watching a global var of the state and basically checking this in the various onCreate, onResume methods. at least for the buttons anyway. Not sure about menu items and how to make them dynamic.
Now I figure there must be a better way to do this in android ? In swing you might have a modelchangelistener and you could register as a listener of that in your view. Does something similar exist in android ? Also I know in Java you can do the Observer pattern but I was looking for something built into android. I imagine this scenario is fairly common.
But if there is not then NO YOU HAVE TO DO IT YOURSELF is an acceptable response to my question too.
Thanks in advance.
Frank.
Android does not have anything in particular like an Observer/Observable - even though you are free to use those in Android as well.
The question is: should you use Observer/Observable-classes, or not? Some say no, because it requires you to override an update-method which takes an Object parameter. This is not OO-friendly. Others, love it.
Those against it, suggest you write your own Observer classes, and register those Observers manually. Each Observable should then iterate through a list of Observer instances to say:
"Hey! Here's an update."
Good question.
You have to implement your own Listener and then you can use a selector in the XML file you create later on. Just like when you use it with Buttons : android:state_pressed="true"
Edit: However, I really suggest you don't spend time at all on this task as that can be accomplished in any other simpler way.
This might not make much sense in terms of Android SDK, but, in C++ I am used to keeping my main.cpp (and specifically main() function) as a place where I declare and initialize other classes/objects, and afterwards all the things that my application does take place in those classes. I never come back and check for anything in main.cpp afterwards.
But in Java, Android SDK, you have to override dozens of methods in main activity and all of that takes place in one single file. Example:
I have a MainActivity.java and SomeTest.java files in my project, where first is default MainActivity class which extends Activity, and SomeTest.java contains class that declares and runs new Thread. I initialize SomeTest class from MainActivity.java and pass a handle of the activity to it as a parameter:
SomeTest test = new SomeTest(MainActivity.this);
And having the handle to MainActivity, I proceed doing everything from this newly created thread. When I need to update the UI I use runOnUiThread() to create and show a new ListView (for example) on my main layout. I want to get the width and height of the newly created Listview, for what I have to override onWindowFocusChanged() in my MainActivity.java and notify the thread from there, as getWidth() and getHeight() will only have values when ListView is actually displayed on the screen. For me it's not a good practice to make such connections ('callbacks', if you will) from MainActivity to that thread.
Is there a way I can keep methods like onWindowFocusChanged() within the thread and don't touch the MainActivity.java at all?
As I said, might not make much sense.
Is there a way I can keep methods like onWindowFocusChanged() within the thread and don't touch the MainActivity.java at all?
onWindowFocusChanged() is a callback method. It is called on the activity. You cannot change this.
And having the handle to MainActivity, I proceed doing everything from this newly created thread.
That's generally not a good idea. Using a background thread to, say, load some data from a file or database is perfectly reasonable (though using Loader or AsyncTask may be better). However, usually, the background thread should neither know nor care about things like "the width and height of the newly created ListView".
You are certainly welcome to migrate some logic out of the activity and into other classes. You might use particular frameworks for that, such as fragments or custom views. However, the class structure should not be driven by your threading model. For example, let's go back to your opening statement:
in C++ I am used to keeping my main.cpp (and specifically main() function) as a place where I declare and initialize other classes/objects, and afterwards all the things that my application does take place in those classes
However, in C++, you would not say that you are locked into only ever having two classes, one of which is operating on some background thread. While you may have a class or classes that happen to use a background thread (or threads), the driving force behind the class structure isn't "I have a background thread" but "I want to reuse XYZ logic" or "I wish to use a class hierarchy in support of the strategy pattern" or some such.
Personally speaking Context idea taken from Android SDK seems to be messy. What you are describing comes from too much responsibility intended for Activity. That's why you need to track a LOT of things inside single file (Activity's life cycle, getting Context instance in order to show Dialog etc.). I don't think there's perfect solution but I would recommend using:
Fragment subclasses which are helping to divide your screen (and so on logic) into seperate parts
3rd party frameworks/libraries like AndroidAnnotations, RoboGuice, Otto which are perfect tools to avoid spaghetti code
if you would like to perform some UI updates from another class, consider using an AsyncTask passing it the Views you need to update. Let me know if you need an example
I read everything and understand your statements, I can see you've been doing programming for sometime but apparently is just starting with Android, I've done a lot of embed systems before so I totally get the concept of having a software that looks like:
void run(){
object.setup();
while(true){
otherObject.run();
}
}
But there's one fundamental flaw on the you logic of your question:
Android programming is a different programming paradigm from C++ and from computer programming and you should understand its specific paradigm instead of assume what is good practice from other paradigms.
Quote from you: create and show a new ListView (for example) on my main layout. I want to get the width and height of the newly created Listview, for what I have to override onWindowFocusChanged().
From that I can see that you've really trying to do Android stuff on a way that is not recommended on an Android context. A ListView you can easily implement from the XML layout setContentView(int) and use the Activity onCreate to instantiate any threading (AsyncTaskLoader) framework to load the data in background and deliver it back to the UI.
That doesn't mean that all your code will be dumped in one file making it a mess. This little example I put you can do with Activity that implements the loader callbacks, a separate class with the loader, a separate class with the data loading work, a separate class with the data adapter, the activity is just a central piece that organise and manage those classes on the correct moment of its life-cycle and at no point you need to call onWindowFocusChanged() and still have a nicely organised code.
Apart from that please refer to CommonsWare answer as it's usually cleverly written and correct.