I have a technical problem about my architecture. I explain my goal with this project.
I want to create a modular application. So I have created several modules; some have a UI and others do not.
My UI application is divided in three parts:
one part, is the header, which display hours and some technical information
another part is a list view where we can select the module to display.
the final part is the content of the module or the default screen.
So I tried to explore fragment where each item of my listview is a fragment. According to user's click, I load and display the view of the module in the content.
Each module do its treatment when it receives a intent from a broadcast.
An other idea, is to create, one view per module and attach this view to my current view (not create dynamically but with an xml).
I am so confused with the type of architecture to use.
If anyone has suggestions.
This sounds like an ideal use for fragments. The guide topic on fragments explains the general approach and also discusses FragmentLayout.java, which is part of the API Demos sample project.
Related
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.
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.
Android Studio 0.8.10
I have developed an App that has 3 fragments. I have just used 1 Activity and when I want to display a different fragment I just replace the existing fragment with the one I want to display. However, as I have 3 fragments now, and maybe more in the future, I think this will get harder to manage.
I am just wondering what is the design pattern when programming with multiple fragments, should each fragment have its own activity?
I will be scaling this to Tablets in the future, so I am not sure what impact this will have if I stick with the multiple fragments and single activity.
Many thanks for any suggestions,
should each fragment have its own activity?
Yes, but you can also use nested fragments.
I think this will get harder to manage.
you are right but
i think you must match your app with some other widget for example if you have multiple fragments that want to show one after the other use viewpager or you can use horizontalscrollview. you can create tabs and sync them by viewpager and so on.
Yeah, this can be really hard to figure out. I think a pretty good analogy, from the web application world, might be a servlet and a frame.
An Activity is like a servlet. It is one page in your app's workflow.
A Fragment, on the other hand, is like a block of content. It might appear in several different contexts and it might be served by several different servlets.
In MVC terms, the activity is largely part of the controller. A fragment, on the other hand, is more like a view include.
Much of the time, those two concepts align. A page in the workflow frequently contains exactly a single block of content. As you have, wisely, noticed, though, when you get more screen real estate (on a tablet), it is entirely possible that a single activity will display more than one fragment.
A single activity, on a tablet, might show, for instance, both a list of selectable items, and the details for the currently selected item in that list. When you have less space on the screen, though, those two things would be displayed as separate workflow items. Clicking on an item in the list invokes an entirely new activity.
The content is constant. The workflow changes.
Most modern applications will use a Fragment to display Activity content. It makes the application more flexible and easier to adapt to wildly different screens.
I am building an Android application and would like to include a help component in it. The Help module would have a structure as shown below :
HELP
FAQs
Features
Placing Orders
Online Ordering
Mobile Application based Ordering
Phone Ordering
Managing my Loyalty Account
Signup
Points Catalog
Loyalty Status Tracking
Points Redemption
Accessing Order History
Purchase History
Insights
Reports
Setting Reminders
Helpline
As far as i could find, there are two ways of doing this kind of structure.
The first way would be to use a Multi-level ListView. The problem with this is that the code is quite complicated and that usually ListViews have equal number of child nodes. For example :- in the above mentioned layout "Features" has several children whereas "FAQs" has none. How would that work in a List View?
The Second Method is to use Buttons for all the first-level options and then create individual activity pages for each of the corresponding children. So the first page called "Help" would have 3 buttons as shown :-
HELP
FAQs
Features
Helpline
Upon clicking any one, a new page would open with either more buttons or some text; depending on what the user clicks.
My question is, which of the above two methods is better suited to my application? If there is another way to do this than the two i've mentioned I'd be happy to hear about that as well. I thank you for your time and patience in helping me.
Or you can use this open source project to create a TreeListView:
https://code.google.com/p/tree-view-list-android/
I can suggest the following structure:
The HELP Activity will contain 3 tabs
FAQ can contain the ListView of questions.
Features can contain the ListView with Section Deviders: Placing Orders, Managing my Loyalty Account etc.
Helpline can contain e.g. text and image.
This structure can be created using Eclipse Activities templates: Tabs or Tabs + Swipe or Swipe Views + Title Strip.
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