Until now, fragments were the recommended solution for having one screen inside another main screen, for example for list-detail pattern.
Now google has released Activity embedding: https://developer.android.com/guide/topics/large-screens/activity-embedding
With Activity embedding APIs you can take advantage of the extra
display area on large screens by showing multiple activities at once,
such as for the List-Detail pattern, and it requires little or no
refactoring of your app.
Is Activity embedding replacing fragments? or will fragments be a better solution for some cases? If so, for which cases will be better each solution?
Thanks for the post. I was not aware of this capability. As for your question, I think that last couple of lines of the link you posted answersit:
Modern android development uses a single-activity architecture with fragments, navigation components, and versatile layout managers like SlidingPaneLayout.
But if your app consists of multiple activities, activity embedding enables you to easily provide an enhanced user experience on tablets, foldables, and Chrome OS devices.
So, it looks like fragments are the way to go but, if your app is composed of activities that make sense to run side-by-side, then activity embedding may be useful.
Is Activity embedding replacing fragments?
Not really.
(though composables are replacing fragments (and views)).
or will fragments be a better solution for some cases?
With respect to activity embedding, fragments are a better solution in most cases. Roughly 0% of Android devices today support activity embedding, whereas roughly 100% of Android devices support fragments (either through the modern Jetpack implementation or through the older framework implementation). Also, fragments are for more than merely side-by-side presentation on larger screens (e.g., as pages in a ViewPager).
Activity embedding is for developers who:
Have an existing app that is centered around activities, and
Want to adapt that app to deal with foldables and large-screen devices without rewriting the whole app to use fragments or composables, and
Are willing to live with the fact that activity embedding is for Android 12L and higher
(though I think activity embedding is also around for Android Automotive, the "your car runs Android" OS)
Related
With Jetpack Compose, is it a viable way to develop an app by having a single Activity only, and have Compose manage navigation between #Composables? When would it be necessary to add more Activities or Fragments?
Long version: I did some Android development years ago, where you would work with Activities and it was necessary to have multiple of them in any non-trivial app as they were the 'primitive' building blocks of every app. Then, Fragments came along and it was possible to host different ones within a single activity (they supported replacement etc. all with animations) and suddenly it was possible to implement the same app with fewer activities.
Years later, I'm back to Android development, this time with Jetpack Compose. I have already written an app with a couple of screens, using Jetpack Compose Navigation (https://developer.android.com/jetpack/compose/navigation), where #Composables are replaced and I'm very happy with by how much simpler everything has become. It seems that it is now possible to have an app with just a single activity, possibly without fragments either. I think that sometimes different activities might be necessary, e.g. if the application can process various Intents, but even then Compose Navigation supports stuff like deep linking etc.
With Jetpack Compose, is it a viable way to develop an app by having a single Activity only, and have Compose manage navigation between #Composables?
That is the theory. It remains to be proven for massive apps (think Facebook), but for small to mid-size apps, as far as we know, it should be fine.
Also note that the single-activity architecture pattern is not new to Compose UI — some developers have been going that route with fragments for the screens.
When would it be necessary to add more Activities or Fragments?
Assuming that we do not encounter some practical limit, the primary scenario for needing other activities and/or fragments would be for integration with framework classes or third-party libraries, where those external dependencies expect activities or fragments.
For example, app widgets can have a configuration activity. It is possible you could have your one-and-only activity handle that case too, but you might find it simpler to have a one-off small activity class just for the app widget configuration. That way, your main activity class does not get cluttered with logic for trying to distinguish between normal launches and app widget configuration launches. More generally, activities become entry points into your UI, and you probably only need as many activities as you want distinct entry points for different roles.
And, overall, "everything in moderation". If having something be implemented as a separate activity or fragment will help your app materially — ease of initial development, ease of maintenance, etc. — use it! Just because it is practical to have few activities does not mean it is bad to have more than one activity. We just now have even easier means of not forcing multiple activities where we might not need them.
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.
As per Android design guidelines to support multiple screens(Phone and tablet),
In Tablet, we use single activity and load two fragments
In Phone, we use two activities A and B with master-detail fragments load in each activity.
In phone,why we need to start another activity B and put detail fragment on it? simply we can replace master-fragment by detail-fragment in Activity A itself?
That is certainly possible. It will make Activity A more complicated, though, and overall it may not simplify your app.
Indeed, Google now recommends using a single Activity.
Today we are introducing the Navigation component as a framework for
structuring your in-app UI, with a focus on making a single-Activity
app the preferred architecture.
For very long time, I think what is the reason of using fragment in Android if I just develop the application for Android Phone only but not 10.1.
Is it necessary to use fragment? Also, what is the usage of fragment,
I found that it may use for 'tab' and 'separate view'...
I really think it is very confusing. Can anyone explain briefly and give example?
From documentation
You can think of a fragment as a modular section of an activity, which
has its own lifecycle, receives its own input events, and which you
can add or remove while the activity is running (sort of like a "sub
activity" that you can reuse in different activities).
Some advantages are..
A particular UI part, once done in fragment, can be reused in
same/different activities.
You can separate different sections of UI, hence code will be neat,
and easy readable.
The ability of fragment to be able to reuse is very helpful when you are creating applications for different kind of android devices (phones, tablets). A well designed fragment can be just plugged into your UI hierarchy.
Fragments is a new concept introduced in 3.0 version.
The basic purpose of fragments is:
Fragments are designed to use the device UI space efficiently.
When you are writing an application in android, then some people can download it into phone, some into tablets. If you see the space in tablets it will be little bigger than phones. You should be able to use that space efficiently. But you can't keep writing different applications one targeting for phone, and other targeting for tablets. In order to do it efficiently, i.e writing only application that can fit well with all screen sizes, we use fragments concept.
fragments are designed as a reusable UI components between more than one activity.
Once you design a fragment, you can view it as a detachable independent unit, so that you can plug it into any activity where ever there is a space. That means you can reuse the code designed for a fragment.
Fragment you can think of it like a sub activity, which sits with in an activity and which contributes its own UI to the activity screen.
Fragments are always part of an activity. With out an activity, a fragment will not exist. So your fragment life cycle will always be affected by activity life cycle.
An activity can contain more than one fragment. Similarly a fragment can be re used in multiple activities.
If you use Fragment in your application, your apps will support all the device like small device, tablet and even google TV. In one .apk file, we will have different design for various devices.
This is the best Android tutorial that I've ever found. Section 21 covers fragments
Refer Here
Could somebody please explain the exact advantages of using Fragments? In what cases should we use Fragments?
For what I understand, this framework:
Helps reuse existing code - if I implement functionality in a Fragment, then it's relatively easy to display this fragment in multiple parts of my app, when the functionality is needed.
Helps dealing with multiple screen sizes - a device with a huge screen may be able to display multiple fragments at once, and for smaller devices I can display the fragments in separate Activities.
Is there more to this framework?
Edit:
I've been using Fragments quite extensively in a larger project for 3.0 tablets. To me the greatest advantage was that using fragments I could break up the logic that would go in a single, monolithic Activity into multiple, smaller Fragments. Big screens mean huge Activities, difficult to read, understand (especially to new team members), develop and maintain. Fragments certainly helped in this matter.
Is there more to this framework?
Animated effects available when dynamically adding and removing fragments from the screen
Automatic BACK stack management, so the BACK button can remove dynamically-added fragments before eventually exiting the activity
Integration with the action bar for tabs, as a replacement for TabHost
Integration with the action bar for "list"-based navigation (really a Spinner in the action bar, toggling between different fragments)
Somewhat easier handling of configuration changes courtesy of setRetainInstance(true)
Also, responding to #Jim Blackler:
I share your confusion, since it's always been easy to customize Views which seems (to me) to solve all the same problems.
Everything offered by fragments can, by definition, be done using Views, simply because fragments are built on top of the view framework. However, fragments make more complicated scenarios involving dynamic fragments a bit easier IMHO.
Moreover, fragments in conjunction with the action bar seem quite likely to be a long-term area of attention for Google, meaning I expect a fair amount of additional work in this area over the next 2-3 releases.