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?
Related
This is the image explaining the usage of fragments. The first image shows two fragments and two activities.
Lame doubt. Why use two activities when the sole concept of using fragments is err.. using fragments instead of switching activities.
Depending on your goals you can do it either way.
The method shown in the guide can be implemented entirely in XML layout files so it is a better method to teach to a new user of fragments.
The method you suggest requires the developer to manage fragment transactions in code, which is not too difficult, but why do it if your app does not have any special behavior that requires the extra work.
Also, since the animated transitions between fragments look different than activity transitions, your method will reveal the use of fragments at the user level. The method in the guide uses fragments as a modular programming technique that is transparent to the user.
You end up with an app that uses available space on all device types, but on a small device it acts just like a classic app that users already understand.
The idea is that when you have extra room (such as on a tablet), you can display the content from what would have been two activities side-by-side rather than as two separate activities.
Think about a mail application. On a phone, you fn really only fit the list of mail on a screen, and you click on one to open the content of that mail on another screen.
If you did that on a tablet, there's a huge amount of wasted space; you can display the list of mail on the left side of the screen, and the selected mail's contents on the right side.
Because the list UI is the same in both examples, and the mail-display UI is the same in both as well, you can reuse that UI by including them as fragments. The logic for those UIs is also self-contained in the corresponding Fragment classes.
This allows the user to see more content with fewer activity switches.
What is the best way to go about designing an Android application that features quite a bit of formulas and conversions? I was thinking that multiple Activities with ListViews sort of like a tree with the leaves being the actual calculations. However, after reading Android design principles it's better to avoid a pure navigational structure and try to reduce the deepness of the app.
For example:
Main Menu
Conversions
Weight
Distance
Distance - Speed - Time
Calculate air speed
Calculate distance traveled
Weather
METAR
TAF
So by the 3rd or 4th screen we've reached the actual individual calculator. Does this make sense? And if it does, is there a better way of designing this (maybe using action bars or tabs)?
By using a very simple UI concept of Expandable Listviews, in which there is more than one child row for each section of the parent row, by tapping on the "Conversions", could expand into sub-rows, likewise for each section as you see fit, and treat that as a Main Menu in a sense of a word, that is, your main application screen.
The nice advantage is that the nesting of the menus in the Android way, is eliminated and can accomodate as many as you wish.
The third or forth screen sounds like it's too deep down the rabbit hole, how about instead having multiple tabs for each "type"?
For example;
[Conversions][Distances][Weather]
If you add an ActionBar to it, you could have a type of filter as the GMAIL app has (where you select the account) and use it to toggle the different "modes" so to speak.
Another approach would be to have it all in one screen, just that you switch the active layout (or perhaps Fragment) via the filter I mentioned above.
Check out the GMAIL app, and you'll see what I mean in terms of the filter. :-)
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.)
I am working on an Android app that has multiple screens the user will need to navigate between and I am curious what the best practices are when switching between those screens. I am torn between creating a new Activity for each screen and simply changing the view (setContentView(R.layout.whatever)). The screens all share at least some variable values so I'm leaning toward changing views and using class level variables, but I'm worried a single activity could become very large and confusing with logic for multiple screens in a single file. I'd like to keep the code clean and separated, but I also don't want to be passing several variables around between views if that isn't needed.
Being new to Android development, I'm hoping some more experienced members of the community could share their thoughts and let me know how best to handle it.
Thanks!
Note:
I wasn't planning on using a viewflipper. My thought was to use a button click event and then call setContentView() to a new view for the page I wanted to bring up next.
Example: My application starts up using R.layout.main as it's view. User clicks the Help button and it calls a method that runs setContentView(R.layout.help); to display the help screen as opposed to switching to a help activity.
You should use an activity per screen as this will make the best use of the framework and allow the OS to selectively kill off screens if things get tight.
If you have a single activity and resources get tight the OS has two choices; kill everything or kill nothing, and if the user is not using your app then it's most likely it'll kill everything.
If you use an Activity per screen the OS can kill off some of the screens the user hasn't visited for a while, whilst still allowing others to remain active which allows the user to go back to them quickly.
As for sharing variables and values, you could use the SQLite database or SharedPreferences stores for passing them around if they are widely shared, or use the putExtra methods in Intent if they're only of use from one screen to the next.
If you have variables that you will reuse make a base class for them, that you will extend.
This can be a your custom activity that extends Activity.
As far I can tell you have to create separate activities for each views, only a few situation can be handled by viewflippers.
I noticed that when I swipe my finger from left to right across a home screen widget, in simulator on a AVD, Android switch to the left home screen.
I was wondering if its possible to prevent this behavior and allow home screen gadgets to listen and react to finger gestures (like swipe)? Its very critical for my widget UI design.
Sorry I am posting this reply as a separate answer because it wouldn't fit as a comment. :)
So interaction with widgets is very limited.
The thing is, widgets aren't "mini applications," they are... widgets. They live in the world of, and are dependent upon, the real application containing them.
There is a continual demand for widgets to support more and more complicated interactions, but every time we start down that path it ends up making the interaction with the containing application much more complicated as well, and seems likely to negatively impact overall usability.
For example, if widgets can process swipes, then the user is now very uncertain about how they can swipe between screens because they will get different behavior depending where they swipe. They could even get stuck in a state where it is nearly impossible to swipe between screens because of the widgets covering the touchable area.
So the way I would recommend thinking of widgets is as a window into the key information associated with your app, to jump into more details of that information by tapping on the widget and switching to the app, and possibly some additional buttons to perform key operations.
Also as of 2.0, with the new wallpaper themes, you can make the UI of the activity that the user visits from your widget sit on top of the same wallpaper as home. This makes the switch between it and home feel much more like an interaction inside of home rather than with another application.
Starting with API level 11 (Android 3.0.x) you can use "android.widget.RemoteViewsService.RemoteViewsFactory" and and assign a widget to use (from docs):
ListView: A view that shows items in a vertically scrolling list. For an example, see the Gmail app widget.
GridView: A view that shows items in two-dimensional scrolling grid. For an example, see the Bookmarks app widget.
StackView: A stacked card view (kind of like a rolodex), where the user can flick the front card up/down to see the previous/next card, respectively. Examples include the YouTube and Books app widgets.
See http://developer.android.com/guide/topics/appwidgets/index.html section Using App Widgets with Collections.
So yes - if you use one of the above layouts your widget will accept gestures.
One more is:
AdapterViewFlipper: An adapter-backed simple ViewAnimator that animates between two or more views. Only one child is shown at a time.
Doc: https://developer.android.com/reference/android/widget/AdapterViewFlipper
Example: https://github.com/sunphiz/adapterviewflipper-widget