I am working on an app for school children. Basically, there would be questions with multiple choice answers as in image below. Main requirements are:
Each round of a test will have 10 questions (configurable)
Questions with answers are loaded from an api
The test is timed. So each question will be visible for 10 seconds and then the next one will be presented, maybe with some animation/slide effect
My question is which of the below is the better way to do the above?
Have the questions and answers appear in a UI fragment while storing data in a model fragment. New questions are provided by wiring up an adaptor.. something like a ViewPager without swipes
Everything is one Activity. Change the question and answers by changing android:text using maybe a handler and postDelayed()
Is option 1 better as it might handle Config changes better? Or is it easier to just use option 2. Thanks..
If you don't intend to have fancy UI, go for Option 2. And architect your code using MVP approach, where the logic is in the Presenter, and the View portion handle by the Activity.
You could read more on MVP in http://antonioleiva.com/mvp-android/
Related
I'm doing a app that will ask question to users like:
what is the capital of australia?
Camberra - paris - washington - toquio
and I will have 4 options, so user can select the right one.
When it choose the answer the next question will show.
I'd like to know if I need to create one activity for each of this questions/answers or there is another method? can I have examples?
'You can use Viewpager or viewFlipper for that purpose. in this way you can show all of your's questions in one activity'
I would change dynamically the content of the question and answers components.
If you animate the changes in those components it will look really nice and you'll be saving resources that you would waste creating an activity for each question.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am thinking of implementing one screen with Activity and all other sreens with Fragments and managing all the fragments thru the activity.
Is it a good idea? and my answer is NO but still I want to know more clearly about this thought.
What are the pros and cons of the idea?
Note:
Please don't give me the link for fragment and activity.
EDIT:
Here is something over Fragments and activity:
Pros:
Fragments are meant to be used with activities as a sub activity.
Fragments are not the replacement for activities.
Fragments are meant for reusability(Need to know in what way reusability can be achieved.).
Fragments are the best way to write code to support both tablets and phones.
Cons:
We need to implement the interface to get the data from fragments.
For dialog we have to go a long way to show it.
Why should we use fragments if we are not considering tablets?
What is the starting time difference between activity and fragment?
It depends on the app you are creating. I've created several apps using both approaches and can't say one way is always better than the other. The latest app I created I used the single Activity approach and a Facebook style navigation. When selecting items from the navigation list I update a single Fragment container to display that section.
That said, having a single Activity also introduces a lot of complexities. Let's say you have an edit form, and for some of the items the user needs to select, or create, requires them to go to a new screen. With activities we'd just call the new screen with startActivityForResult but with Fragments there is no such thing so you end up storing the value on the Activity and having the main edit fragment check the Activity to see if data has been selected and should be displayed to the user.
What Aravind says about being stuck to a single Activity type is also true but not really that limiting. Your activity would be a FragmentActivity and as long as you don't need a MapView then there are no real limitations. If you do want to display maps though, it can be done, but you'll need to either modify the Android Compatibility Library to have FragmentActivity extend MapActivity or use the the publicly available android-support-v4-googlemaps.
Ultimately most the devs I know that went the one Activity route have gone back to multiple Activities to simplify their code. UI wise, on a tablet, you are some times stuck using a single Activity just to achieve what ever crazy interaction your designers come up with :)
-- EDIT --
Google has finally released MapFragment to the compatibility library so you no longer have to use the android-support-v4-googlemaps hack. Read about the update here: Google Maps Android API v2
-- EDIT 2 --
I just read this great post about the modern (2017) state of fragments and remembered this old answer. Thought I would share: Fragments: The Solution to All of Android's Problems
I'm about to finish a project(5 months in development), that has 1 activity, and 17 fragments, all full screen. This is my second fragment based project(previous was 4 months).
Pros
The main activity is 700 lines of code, just nicely managing the order of the fragments navigation.
Each fragment is nicely separated into it's own class, and is relatively small (~couple hundred lines of ui stuff).
Management can say, "hey, how about we switch the order of those screens", and I can do it very easily, as those fragments don't depend on each other, they all communicate through the activity. I don't have to dig through individual activities, to find where they call each other.
my app is very graphics heavy, and would never work as 1 screen 1 activity. All those sub activities in the memory, would make the app run out of memory all the time, so I would have to finish() all non visible activities, and make the same control logic for navigation, as I would do with fragments. Might as well do it with fragments just because of this.
if we ever do a tablet app, we will have an easier time re-factoring stuff, because everything is nicely separated already.
Cons
you have to learn, how to use fragments
First, whatever you do, make sure you have a modular design using model, view, presenter that is not highly dependent on an Activity or a Fragment.
What do Activities and Fragments really provide?
Life cycle events and backstack
Context and resources
Therefore, use them for that, ONLY. They have enough responsibility, don't over complicate them. I would argue that even intantiating a TextView in an Activity or Fragment is bad practice. There is a reason methods like public View findViewById (int id) are PUBLIC.
Now the question gets simpler: Do I need multiple, independent life cycle events and backstacks? If you think yeah maybe, use fragments. If you think never ever, don't use fragments.
In the end, you could make your own backstack and life cycles. But, why recreate the wheel?
Pros
You could control your fragments from a single activity, beacause all fragments are independent of each other. The fragments have a lifecycle (onPause, onCreate, onStart...) of their own. By having a lifecycle, fragments can respond independently to events, save their state through onSaveInstanceState, and be brought back (i.e. such as when resuming after an incoming call or when the user clicks the back button).
Cons
Create complexity in your code of activity.
You have to manage the order of the fragments.
Never the less, it is quite a good idea, as if you need to create an app, where you want to show several views. By this idea, you'll be able to view several fragments in a single view..
It depends on the design layout of your app. Suppose if your using Tabs in ActionBar in the design layout then in the Single Activity of the app one can have fragments being changed on Tab click. So now you have an Activity and say suppose three Tabs in the ActionBar and the view for the tabs being provided by the Fragments, which makes it easy to manage plus is feasible also.
So, it all depends on the design scheme of your app and how you take the decision to build for it.
Pros:
Can be used to create a single interface usable by multiple screen sizes and orientations via xml layouts.
Cons:
Requires more complex code in your activity.
I believe it's a good idea, because using different xml layouts based on the current screen size and orientation can make the app more usable and reduce the need to release multiple versions of your app if you plan on releasing your app for both phones and tablets. If your app will never be used by both tablets and phones, it's probably not worth the trouble.
I'm a proponent of deferring all view inflation to fragments to provide better flexibility. For example having a single landing activity for a tablet which aggregates multiple fragments and reusing the same fragments on a phone to show one screen per fragment. However in the phone implementation I'd have a separate activity for each screen. The activities would not have too much code as they would immediately defer to their fragment counterpart for view inflation.
I think it's a bad idea for the phone implementation to have to change to a single landing activity when tabs or a slide out menu is introduced since the tab or menu navigation just results in a completely new screen.
The most important reason I would give for not using the single activity approach is so that the activity lifecycle can be taken advantage of. Activities contain contextual behavior of a certain portion of the application and fragments supplement that behavior. Having the ability to take advantage of the overridable steps in the activity lifecycle helps to separate one activity's behavior from another with methods such as onPause and onResume. This lifecycle also allows you return to previous context. With the single activity approach, once you leave a fragment you have to create an mechanism to return to it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
First question on Stack Overflow, apologies if it is not well formed.
I am developing a relatively complex tabbed app, and already had the basics set up before coming across information that ActivityGroup and TabActivity are deprecated, and the preferred model is to use views.
I have had no trouble using views, this is a question about architecture rather than syntax (which is why I haven't posted any code). Specifically, how should I go about restructuring the app to use views instead of Intent launched Activities.
The app has five tabs; two hold a single layout, no problem there. The other three tabs are running an ActivityGroup with 2-5 different Activities (i.e. a tab running an activity for settings, where clicking each view starts a new Activity dealing that particular setting, pressing the back button returns you to the broader settings activity/view). If I were to keep each Tab as a TabActivity, it would still be fairly easy to change those internal transitions to views as opposed to separate Activities.
The main question is using ONLY views, no TabActivity/Activity group at all. The vast majority of the research I've done has been discussion about whether to use Activities or Views, or about specific syntax. I haven't been able to gather a clear idea of how to actually MAKE the transition to views across the whole application.
If I were to do so, wouldn't the entire app now be running in a single Activity - the one hosting the tabbed layout?
If (1) is true, how to manage this? Despite ActivityGroup being deprecated, all of the Android documentation still seems to state that it is preferred to use separate Activities for separate aspects of functionality--which makes sense. Did the Android development team simply decide that the costs to the stack and the device made the TabActivity implementation ineffective?
If the application is running in a single Activity that manages different views for each tab (and then different views WITHIN a tab when necessary), should I have one single enormous onClick method to handle all clicks from any clickable view, handling input based on which view is active? Or should I register and de-register all of my Listeners programatically?
With a single Activity, won't any click listener or any broadcast receiver be running all of the time, consuming resources even when unnecessary?
With a single Activity, the back button would exit the entire app from any point in its functionality. If I am using views, won't I have to consistently override onBackPressed() and carefully manage the app behavior to force it to behave "like an Android app?"
AM I THINKING ABOUT THIS COMPLETELY WRONG? It's possible that I am unintentionally attempting to recreate ActivityGroup and TabActivity functionality using views instead, when I should be taking an entirely different design approach to using tabs and Views.
When the people at Google say we shouldn't use activities as tabs anymore, and Mr. Mark Murphy so emphatically agrees, I'm inclined to believe. I simply haven't been able to research-up a way to switch without resorting to recreating a lot of Activity functionality by hand (which would probably include a variety of dirty hacks).
Appreciation in advance for anyone willing to tackle such a vague and overwritten topic.
Using Fragments is the new standard for performing tabbed style ui components, I think you must have just overlooked them because they are the missing piece to all your above questions. Good luck.
Don't forget that using the compatibility library brings Fragment support all the way back to 1.6.
And here is an easy Google recommended tutorial on using Fragments within a TabHost.
About 3) Split your app in as many Activities as you have different parts of the app. Today I'd even go for Fragements that can be easier composed to different layouts when you e.g. make the app for Phone and Tablet.
Most of the time, you can just set up the onClick listeners in the respective xml layout definition files like this:
<ImageButton
android:id="#+id/new_tweet_back_button"
android:layout_height="wrap_content"
android:layout_width="wrap_content"
android:layout_gravity="left"
android:onClick="done"
android:src="#drawable/back_button"
android:layout_below="#id/CharCount"
/>
Here the android:onClick attribute points to a method that implements the handler.
You don't need to de-register anything.
And instead of Tabs I'd go for the ViewPager which makes imo a much more natural experience with just swapping views by swiping left and right (see e.g. G+ app or market app)
As a final answer to my own question:
Using fragments in tabs DID solve all of the above issue.
So, instead of an Activity defining tabs containing other Activities, I have one large FragmentActivity that sets up and switches the views of the various fragments. The click methods defined in the XML for each tab view belong to the FragmentActivity, and I opted to have each onClick call a corresponding method in the appropriate fragment (passing a context if necessary) so the code for manipulating each view programatically can stay in the appropriate class.
THIS IS FOR A PHONE USING THE COMPATIBILITY PACKAGE, not a tablet or Honeycomb, so I can't speak for those unfortunately.
This solution seems to have worked well for me. I recommend anyone looking at the same issue to check out:
thepsuedocoder blog post:
http://thepseudocoder.wordpress.com/2011/10/04/android-tabs-the-fragment-way/
Android documentation on Fragments:
http://developer.android.com/guide/topics/fundamentals/fragments.html
The API demo "Fragment Tabs"
http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/index.html#Fragment
I want to create an activity, which shows a question with 4 answers, and at the bottom of the screen i want to place a timer.
I have already found timer example, and i created a question with the answers. the problem that they are 2 different projects and activities, and i am looking for the best way to implement it. i think i can't show 2 activities on one screen, but i can show 2 views or shell i use the ViewGroup, or maybe to copy-paste one of the activities code to another ( its the easiest way but probably the most ugliest way to implement it).
please tell me what is the best way, that i will study and not to waste time to study all the ways and only then to choose one of them.
welcome to StackOverflow.
You are correct in that you cannot display two activities at once. You must instead look into how layouts work in Android by reading some tutorials on the Android developer guide.
For your layout, I would recommend using a LinearLayout with four TextView objects inside it containing the questions (and perhaps your EditText objects below them) as well as your timer. Make sure they are all inside a ScrollView so the software keyboard doesn't force it all to be squeezed up. This is how I would approach it, but I encourage you to read about how layouts work and use the XML resources.
The Notepad tutorial is an excellent way to get started with views and text entry, as well as using SQLite databases.