I'm new with android apps development (but have some Java experience) and I am struggling a little bit with how I should design my app. For example:
When I execute the App I have a start page with the logo and two buttons: Register and LogIn. This should be the first activity.
1.) If I press the register button I see a page (another activity) with the input fields, a register button but also a Facebook and a Google+ Button.
2.) If I press the login button I see a page (another activity) with the input fields, a login button but also a Facebook and Google+ button.
Instead of implementing the facebook and google+ button twice, I thought about putting the google+ button and its functions into a seperate fragment and the same for the facebook button so I can reuse them.
Is this a "good" interpreatation of activities and fragments and if not when should I use fragments and activities? I thought about fragments like reuseable containers which can be implemented in different activities.
Thanks for any advice!
Activities, fragments and views have very similiar purpose, but on different levels. You can freely mix them as you wish as long as it's working for you. Personally I don't like fragments, so I'm only using activities and views in my apps. Here are the main differences:
Activities are the entry points. You can start your app using Intent to one of it's activities. You can't do that with other elements. You should use an activity when you plan an entry point. For example an email composing module which can be accessed by other apps.
Views are very light and simple. Use them to prepare reusable components, layouts and widgets. Views can be accessed by other apps only in a library form.
Fragments are somewhere in between. They consist of visual parts, data and application logic. Fragments can be used with backstack manager like activities, can't be launched using intents, can make use of layouts and widgets like views. Use fragments to create larger screens with backstack.
And similarities:
All three mentioned elements can be displayed multiple at the same time. Activities using ActivityGroup, fragments using layouts and FragmentManager, views using layouts.
All three have their lifecycles. Fragments have the most complex lifecycle, views - the most simple.
All three can be used to compose applications. You can place layouts and widgets on screen using activities, fragments and views in a very similiar way.
Basically activity consists of a window and a layout (and some data & logic). Fragment consists of a layout (and some data & logic). View is a layout or a widget (and some data & logic).
Answering your question - This means that your approach is fine. At least for me. If you plan to reuse these buttons only as a UI components, you can rewrite them as views.
Related
Hi everyone as the title say I am wondering whats the best practice to design an android app should I make multiple activitites for each interface in my app or one activity that has multiple fragments(note:I am using a navigation buttombar)
Depending upon your need you can choose between activities and fragements. Activity is more like a complete separate page and fragment is a small view that can be called in an activity, multiple fragments can be used to display activities UI .
Fragments can be used to make dynamic views check this link https://developer.android.com/training/basics/fragments/index.html. Hope this helps :)
I am making an app and want to make sure I am following good practices before I proceed further and potentially turn my app into a "big ball of mud" implementation.
So right now the general idea I have in my head is where you have a row of icons along the top representing the different pages you can click on. You click the button/icon and it takes you to that page.
So this icon-row along the top would be constant throughout most of the app. The only thing that would change would be the contents below that icon-row.
Is it considered acceptable practice to use fragments here? Use one main activity that has the icon-row at the top and then have the container below that "swap out" fragments based on the icon clicked? And then each page is really just a big fragment?
Does this make sense, am I following good practice? Is there a better way to do this?
I am making an app and want to make sure I am following good practices before I proceed further and potentially turn my app into a "big ball of mud" implementation.
If that happens, try a good brand of laundry detergent, at least if you are using Twitter Fabric.
So right now the general idea I have in my head is where you have a row of icons along the top representing the different pages you can click on. You click the button/icon and it takes you to that page.
A typical implementation of that in mobile apps is to use tabs that contain your icons.
Is it considered acceptable practice to use fragments here? Use one main activity that has the icon-row at the top and then have the container below that "swap out" fragments based on the icon clicked? And then each page is really just a big fragment?
Most modern tab implementations are based around using a ViewPager as the container for the tabs, so the user can swipe the content or tap on the tab to switch to different pages. ViewPager can work with plain views for its pages, but the stock PagerAdapter implementations use fragments.
Even if you elected to eschew tabs, using fragments for the pages (whether wrapped in a ViewPager or not) is reasonable.
The big thing to watch out for is memory consumption. Android devices do not have infinite RAM.[citation needed] You need to make sure that you have a modest number of fragments outstanding at any given point.
Yes, this is the proper way to use the parent activity or fragment with this "icon-row". You can use the Toolbar+menu for example, if you want to preserve the Android look, use tabs+ViewPager or use custom view.
Then, in this activity/fragment you will have a layout that will work as a fragment container. In this layout you can replace the fragments dynamically using the FragmentManager of parent activity/fragment. Each of these pages is a separate fragment.
So yes, this is good/common practice.
You may read the how-to about replacing fragments here
I have a workflow with several screens with different questions and answer-options. So there is a question on screen 1 and the user makes his choise -> the user hits the continue button -> screen 2 opens with another question -> user makes his choice and continues -> screen 3 opens etc...
But actually I'm not sure which is the best way to implement this behavior in consideration of a good maintainability and clearness. I think they are at least three options:
Every screen gets its own activity and layout file and I pass the choosen data trough intents.
1 Activity and different fragments, each fragment has its own layout. If the continue button is pressed, the fragment will be replaced with the next fragment.
1 Activity and different layout files. Just the layout gets replaced and everything else is handled in the activity.
Actually I already started implementing with option 2.) but I don't know if this is not "too much".
The Android API guidelines say that you should use Fragments for multipane UI and for reusability. But actually I don't want to build a multipane UI in this case and the fragments are not reused. So maybe 3.) is the way to go? Or even 1.)?
I would choose your option # 3. The reasons are:
Activity takes some memory compared to fragment or layouts. The interface between activities and fragments is a bit awkward, though I got used to it. I don't recommend it for your case.
I like fragments. However if all the fragments are similar in looks/feel, then why take the computer time for hiding/showing or replacing them. The reason for fragments is stated in Google web page like at Building a Flexible UI. I don't think you need a flexible UI as said in Google's intention.
I would suggest one Activity, at least one Fragment for all the questions/answers. You simply use one layout to change text/content. If the UI is different, then replace the layout with another. It's quite normal for an Android app to have so many different layouts anyway.
Android takes some memory to load layouts but it's quite fast and efficient.
For option 3 design:
You can use the inflate() method to load a certain layout and to replace one. A good example at SO link # Android layout replacing a view with another view on run time
I have a tabbed interface for my program - there are two tabs: take photo and view photos.
As the name suggests, the user can take a photo in "take photo" and the user can view photos taken in "view photos". Right now the way its set up I use one single MainActivity and I have TakePhotoFragment and ViewPhotoFragment -- question is: does this contradict the principles in which Fragments are supposed to be used in? I don't really anticipate having both fragments displayed in a single screen (e.g. on a tablet), but I don't see how I can use one activity for each because of the limitations of the tabbed interface (when I created the activity in eclipse, I was prompted to select what kind of layout, I chose tabbed layout, and automatically code for fragments within an activity corresponding to several tabs was generated)
Can anyone help? Should "take photo" and "view photos" be fragments or activities?
It should definitely be fragments.
This does in no way contradict anything, plus I do not understand your concern about showing both fragments in a single screen. If you do not want that to happen, you just program accordingly. That is certainly not something that just happens because of the choices that you have mentioned so far.
Fragments is the best method you can use for the purpose you mentioned above. You can check the below links to know about the usage of fragments.
Creating a fragment
Fragments
android fragments
android fragments tutorial
I need some advice for those who are experienced making Android applications. What I would really like to have, for my application's appearance: at the top, a title-bar which is a ImageView (content is a png), and at the bottom a series of custom buttons which make up a tab-bar like thing. In between the title and the tab-bar is the Content, which may be anything... (most likely buttons)
I have been doing this by making a RelativeLayout which specifies LeftMargin and UpperMargin for x,y coordinates--
Currently all of my activities are inheriting a custom MyActivity class, which rebuilds the title and the tab-bar at the time of onCreate. This seems bad to me!
PART1)
---A solution to Persistent data
Since the "tab-bar" and the title are persistent no matter what screen you're on during this application's run-time, it makes the most sense to store them somewhere... How should I do this? Make a singleton object that the Activity's ask for?
I thought a little about the singleton object, and I'm not even sure what I would store, since the Views that are on displayed during Activity A have activity A as context, and not Activity B.
PART2)
---Animation Aesthetics
I would really like to have the "Content" (the view in the middle between title and tabbar) slide out to the left, and the new content slide in from the right. I.e, I'd like the tab-bar and the title to remain fixed while the "activities" change. is this at all possible? What should I do to achieve it?
one idea I had, was to make all of the program in one activity! I would create an animation for the Custom View in the middle, and I would override the "back" button to navigate correctly to the previous Custom View. Is that a horrible idea?
Anyone have any advice?
Read http://developer.android.com/design. Most of the design principles can be applied to apps that run on legacy releases; it's not just limited to Honeycomb and Ice Cream Sandwich. Do consider the Action Bar and Dashboard design patterns.
I don't really recommend using just one Activity -- generally, an Activity should be a separate, encapsulated, pretty well defined chunk of functionality that can execute independently of other Activities.
To avoid duplication of your UI, consider reusing XML layouts.
To avoid duplication of your logic, consider using Fragments. You should be able to mix and match them in your activities.
To achieve the animation you describe, consider implementing a ViewPager.
Using the ActionBarCompat sample app and Android Support Library, you can enjoy modern goodies like Action Bar, fragments, tabs, and horizontal sliding transitions on devices running Android all the way back to Donut (1.6).