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.
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.
Good Day everyone.I have searched internet and hardly found that it can't be like that but i really can't believe.So i decided to ask here whether is it possible to inflate layout which will have its own activity i mean JAVA CLASS where i would type the code.So just for this case.Imagine we must have google maps on screen and as well as separate screen of list view people all nearby.So in that point we want to inflate the layout onto google maps view.But as i can logically think it will be horrible to write code all in one class by side of performance,so I'm looking for alternatives to inflating a layout,is somehow we can bring activity on main screen and don't lose that screen as well?This is all questions.Thank you very much beforehand!
If I have understood you right, you want to have two layouts in one Activity?
You should use Fragments for it purpose. You can add as many as you want in one Activity, and manage them dynamically. You can find solution here. Also, look at this solution.
Edit:
The question is ultimately about if there are any defacto standards or Google recommendations on how to implement the below question.
Origin:
I have recently started to have a closer look at the Fragments concept in Android. I do get the idea of it (or at least I think I do) and I also see the need for it. I have no trouble understanding the technicalities behind the implementation of my fragments. What I seem to have problems understanding, though, is how to compose the final layout of my application, so that it automagically works on a large tablet as well as a small smartphone?
I have my list fragment (e.g. MS Outlook-inbox-list) and I have my detail view fragment (e.g. MS Outlook-email-preview). On a tablet I would naturally like to show these two fragments in a single activity, but on a smart phone I would like to show them in two different activities while there isn't necessarily room for both of them on a single activity.
How do I go about to solve this?
Do I have to implement three activities in my application (the all-in-one tablet activity and the two separate, smart-phone specific activities)? But how can the application then decide on which implementation to use (1 or 1+1)?
Usually my activities play the role of the 'controller' (according to the MVC paradigm) but, as of the above question, I would have three controllers. Which construction would play the role of the root controller? Should I write a 'master activity' (without UI) which programmaticaly tries to decide which device it lives on and then call the suitable fragments activity accordingly? But then; how can I - in a well defined manner - find out what type of device (tablet/handset) my application is running on?
I guess I could post some of my code but I don't think it would clarify my problem any further as it's more a question of architectural choices than implementation specific.
Cheers,
dbm
Do I have to implement three activities in my application (the all-in-one tablet activity and the two separate, smart-phone specific activities)?
No, probably only two. One is responsible for loading the ListFragment and, if there is room, the detail fragment. The other only loads the detail fragment -- this activity would be started by the first one if the user taps on a list entry and the detail fragment is not displayed by the first activity.
Usually my activities play the role of the 'controller' (according to the MVC paradigm) but, as of the above question, I would have three controllers.
IMHO, with fragments, the fragment is your controller. Activities are an orchestration layer determining which fragments are visible and handling cross-fragment events.
But then; how can I - in a well defined manner - find out what type of device (tablet/handset) my application is running on?
The simplest solution in many cases is to drive it by layout XML resources.
For example, in my above recommendation, the first activity could have two different versions of, say, main.xml. One (res/layout/main.xml) loads just the ListFragment. The other (say, res/layout-large-land/main.xml) loads the ListFragment and the detail fragment, or loads the ListFragment and a FrameLayout container for a dynamic detail fragment (one you would define via a FragmentTransaction). The activity itself determines whether it is managing two fragments or one by determining if the second fragment (or its FrameLayout "slot") exists in the inflated main.xml. That way, if you change your layout rules in the future (e.g., res/layout-sw600dp-land/main.xml), your Java code does not need to change.
There is nothing stopping you from using Configuration and DisplayMetrics to try to make decisions in the Java code as well.
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..
I've recently started developing Android Apps, and whilst the model is making more sense the more I look at it, I cannot do something (nor find any reference material on it) which to me seems quite simple.
I have an activity which has five buttons along the bottom, and a blank View taking up the rest of the screen. I want, upon clicking these buttons, for an activity to be opened in (and confined to) this view. I can get a new activity running without incident, but this opens in a new screen.
If anyone can show me an easy way to launch a (sub/child?) activity within a view which is defined in the parent activity's layout xml file - equally, it could be created in the parent activity - you'd really be doing me a favor!
I'd recommend taking a look at TabHost. The tabhost is an Activity itself, and the sub-views are all Actvities as well.
Here is a good tutorial that'll get you going very quickly. There is a more work to create (optional) icons for the tabs (also describe in the tutorial).
Hope this helps.
Edit* You mentioned buttons being at the bottom of the screen. Take a look at this SO Question
You can achieve that by using an ActivityGroup... here is a simple example which shows how to do it using a TabActivity:
http://web.archive.org/web/20100816175634/http://blog.henriklarsentoft.com/2010/07/android-tabactivity-nested-activities/
Of course, you will have to change the code since you are not using TabActivities. Just take a look at the getLocalActivityManager and getDecorView methods that is what you will be using.