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
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 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.
I have an Android project I've inherited from another developer.
The original code was hacked together using a single View and a single Activity. The view class has a State variable that is switched on during input and rendering.
Each "screen" is a single bitmap rendered directly onto the screen. There are no layouts used at all. To make things even worse each variable in both the View and Activity classes were all declared public static and would access each other frequently.
I've reworked the code so it is now somewhat manageable, but it's still in those original two classes. This is my first decently sized Android app so I'm not completely sure where to go next.
From the looks of things, each "screen" should have its own View and Activity. Is this the general practice?
If so I need some way to share data between the separate Activities. I've read suggestions to use a Singleton class that holds generic data. Is there any other ways that are more built into the Android framework?
Thanks in advance.
I would recommend using one activity per screen, or rather, per function. An activity generally has one associated view that draws the UI. If all the activity does is display different bitmaps, than you can define an ImageView in the layout and display the various bitmaps in that ImageView.
Using public static fields is bad practice in Android Activities. Activities should not access fields in other Activities at all, they should pass data to one another through the intent, or via a database, or via shared #Injected classes.
From what you write, it may be easier to start that app again from scratch, than to try to fix the current app. I have been there, done that, afterwards regretting not scrapping the app and starting from scratch.
I am trying to build an app in which I want to go to a new page through swipe-say. I have about 10 different pages and I want to go to these pages by swiping. Can I implement these pages as separate activities? Can I swipe from one activity to another? I strongly like to implement these pages in seperate xml files rather than creating everything in a single xml page. But as far as I have searched, there are no proper tutorials or blogs giving an appropriate example of a program implementing swipe. If possible, provide some working codes.
Thanks in advance.
It seems that a FragmentPager is what you want.
Examples and code on the linked page.
If you build for earlier versions of Android, the necessary code is included in the Android Support Package.
In Android, swipe is not identified as a particular gesture.
You can use a OnTouchListener registered on your view, and animate your view if the gesture exeeds a certain threshold.
You can then launch a new activity, or in a simpler way, use a viewFlipper.
Please try the attached link View flow.
I feel it will fit your needs perfectly. You can even create different xmls and inflate them into different view objects and then use the "view flow" to switch between them.
The "view flow" is perfect for handling both simple & complicated views. The flow indicator on the top of the screen is optional.
I hope it helps..