I know how to change the activity, without use of Master Detail Flow Template but I need to make an app with multiple Master Detail Flow layouts.
I think that a single Master Detail Flow Layout is already a little bit complex and confuse alone, but it must be more confuse when there's necessity of multiple app screens.
Someone knows a good tutorial on this?
I have the same need, did you ever get any response or found the solution? I have a List that is a Menu, with around 10 entries and each entry requires a different activity/screenlayout.
EDIT:
I have found this very good tutorial: http://www.michenux.net/android-fragment-swapping-325.html. After making the needed adjustments for my app, change until 10 different layouts in the detailFragment, based on item selected in masterFragment, it works perfect for me.
Related
I'm new to android programming pls help. It's just that I have this application modules created in Activities form. Now that I wanted to use the Android navigation bar to navigate between them, I can't do so, it seems that theres alot of things I would have to change such as the imports, the declarations, and omit certain methods etc. Is there a comprehensive manual for such task?. I just can't seem to find one. If there is, it's just limited to a few things. BTW, I just want to know how I would be able to do such task. If there is a for Dummies of it,would be the best.
Be better if it would also include the AppCompatActivity thing, I can't seem to combine it too with Fragments and Activities, :(.
You need to understand your app's architecture first. You need to analyse the flow of UI screens and the underlying logic they perform. If you want to navigate through your activities using Navigation Drawer, well, then converting all of them them into fragments isn't a solution! First find out which screens can perform flawlessly if you replace them with fragments and then go ahead with it. If you are new to android programming then visit Udacity online and watch all of their android tutorial videos! They have a bunch of comprehensive ones and the best part - it's free.
I've developed an android phone app in which the navigation is mostly activities and starting activities for results. I've read that in order to make the tablet layout look like 2 screens of my phone app one next to the other I should have made it with fragments. Is there another way to migrate my functionality to the tablet app? Meaning to keep the start activity for result but just concatenate two activities on screen? (it may sound stupid, I know). Thanks
In order to keep the software design simple and modular, fragments come in really handy. You can use the same fragment's UI design + working code in multiple places without changing much functionality.
Since you have the code built and running in terms of activities, it won't take much time to migrate/port it to a Fragment since the life cycle methods are pretty similar. All you need to do is study the life cycle of a Fragment and move code chunks from the Activity to the Fragment class.
You can study all about Fragments here - http://developer.android.com/guide/components/fragments.html
or maybe a training session here will help you more -
http://developer.android.com/training/basics/fragments/index.html
You will learn a lot and once you have tried it you will be able to comprehend the advantages in a much better way. In future always make it a point to design in terms of Fragments to have a much modular design.
Along with that I think you will also need to learn to design layout for multiple screen sizes. This link over here will help you understand how to support multiple screen sizes -
http://developer.android.com/guide/practices/screens_support.html
If a tutorial to do this very quickly is what you seek then this should help -
http://www.101apps.co.za/index.php/articles/converting-android-activities-to-fragments.html
All the best :)
It very depends on your app GUI structure. Sometimes, you even not need to adapt your GUI for tablet (if you build interface dynamically basing on screen dimension). As rule, if you have two screens where one screen is advanced or logical extension of other then you can union it into one screen on tablets for better informativeness. Secondary way, as rule, based on fragments.
You can achieve it with help of Activity group but it is deprecated in Api level 13, for more details please visit http://developer.android.com/reference/android/app/ActivityGroup.html, but I will suggest to go with Fragment as Fragment having nearly similar life cycle like as Activity with extra methods and features. Please refer link for more details http://developer.android.com/guide/components/fragments.html
I have read the documentation and some other questions' threads about this topic and I don't really feel convinced; I don't see clearly the limits of use of this technique.
Fragments are now seen as a Best Practice; every Activity should be basically a support for one or more Fragments and not call a layout directly.
Fragments are created in order to:
allow the Activity to use many fragments, to change between them, to reuse these units... ==> the Fragment is totally dependent to the Context of an activity , so if I need something generic that I can reuse and handle in many Activities, I can create my own custom layouts or Views ... I will not care about this additional Complexity Developing Layer that fragments would add.
a better handling to different resolution ==> OK for tablets/phones in case of long process that we can show two (or more) fragments in the same Activity in Tablets, and one by one in phones. But why would I use fragments always ?
handling callbacks to navigate between Fragments (i.e: if the user is Logged-in I show a fragment else I show another fragment). ===> Just try to see how many bugs facebook SDK Log-in have because of this, to understand that it is really (?) ...
considering that an Android Application is based on Activities... Adding another life cycles in the Activity would be better to design an Application... I mean the modules, the scenarios, the data management and the connectivity would be better designed, in that way. ===> This is an answer of someone who's used to see the Android SDK and Android Framework with a Fragments vision. I don't think it's wrong, but I am not sure it will give good results... And it is really abstract...
====> Why would I complicate my life, coding more, in using them always? else, why is it a best practice if it's just a tool for some cases? what are these cases?
I am sorry if I wrote too much, and thanks for your time. I hope I will get your attention, because I really need ideas and experiences about this topic.
Best regards, Ahmed
You shouldn't always use fragments. Fragments have their uses, such as when you want to page in and out parts of the screen or when you want to drastically change the UI in different orientations. When they make sense, use them. When they don't, skip them. I find they make sense in maybe about 10-20% of apps- I rarely see the need.
If there's a certain positive aspect apart from the simpler reuse of logic through different layouts, it's the ability of Fragments to be kept alive by the system at orientation change, aka while an Activity is reconstructed from zero, a Fragment can retain its instance, and therefore using them is more stable than an Activity. Also, switching between Fragments is quicker.
Personally, if I don't need to mess around with different orientations and layout sizes, I still prefer using Fragments and a singular container Activity around it, for stability and seamless switching between the different screens.
Its quite a general question and not directly related to a specific programming problem. But in my opinion good software is based on good design and therefore a good understanding and best practices. So your question is a good one for stackoverflow.
So, what about fragments. It took me a while to understand why you could or even should use them. As #pskink said, you can easily live without them. But if you are planning to rollout your software on different devices, you should definately think about fragments.
The screen resolution and density is not the only problem. Think about a smartphone. The screen is much smaller, so you can not present your app the same way as you can on a tablet. For instance a master detail flow. Left side, a list of elements and when you click one element, you will see details of that element on the right side. Easy to do on a tablet. But on a smartphone you would put the master-view into one fragment and the detail-view into another one.
You got two options to realize that scenario. Either programm different activities for smartphone and tablet but because they are actually doing the same logic, it's better practice to put the logic into fragments and reuse those fragments in two layouts (phone/tablet).
In an Android app, I have two screens* the user sees, one for preparing a query and the other for displaying the results. The right UI here is to have the query preparation in one screen, and then see the result on the second screen. Since this app is aimed at phone users, there's no need to display the two at once.
The traditional Android way is to use two activities, a QueryPreparationActivity and a DisplayResultActivity, and switch between the two. However, I've been hearing more and more about how the Android UI is switching to fragments. I can implement the two screens as two fragments and have the activity switch them, but is it worth the trouble? I will essentially be reproducing the Activity management code Android already has.
Is there a reason to use two fragments here?
*I'm using the term screen, because it isn't necessarily an activity...
Personally, I always develop using Fragments.
But the best reason I can give you for using Fragments is when you develop for handset and tablet devices you get a lot of reusability.
I know you already mentioned that there is no need to show both screens at once. But say later you were to develop the same "screen" for a tablet device and realize that the preparation screen is too barren and want to have both queryprep and display result show at the same time, you would have to write a totally new 3rd activity.
If you used fragments, you would reuse your 1 activity and 2 fragments, and that activity should be coded smart enough to determine the size of the screen and show the proper layout.
Code Reusability & Flexibility are the buzz words here.
If you have any questions please leave a comment and I will expand my answer. If you like my answer, please upvote and accept.
Fragments were introduced encapsulate UI elements and related behaviour into a single, reusable module. Before fragments you had to re-write the much of the same code that 2 or more activities had in common especially if you couldn't find a good approach to abstract the UI/control code into a super class. This was further complicated by the limitations that activities only call setContentView once. So sharing some code between activities wasn't all that nice.
Now, to answer your question, it all depends on you. If you think that further down the road you could use the QueryPreparation or DisplayResult ui as a module (layout and logic behind it) then go for the fragment implementation. It could be a different layout for landscape view on phone or if you decide to support smaller tablets like the nexus 7. If you are sure that it will never happen then stick with activities. Personally, I use fragments everywhere and they are a sure way to "future proof" your implementation for reuse down the road.
In short Fragments were introduced to accommodate the emergence of tablet/large screen devices and allow developers to create applications that will run across a wide range of screen sizes with very little change to code.
More can be read here at the Android Blog. That blog also details some of the finer technical details for the reasons for the move toward Fragments. Also introduced at Goolge IO 2012 were DialogFragments which you should consider using instead of Dialogs. Another blog post here describes them.
You're better off getting used to using Fragments and DialogFragments from the get go as this is the way Android is moving. Only use individual Activities if you really really need to do a quick-and-dirty app for say testing purposes. Fragments, in my opinion, do require a bit more code-work to incorporate and to initially get your head round but it's worth the effort.
I'm trying to get an example or a starting reference on how to develop a drill down structure. The best example I can give is, how Android navigates through it's own folder structure. Here is a screenshot to illustrate my point:
Some things I would like to point out:
I will have know knowledge of how deep the structure will run
Minimum API level 10
Could someone please point me in the right direction.
Many thank in advance!!
To those you are wondering how I managed this, I basically call the same activity, just with the parent ID (which will be located within the bundle). This way I can fill the ListView with the parent ID provided and let my BaseAdapter sort out which UI to display.
I don't know if the was the best way of doing it, but it worked for me.
Kind regards,
IMO, technically there is no limit on the structure depth. But for the sake of design, good user interaction with the app as well as for codes maintenance, I suggest 3 to 5 level deep is enough. If you must go further than that perhaps you should re-design the app.
And you may also use breadcrumb to improve structure visibility.
http://developer.android.com/reference/android/app/FragmentBreadCrumbs.html