I am having some trouble working with Activities and Fragments. I am in the early stages of app development and am ultimately looking to design the most efficient way of integrating two separate screens.
The first screen would be the "Splash Screen", It would present the user with the Logo, the ability to enter user information and sign in through either a database or with Facebook. There would also be a button available to allow the user to register for the app.
The second screen would allow the user to set up an account by defining his user information and would include a register button and also a connect with Facebook button.
I would like to know how everyone would approach the task at hand as I had initially designed the app designating 2 Activities to handle each screen. Recently, I have switched to being able to host the screens as 2 fragments under 1 Activity.
What are the benefits of each approach and which design would you opt for?
Fragments are mainly for allowing you to display two separate UIs side-by-side on large-format devices. Fragments can combine code and UI within a single layout, and they also allow non-UI "activities", but mostly they give you flexibility in showing the various views attached to an activity.
I'd choose 2 activities, since what you're describing is a progression of operations rather than multiple views into the same operation.
Related
I have an android app where I have the same basic activity for both signed and unsigned user. The difference between activities is that I want to implement the sign out button in the overflow menu for the Signed user and some button for saved data.
Should I use the same activity for such thing or separate activities?
I personally would recommend having one base activity and two fragments, one for "logged/signed in" users and other for unsigned users.
This particular approach can help you with various problems because you can have the base activity acting as a "controller" to the child fragments. Fragments are more flexible and less expensive in terms of resources. This way you can have one fragment handling the "signed in" state, and calling various methods that can be shareable across the other fragments, cause they are sitting under the same base activities (these methods that are "shareable" should be implemented in the base activity, or in a separated manager, in case you want to use them in other contexts (activities)). For more context about this Fragment vs Activity, have a look at this.
Back to your case, from my experience, I would use this approach instead of showing or hiding stuff, depending on the user state. This is because I always start a simple app, with one generic screen that treats various states, but then the app becomes more complex, and I end up needing to separate one fragment that is showing/hiding stuff depending on the user, to two or more separated fragments. Always treat each state as their own, instead of having one generic one that treats different states.
I don't particularly see any reason to duplicate work in order to either add or remove a button from the user interface. This'll complicate your development, testing and maintenance of your code.
I'd recommend using the same activity based off the information you've given.
I have an android application working in mobile, this app has two types of activities ones that loads a list of items, and forms that open when you touch one item.
Now I have to port the app to tablet and the layouts need to be fully restructured to fit big screens, so much that the java code has to be heavily changed so i thought to merge both activities in one as shown below
Is that possible?
And if its what i need to use, fragments?
Can each activity still in its own class?(this is critical)
Can each activity have its own network operations and AsyncTasks?
Yes as you said you can use fragments for your situation (Infact their main purpose is to support different screens without code duplication). So you'll have only 1 Activity class and 2 layouts for different devices and you just need to do some run time checks and perform actions according to them.
Here you can find tutorial :- https://developer.android.com/training/basics/fragments/index.html
is not possible because only one activity working in single screen in android. i have one idea to put two fragment in single activity then use your own AsyncTasks network operation.
From what I understand, and activity is equivalent to a "page" in a web app.
For example, the list view would be one activity, edit view another activity, and add view a third activity.
While this works as expected, android activities seem to operate as individual apps--the action bar is different for each activity and so are the menus.
Is my usage of activities above correct or should I be using some other mechanism such as swapping out layouts and views?
Fragments are a core part of activities - not that much different. The use of fragments comes since Honeycomb 3.0 and the idea is an option to split the screen in several fragments at once. For example if you look at the gmail app for a tablet - you have one fragment on the left dealing with navigation and then the next fragment on the right is the list of emails.
On a mobile device, viewing area is limited, so you it could be said that fragments sort of behave like an activity - you interact with one fragment, which triggers another and so on and so fort. But in the end you always reference a super activity of each of these fragments - for example when you want to access the context.
So if you just want to wrap web pages in WebViews, stick with activities. If your scenario might involve developing for both tablets and phones, then go for the fragments.
Alternatively, you can read about the design philosophies of both here:
http://developer.android.com/guide/components/fragments.html
Good luck!
Fragments are to be used when you have common feature across multiple activities. From my perspective you should use individual activities as there will be back-end code to support (fetch and validate data, i.e. business logic). This way you have more modular code. Fragments is a new feature from v3.0.
From what I know, Fragments would be a good option to be able use different configurations/real estates on different devices. For example, if you are on a device with big real estate like Tablets or TVs you can display more content in a single activity, on the other hand for a devices with smaller real estate you can show content based on a progressive manner.
See this: http://developer.android.com/training/multiscreen/adaptui.html
Note that Fragments are supported only on devices running Android 3.0, so you might have to use Support Fragments (See: https://stackoverflow.com/a/6528757/713778)
But Again it depends on your specific needs. I am not sure what your exact use case is, but I would suggest you to watch some Android design in Action for some examples to improve your design and make your app "User Centric" (See: https://www.youtube.com/playlist?list=PLWz5rJ2EKKc8j2B95zGMb8muZvrIy-wcF)
I recently came across this https://www.youtube.com/playlist?list=PLWz5rJ2EKKc-riD21lnOjVYBqSkNII3_k seems provide an in-depth analysis on User Experience.
I would recommend using fragment for web like views. Fragments are pretty snappy compared to activities and reusable.
But before you start, make sure to fragments are good fit for your requirements since they are supported from android 3.0.
You can declare fragments from xml itself or you can create frame layout and add that view in the code itself.
http://www.c-sharpcorner.com/UploadFile/2fd686/fragments/
The above link has a good example tabhost.
I've developed like 5 Android applications using only Activities (and from time to time Fragments for ViewPagers for instance).
I have to develop a new application targeting Android ICS for tablets and handsets, with a very simple and static menu bar on the top (like 4 buttons on a single line). I don't need any single-pane / multi-pane layout depending on if the user has a handset or a tablet.
Each button of the menu bar will open a different screen, always keeping the menu bar on the top of the application. My question is if using Fragments for each screen instead of Activities is the proper way to achieve this.
Apart from avoiding some code duplication (basically the behavior of the menu bar), I don't see any advantage of using Fragments.
EDIT
First of all thanks a lot for answering my question so precisely and so fast.
Your answers have been very helpful for me : for instance I was afraid of having just one single Activity one my app, but I now understand it's rather a good thing.
You wanted to know what my application will actually do, so... there will be like 4 different screens : a News screen, a Videos screen (with live streaming video players), a Search for past videos screen and a basic Contact screen.
My question is if using Fragments for each screen instead of
Activities is the proper way to achieve this.
Your scenario is pretty simple and you could go either way. I would choose fragments over activities mainly because:
always keeping the menu bar on the top of the application. - With a fragment based app you could have a smoother transition between the various screen(and it will also allow you to keep in place the buttons bar).
easier communication between the various screens of the app as you'll have all the fragments in one parent Activity(but as I don't know what your app does I'm not sure this is something relevant).
Your app may be small now but you may get new ideas/requests to improve it in the future and this may be an easier task to do when your app is composed from fragments(which should be designed as loosely coupled components). Again, not knowing what your app does, this may or not may be relevant. An example scenario would be the need(in the future) to insert a ViewPager for the content of the app(so you allow the user to also swipe to a page not only click a Button). Using fragments this would be very simple as you need to setup the ViewPager and insert the content fragments, using Activities would mean a lot more refactoring.
As Android documentation states: "An activity is a single, focused thing that the user can do."
However with Fragments we will be able to do many "things" within the same Activity as Reto Meier suggest. His suggestion is to replace a selection fragment by a content fragment within the same Activity (section "Within our code this produces a dilemma").
Lets say my application is a "bit" more complex, with many activities, with a complex navigation tree and designed with the "single, focused thing that the user can do" principle in mind.
Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.
Should I have one Activity to manage all the application fragments and fragment transactions? Like Retro Meier suggest above. Is that the recommended path to follow? Thus breaking with the "single, focused thing that the user can do" principle for Activities?
Or am I missing something? I hope ;)
BTW, I think Fragments looks great, but from what I have seen till now, only if you are creating an application from the scratch. Because making applications to be compatible with phone and tablet looks like going to be a bit tedious. Hope to be wrong :)
Dianne Hackborn already has answered (thx for the link mgv):
you could put your entire application in one activity in which you change the fragment structure as its state changes
So then Activity becomes a sort of container where you will be able to plug Fragments. I like the approach, but... in my app there are about 30 different operations available, each one requires about 2 to 4 screens steps to be performed(forms and selection lists), all of them differ and there are also navigation restrictions. It works fine with Activities each one handling one screen/step behaviour.
So then to port to Fragments I should move each screen logic to Fragments and use Activities as containers for each operation. Thus leaving Activities as the ones managing the navigation between Fragments for every operation, right? Looks like going to be a pain to adapt long applications. :(
Current Activity definition should change a bit btw. :)
Should I have one Activity to manage all the application fragments and fragment transactions?
That is impossible to answer in the abstract. However, most applications will have multiple activities, even in a fragment-based world. Some of that will be to accommodate smaller screen sizes, where it will tend to be one fragment per activity. Some of that will be required by the framework (e.g., inheriting from PreferenceActivity). And, some of that will be by GUI design.
Thus breaking with the "single, focused thing that the user can do" principle for Activities?
That portion of the documentation was written in 2008, perhaps earlier. Had fragments existed back then, I imagine the documentation would state that a fragment is a "single, focused thing that the user can do", with activities serving as an orchestration layer, determining what fragments are visible in what circumstances.
The documentation will not in all places be updated to reflect fragments, and even if it does, it will take some time. For the balance of 2011, at minimum, you will need to perform your own translations of 2008-era instructions to convert them to 2011-era fragment-based UIs.
Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.
I have no idea what you consider "completely different logics" to be. In a fragment-based app, most of your business logic will be in the fragments themselves. The activities, again, serve as an orchestration layer, determining what fragments should be visible and coordinating event handling. The latter will get a bit more complicated than it used to be, since sometimes clicking on an item in a list will bring up a new fragment and sometimes clicking on an item in a list will start a new activity, depending on screen size.
Or am I missing something?
To be honest, you are missing enough concreteness to your question to make it reasonably answerable.