Develop Reference

Xamarin Android Screen with Stacked Tables of Data

I need to fit several tables of data on a screen. For small screens, I though the best way to handle this, as a simple solution, was to have them all stacked up on top of one another. And then just to scroll down an view each table as you go down.
The tables of data need to be created with some kind of repeating, data-bound control. It seems like the ListView is the one to use with Android (but I'm open to suggestions).
The thing I am bumping up against is that you can't seem to have ListViews inside a ScrollView (note: I want to support KitKat). The rationale being that you can't have a scrollable control inside a scrollable control.
Is there any simple way of doing this? At this stage, I was hoping there'd be a simpler solution than going for the ViewPager swipe right option.
Thanks

Using the ExpandableListView solved my ux dilemma here. Or rather, the MvxExpandableListView.

Android What's the best way to display several layers of varying types of nested data?

I've read several SO posts and gone through some tutorials and now I'm trying to re-create this: http://i.imgur.com/on2xi72.png However, I'm not sure if what I propose to do is the best way to re-create this layout.
Here's what I'm proposing to do:
I'm working with this well nested JSONArray and JSONObject and vice versa API response (example data: https://jsonblob.com/5525b47ae4b0599c1fbd338b). I was thinking that I would create 3 different types of fragments to show the bullet point data. For example, one fragment would display "High Knees .. 25 yards" Another one could be a hyperlink type like in the case of "Shoulder Shrugs", and the final one would display the chart like the one at the bottom of the image. Since the API response separates data by a title like "Warmup" , "Upper Body Circuit", I was going to create a "block" activity that could contain the title and its related fragments/bullet point data. All of these "block" activities separated by the horizontal black lines would then be placed in another "full view" activity that would display stacked top to bottom. This "full view" activity would then be stored in another array because there are different dates to swipe through (if you notice at the top, it says Tuesday). Also, for each of these layers, there could be any type of variation and amount of data depending on the API call made. I hope this makes some sort of sense, haha.
Thank you for reading my post.

You can have only one activity per screen view in an android app, but can have several fragments per activity. Visual separation of your screen sections does not mean you need to have different fragments per sections in your activity. The reason you would want to use separate fragments is to be able to switch out the content of each fragment independently based on some application logic.
However, - if I understand it correctly - in your case, there is no reason why you would want to use multiple fragments per activity, as all your data is going to be changed as a whole based on the user/calendar day. Therefore, you can just use a single activity, or even better, use one fragment in your activity.
For your reference, this CodePath guide on Fragments may help you better understand fragments and how to use them. If you would like to read up on Activities more as well, you can do so on the android developer guides.

Should each Fragment have its own Activity?

Android Studio 0.8.10
I have developed an App that has 3 fragments. I have just used 1 Activity and when I want to display a different fragment I just replace the existing fragment with the one I want to display. However, as I have 3 fragments now, and maybe more in the future, I think this will get harder to manage.
I am just wondering what is the design pattern when programming with multiple fragments, should each fragment have its own activity?
I will be scaling this to Tablets in the future, so I am not sure what impact this will have if I stick with the multiple fragments and single activity.
Many thanks for any suggestions,

should each fragment have its own activity?
Yes, but you can also use nested fragments.
I think this will get harder to manage.
you are right but
i think you must match your app with some other widget for example if you have multiple fragments that want to show one after the other use viewpager or you can use horizontalscrollview. you can create tabs and sync them by viewpager and so on.

Yeah, this can be really hard to figure out. I think a pretty good analogy, from the web application world, might be a servlet and a frame.
An Activity is like a servlet. It is one page in your app's workflow.
A Fragment, on the other hand, is like a block of content. It might appear in several different contexts and it might be served by several different servlets.
In MVC terms, the activity is largely part of the controller. A fragment, on the other hand, is more like a view include.
Much of the time, those two concepts align. A page in the workflow frequently contains exactly a single block of content. As you have, wisely, noticed, though, when you get more screen real estate (on a tablet), it is entirely possible that a single activity will display more than one fragment.
A single activity, on a tablet, might show, for instance, both a list of selectable items, and the details for the currently selected item in that list. When you have less space on the screen, though, those two things would be displayed as separate workflow items. Clicking on an item in the list invokes an entirely new activity.
The content is constant. The workflow changes.
Most modern applications will use a Fragment to display Activity content. It makes the application more flexible and easier to adapt to wildly different screens.

Android layout design for many menu options

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. :-)

Three listviews in one screen

I have an app on iPhone with cascading design like on the picture, and I'd like to port it to Android. Is there a simple and recommended way to do this?
The section menu on the left (Section A, B,C,D) is the first that the user needs to select, then the user needs to pick a category in the middle (all, popular, pc, xbox,...), then he is presented with a list of articles for chosen category.
I could imagine doing it with three ListViews, but then the app could also listen to a swipe gesture to make the rightmost ListView "full screen", and hide the first two listviews. I could implement a swipe listener for the whole activity and set first two listviews' visibility to hidden, right?
Are my assumptions correct and would this be the right way to do this?

It could definetly work the way you explain it - if the design is good is another discussion. Personally I'm not a fan of throwing in endless amounts of data in one screen, when the space is as limited as it is on most mobile phones (I would probably do it with 3 different screens with a ListView on each)
Implementing the mentioned swipe gesture is doable and you could certainly just hide the two other ListViews with the function setVisibility( View.GONE ).
Hope it helps.

You might want to use the new fragments API, it's specifically built for this kind of thing (and it's compatible all the way down to Android 1.6). Also, as KasperMoerch says, putting all that info on a small screen can get ugly. Using fragments will make it easier for you to gradually increase the amount of information displayed as the screen size increases.
I'm not sure you can just listen for a swipe gesture over an entire activity like that. I think you have to wrap the fragments in a custom view (for example an extended LinearLayout) and do the swipe listening there. However, achieving a finger-tracking animation (i.e. where the rightmost pane follows the finger precisely as it swipes across) is a pretty daunting task (I wouldn't really know where to begin, probably in the custom view though). The best way (I think) to do it is to make a compromise and just start an animation (right-to-left slide) when you detect a swipe. However, the simplest solution is to not animate at all.
You can also take into consideration dropping the swipe gesture altogether and just providing an "expand" button.