I am new to android development, and we have a very specific requirement.
We need to change the content/layout/flow of the app on the fly. For e.g. we have a layout which consists of some images, textarea and textboxes. There might be a request coming to change the textarea to a textbox.
We thought about this and are thinking to provide the apk with a json/xml which will contain all these changes.
My question is will it be possible to re-draw the objects again dynamically and change the content?
Yes this is possible. You can dynamically design what has to be displayed in your Activity UI screen. If you feel there are only 2 or 3 different UI screens that would be repeatedly used, then you can have XMLs for these screens and you can just change their labels in OnCreate() of Activity class before rendering. LayoutInflater class would be helpful here.
When you design a Android Application with Activities and Fragments your XML layout definition is always static. If you want a true dynamic layout structure you should use a Web View with a HTML content pointing some URL.
As Rahul says, another approach is to manage the "default cases". For me that is the standard way to design an Android Application.
The dynamic content (values) can be done with a simple http call to server you can get values for your views.
The navigation could be handled by switching Intents, but, definitively you have to associate these intents to UI elements like buttons in the most cases, and ¿How you can do that if your layout is changing over time?.
I think, that the WebView could be a very easy solution for your problem.
Related
I am working on an application that has several states that matter to the user, online vs offline, how far out of date the local application database is, et cetera. I understand that both non-persistent and persistent notifications are available in android, and might be appropriate in this scenario. However, in our organization's iOS application, there is an 'information bar'.
I realize that this is somewhat of a departure from material design. Is this even possible? I'd like to extend the App Bar in some way as opposed to creating a fragment that I add to every activity if possible.
Try any of the following
1) Replace the action bar with toolbar and customize the design on your own and handle it.
2) Create the separate layout file with the above design and then include it in any screen using the tag <include/>
You can do this a custom Toolbar class or with Fragments. For the later option, each activity will have the user information at the top, either as a view or a fragment. The "normal app stuff" will be a FrameLayout which can hold one fragment at a time. See the Fragment tutorials on http://developer.android.com.
There aren't really hooks for extending the toolbar- in fact Google has deprecated a lot of stuff it used to be able to do (such as tabs in the toolbar). Your best bet is to use a custom fragment at the top of every Activity.
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 am very in doubt of the structuring of my application. When to use Fragments is a big question for me still. I understand the concept of fragment, but I would like to know how more experienced programmers use them. Is it really only when there is a specific task the fragment should do?
For instance, POP-UPs, what layout would be better used?
And back to the fragments, do you usually have a skelleton fragment that can be used for more than one thing, and then reshape it to different final forms (minor changes) or would you just use different fragments if the layout changes?
You should use fragments in a few situations but its going to depend on your app really.
If you have a layout that is going to be used in multiple places and the code is relatively the same, that is a very good candidate for a fragment so you can keep code down.
If you are making an app where the layout changes based on orientation or device type (tablet vs phone) then fragments are highly recommended to hold different layouts. It makes it easier to change or show multiple layouts if need be on a tablet.
I'm sure there are more scenarios but I would say these are the basics for fragment decision
The most common way I use them is as a kind of plugin layout for my activities. Let's say I have several activities and all of them need to display an address, phone number and some buttons (call number, launch navigation/gps, etc). I pass the fragment the id and the fragment does the legwork of grabbing the information and populating fields for my activities. This way, if I need to add anything, say an email address, I just need to modify one section of code rather than each activity and layout file.
I'm working on an Android app, which when the user taps on an icon, a Layout defined (for now) in the main layout slides up with some information.
The problem is that I have icons of different types, so when one clicks on one type of icon or another, the information in the pop up should be different (there are different objects with different structures behind those icons).
What possibilities do I have? The programmatic way just does not seem elegant enough. Are there any templating frameworks in Android? Please provide some examples, too.
You could sub-class your icons (that means the types that are shown with each icon), like having each one it's own fragment sub-class, an then you can use a different layout on fragment.
Here is more info about Fragments
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