Ive been doing some reading, and got a little confused. In Android development, is there a difference between a Screen and an Activity? What are they? I was reading about an Activity having multiple screens.
An activity is a piece of your application which should handle a single specific task (example, receive input from the user or display images or whatever you want).
The part you are referring, "supporting multiple screens" can be explained as a best practice you should follow when developing your application: this is simply the designing of proper layouts based on different possible screen sizes and densities. There is nothing such a "Screen" class in android.
So the relationship between an Activity and the moltitude of screen sizes out there is mapped by the layout XMLs defined in the proper layout folders in your application. The android OS will choose and handle the layout for your activity based on the hardware screen available and the closest-to-best layout you defined.
Think of an activity as a "window" on a desktop OS (like Windows7 or MacOSX or Ubuntu) that allows you to see only one window at a single time. If you have 10 different activities in your app the user may see up to 10 different windows. The android OS will pick the most compatible layout you defined based on the real screen display the user has and places the GUI component accordingly.
An Android activity is the screen you see on your device ie a welcome screen with buttons or whatever. The activity can call other activities which then will show on your device screen. An activity is where you define all your logic for what happens on your device (Of course you can define the layout of your activity in a layout xml file).
An Activity is similar to a form(If you are aware of web development form).
Screen is just displaying activity so there is no object like screen.
For layout control of an Activity you can use main.xml ( Also it can be done using code in your activity extended class.)
Related
I have a Kivy app with multiple screens, some of which I'd like to share a common widget (a dashboard of sorts). My current implementation simply includes multiple copies of the widget in each screen.
This works fine, but I've noticed that the on_change handlers for properties of this widget (of which there are many, since it's updating info regularly) fire once for each screen, even though only one screen is visible at a time. This seems wasteful.
I'd rather not refactor the layout to not use screens (i.e. have a single screen and just switch out the widgets that are not common between screens when "changing"), nor do I want to add if this_widget_on_current_screen: style logic to every property's on_change handler.
My question is if there's a way to share a single widget instance between multiple screens?
I'm working on my small app and I have terrible problem with dialogs. Partially my question will be technical, partially general.
For example I have the following scenario: 1) user select file type 2) user select file 3) user select some additional options - list of about 5/6 options.
I'm wondering if to do this as some kind of three steps wizard (for each step separate dialog) either as one activity with three buttons/elements for selecting the appropriate elements. How do you think? I would like to have my app giving some kind of light appearance to users, thus I would prefer not to have heavy things. have you seen any good examples of more complicated dialogs/activities? Any official guide for more complicated dialogs?
Moreover some technical questions:
1) Is that possible to have activity (full screen) looking as dialog (style)? If yes, how?
2) As for now I use DialogFragment. However android by default sets its dimensions in the way that there is no need to resize them when changing screen orientation (screen smaller dimension is the base for setting dialog size). In consequence when having screen in vertical orientation huge part of screen is not used by dialog. How to change that to have dialog occuping almost the whole screen, but also resizing correctly when changing screen orientation and if possible with still keeping setRetainInstance(true) (less problems with dialogs when changing orientation)?
use the following line of code in your activity below setContentView(R.layout.activity_main);
setTheme(android.R.style.Theme_Dialog);
refer following link,
Android: how to create a transparent dialog-themed activity
Is it possible to create an activity in Android that doesn't take up the entire screen? I would like to create one that is only 1 pixel x 1 pixel wide and launch it.
No it is not. An Activity is designed to be the current active screen.
You can 'fool' people with the view that goes with the Activity, such as making it (partly) transparent but your Activity will still be the one receiving touches.
Create activity with dialog Theme by using this
android:theme="#android:style/Theme.Dialog"
Activities are often presented to the user as full-screen windows,
They can also be used in other ways: as floating windows (via a theme with windowIsFloating set)
or
embedded inside of another activity (using ActivityGroup).
If you want to create with given pixel you can not do it.. Instead you can go for Fragments, DialogInterface in Android which can be created with size specified in layout xmls
I want to know how to chech whether object is existed in layout.
To make clear, I want to check ListView is existed in layout for different screen resolution. If client device is tablet, I'll process for ListView and will make some action. If client device is mobile, I'll ignore this ListView and set visible mode to GONE.
You should define the default (say, phone) layout in /res/layout and the tablet layout in /res/layout-w720dp or something similar. See here for more information on qualifiers for layouts. Then you have defined your different layouting in xml and don't need to jump through hoops in code to make it fit to different screen types.
To know whether object exists or not, just try to find it with findViewById and compare result to null
Disclaimer: This is a link to post on my blog (there is no advertising). I think it might help you think about the way you construct your app to deal with phones vs tablets.
http://damianflannery.wordpress.com/2011/10/16/architecting-a-single-apk-app-to-handle-phones-and-tablets-on-android/
It sounds like your intention is to hide a listView from the screen if the users device is not a tablet. This is easily done using different layouts for different as mentioned in Damians blog post.
However the new correct way of doing this is to use fragments. The basic idea is you combine the code and layout into a fragment and only use the fragment if there is space on the screen. This means that your screen would be formed of 1 fragment if phone and two if tablet, one of which would contain and code for your listView.
Fragments - Android Developer
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.