I've got a lot of experience with Java and C#, but I'm new to Android. I mainly use C# because I am enamored of the Control hierarchy. I love the plug-and-play of the ontology. I'm trying to understand the ontology in this new paradigm and I may have been given some false information.
With respect to Apps, that should be the largest component. Within the App, there may be several Activities. An activity can display a number of Fragments. AppWidgets appear to be a special case as they exist as a component of the App, but are shown on their own. And I was told that you can extend Buttons or ProgressBar to create your own components which again appear to be called Widgets.
As I said, I may have this completely wrong. Ideally I would like to create my own widgets which I can put on a Fragment, an AppWidget or an Activity; any of which I might compose into an App. All the online sources I've found only discuss Widget in the sense of an AppWidget? Was I given incorrect information? Can anyone clarify the ontology?
Thanks
"Widget" is a bit of an overloaded term. You will probably have better luck if you search for tutorials on "custom Views" instead. I'll include a brief rundown of various terms and what they mean at the bottom.
A custom View is pretty much anything that extends the View class (or any of its subclasses) and isn't part of the framework. Custom views can be used wherever typical Views are expected, e.g. in layout files or directly constructed in Java. One thing to note: only certain Views can be used in an AppWidget because they are running in another process outside of your app. This means your custom Views cannot be used in AppWidgets. In my experience this tends not to matter too much.
App: An application. Contains components, which are defined in the manifest within the <application> tag.
Activity: One of the four application components. Nearly always has an associated UI, composed of a hierarchy of Views.
Fragment: A framework class that helps modularize your application's code and UI. Fragments can be attached to an Activity and can contribute some UI to the View hierarchy of the Activity. They are entirely optional; you don't have to use Fragments in your app, and you can attach a Fragment without it contributing any UI to the Activity.
View: A UI component, such as text (TextView) or images (ImageView). These are also referred to as "widgets", and you may notice the framework classes are found in the android.widget package. Some views contain other views, so that you can build a UI hierarchy; these will extend ViewGroup and are referred to as "view groups" or "layouts" more or less interchangeably.
AppWidget: Something the user can add to his or her homescreen. This is provided by the app, but is not one of the 4 application components mentioned previously (it is managed by an application component, namely a special subclass of BroadcastReceiver). Most people colloquially refer to these as "widgets" because it's shorter to say and launchers used that terminology as well, thus conditioning users to it.
Related
I am implementing a second-screen integration using android.app.Presentation.
(second-screen meaning e.g. a separate display connected via HDMI)
All the setup etc works fine and I can display simple layouts with views on my second screen.
However now I want to reuse some components I use from within my Activities,
which are Fragments or DialogFragments.
But when I use the LayoutInflater available within the presentation, I crash with
Didn't find class "android.view.fragment" on path and when I "steal" the LayoutInflater
from the Activity, I can inflate the layout, but screen size and resolution is that of the 1st (main) screen of course.
Any Ideas how to do this?
Similarly, I have no access to a FragmentManager, and stealing the one from the Activity doesn't rather work. So I would have to recreate/duplicate my reusable component code and layouts redundantly flattened into a presentation layout. Doesn't sound too good to me.
I found the cwac presentation framework; but I don't fully understand what it does (yet) (aka what I understand what it does, does not solve my problem) and it crashes on my Android 7.1.1 anyway (bug opened) so please do not just point me there.
Cheers & kind regards,
Tom.
I'm trying to get into Android development on Android development's terms. To this end, I don't want to push onto it a mental model that is largely based on WinForms development.
My problem is that I find Activities and their fragments too cluttered. There are interface implementations all over the place. There are type hierarchies that get smushed into my Activity files. I find it, to say the least, off putting. When I see examples on the developer.android.com site they seem to advocate this complex, everything in one massive file model.
At the same time, I realize that the demo code is just that, demo code. What's the right approach when working with Android elements?
For example, I would like to have a GridView to display some graphics and allow the user to click on them, or long press on an item to do something. I can do this within an Activity.java file, within a public static class Fragment nested in the Activity.java file. I can then implement the on tap and hold listeners. At this point, I feel that this is a rather muddy design.
Would it be Android-Idiomatic to have instead a class that that extends GridView with my specific implementations of the listeners? In this instance, if the GridView decided to navigate somewhere, it could.
The question really applies to any complex view within Android. ListFragment seems nicer since at least I'm getting a type hierarchy explicitly here. I can have the fragment react to various item events.
As I've started to adopt Fragments more and better but also as Fragments functionality is increased (Fragments in Fragments, MapFragments) I'm starting to reach a point where I need to define when I should make a new View/Action as a Fragment or as an Activity?
An Activity is defined as:
An activity is a single, focused thing that the user can do.
But a Fragments have kinda taken that definition instead as described in the docs:
For example, a news application can use one fragment to show a list of
articles on the left and another fragment to display an article on the
right—both fragments appear in one activity
This is two things the user can do in one Activity with two Fragments.
So I'd like some input/help to figure out what is the best approach to decide if I should make a new action/view as a Fragment or as an Activity?
The answer depends on you and your development practices (or those of your company). However, my opinion is this: At a minimum, if you think the functionality being developed could be used within multiple Activities, or if it could ever be used in an Activity alongside another view (as on a tablet), then you should make it a Fragment.
We've recently adopted the philosophy of creating Fragments in all cases. Our Activities are now just top level coordinators, basically the glue that brings things together. This makes for a consistent and flexible architecture. This is important to us as we have numerous engineers at a couple of locations working on code.
An Activity is defined as: "An activity is a single, focused thing that the user can do"
That is more an issue of dated documentation than anything else. Activity has that same definition... when we are on a smaller screen size (e.g., phone). As you move up to larger screens, the odds of an activity being more complex than "a single, focused thing" increases.
So I'd like some input/help to figure out what is the best approach to decide if I should make a new action/view as a Fragment or as an Activity?
Here is my general heuristic:
If you anticipate that such-and-so piece of UI might exist standalone on a phone-sized screen, but be used in tandem with something else on a tablet-sized screen, make it a fragment.
If you anticipate that such-and-so piece of UI will always exist standalone, just create a simple activity.
If you anticipate that your ability to anticipate is not that good, err on the side of making more fragments. For example, you might say, "well, help will never need to be alongside anything else" and make it be an activity. Then, if you realize that other pieces of UI might benefit from the help being side-by-side with them rather than off on its own -- so the user can read the docs and perform the actions at the same time -- you will regret not having made help be a fragment, as you will have to do some re-work.
If such-and-so piece of UI would never exist standalone -- in other words, if it is more like a single widget than a full activity -- and you anticipate using it on multiple projects, make it be a single widget, in the form of a custom View or ViewGroup.
But, as jsmith indicates, there is no universal right or wrong answer. BTW, AFAIAC, jsmith's answer is the correct one here, but I was going to be way too wordy for a comment on his answer... :-)
I've been developing in Android since 1.5 so I have been developing from quite some time Activities and recently Fragments.
Quite frequently fragments left me with a sour taste in my mouth... an example was when I needed a kind of paginated Dashboard with buttons. For that I used a ViewPager + 1 fragment per button. I had all kind of problems because before Android 4.2 fragments couldn't be nested.
Another problem was the asynchronous mode of function of the fragments that when the needed to be moved from one place to the other quite rapidly it had all kind of misbehaviours.
Don't think that all was bad... in more simple cases, the use of fragments worked quite nicely.
So, in my opinion, whenever you have an area that is self-contained, that isn't moved frequently on the views, that can be reused in several screens and also you support tablets (or my in the future), use it.
If you need nested fragments, views that are re-arranged quite frequently, or code that will not be reused, don't.
I am having one app where i created a view. And i want to use the same view in another application. Is there any way to pass the second apps context as parameter to the view. So that the view is created second application's context.
Or is there any way to create a view library so that many applications use that view library to create views.
Ron
You can create a class and call it CustomView wich extends View and customize the view. Then, you can use it in both apps.
However, since you already created your view, my suggestion is to copy-paste the code into your new app unless you are planning to use the same view in future apps.
I see two ways to interpret your question. 1) You have a custom View (like a custom control) and want to share it. The earlier answers address that interpretation of the question -- how to share the code that implements the View.
Another interpretation is you want Application "A" to bring up a screen defined by Application "B". That is you want not only the View, but the behavior behind the view.
For this use I would suggest sharing Activities or Fragments rather than Views. You can have application A use Application B's Activity (if Application B is willing) by sending an appropriate Intent.
I would suggest you follow iturki's method or just copying the same layout into each application xml layout file..I dont think that is to difficult. It is practically easier.
In Android source build system you can usually create a jar and export that jar to multiple apps to share the common functionality. Never tried doing it independently. You can check Phone app on Gingerbread. Some functionality is shared between Phone app and Contacts app. Though these are not sharing Views, Ideally you could take this idea forward and implement Views
I've created a custom navigation bar for my application. One of the things it (currently) does is allow you to switch between various activities in the application. One part I still have yet to solve fully is how to keep the navigation bar constant on the UI while the view above it switches to another activity.
This google groups thread seems to ask this very question and the solution seems to revolve around using a LocalActivityManager to add the Window decor of the new activity to a ViewGroup of your current layout. I'm curious if anyone has done this before and what their thoughts were?
In particular I'd be interested in the pros/cons of the LocalActivityManager/multiple activities approach vs one super activity which switches multiple views (rather than activities).
I would guess that Fragments would be the recommended way to accomplish this now: http://developer.android.com/guide/topics/fundamentals/fragments.html They have a lifecycle like activities but are meant to be added and removed from layouts. With the compatibility library (http://android-developers.blogspot.com/2011/03/fragments-for-all.html) you can use them all the way back to OS v1.6. As a bonus this is the way that the OS has been moving in terms of reusable UI components since v3.0, so you should be in better shape for the future.