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. :-)
Related
It probably will be an opinion based answers rather than fixed ones, but I thoughts it wouldn't be bad to ask this question and get opinions from more experienced developers.
I am implementing in my app recycler view, that each item in the recycler view should have some actions, for example
delete, reminders, spinners, change icons and some others.
Currently I implemented the delete and change icon logic with both swipe action, and contextual action mode(on click the app bar changed to "new" app bar with delete button)
I thought to continue to implement all the other actions, like reminders and spinners in the item itself but I don't know if it's a good idea.
After some research I have several approaches in my mind:
throw all the actions right in the item view itself, which mean the user see right away all the possible actions.
use popup menu(three dots on the item, and open little menu with actions)
expand the contextual action mode that will include all actions
Maybe even completely different approach and put all the actions inside the item detail screen
What do you think is a better approach?
For what it's worth, the Material Design specs (scroll down to List Controls, I can't get a link to it HOW IRONIC) recommend a primary and (optional) secondary action, with possible left and right swipe gestures (which are usually understood to be "get rid of this item" in some way, like archive and delete)
Personally I think that's a good way to go (and you don't need to follow MD but it's a good base set of principles, especially if you're not a designer or UX person yourself) - it avoids clutter, and makes it clearer to users what their main options are.
You can implement tap behaviour on the list item to bring up a dialog (fullscreen or otherwise) where you have room to add lots of other options, labels to explain them, etc. You're not limited to the size of a list item, and you can easily add to it in future if you need to, instead of being committed to trying to fit everything into a list item.
Plus there's accessibility to think about - list items are small, you don't get much space (especially on smaller devices, where the user has large fonts enabled) so where are you gonna put all that stuff? Moving some to a contextual action mode works, but there's not much space there either, and the user has to realise they need to look up there. Will it work well for blind users relying on linear navigation?
Basically you can avoid a lot of these troubles by following established patterns, where other people have done the work to make it all "just work". My own personal experience has been trying to do things in a different way, and eventually coming back to the "recommended" way and wishing I'd done that to begin with!
I'm struggling to implement the expand feature of the card view described by the Material Design for Android.
In their design guidelines they show off different layouts for the Card component, but one example shows a card transition to fullscreen onClick.
This is the transition shown on their website:
I've tried out implementing a feature like this, but it would require much more work than what their guideline examples are suggesting... How does Material Design accomplish this? Is there a built-in feature for this, should I just manually translate and fit the card to fit the screen, or should I use an entirely new fragment or activity for the full-card-view?
Here are the Design guidelines, which contain that example, but nothing is said about the transition, neither on the documented Develop page, which is minimal really.
TL;DR
In the case of the gif image you've attached above, the RecyclerView and the detailed CardView should have their own separate Fragments which are operated in one single Activity.
Jump to the links at the end for the animation part.
Detail
Why so? Well, we had three choices:
Keep both Views in one Activity and overlap the detailed CardView on top of RecyclerView on click event. (This one is stupid, and not a good practice)
Create separate Activities for both Views (Recycler & fullscreen-Card)
The one I mentioned above.
RecyclerView and Detailed View shown as two separate Fragments
Now the reason for not choosing the 2nd option was because it is more performance intensive as compared to the 3rd one. We may not notice this in a small scale app but it certainly makes an impact when the app scales. Plus, creating fragments is more effective as we are sharing common views and variables in between the Views. So the best choice is number three. Note that this isn't a universal case and the usage will differ according to your requirement.
Using Fragments can be overwhelming at first but it keeps the code more organised when you get a hang of it. You should try to keep your app divided into few broadly divided activities and within those should be as many fragments as you want.
Here's a few links that helped me implement the exact same thing you're looking for.
MDC: Material Motion
Implementing Motion with MM
Building Transitions with MM
Hands-on experience in Codelab
All three of them helped me gain a better understanding on how the whole Material Motion framework works and how to implement it in my program.
I would like to create several fragments that represents visual "modules" into my app. Each fragment is a sort of view in to different features of the app.
It would be really nice if the user could essentially move the fragments around visually like more modern desktop like apps allow.
Essentially it boils down to allowing the user to modify an activity.xml's layout visually(drag around).
e.g., the layout is
ab
xy
but they can grab, say, a handle on b and drag it to the lower corner x to get
ax
by
etc. Possibly they could overlap if the user doesn't drag to replace(so a z-index would be required).
Is this possible to do with android, and if so, what will it take to accomplish? I guess it's just a matter of some layout logic and setting the controls?
I'm developing an Android Tablet application with Android 3.1 SDK.
I have to implement a form in an Android Tablet. Now I'm doing on one screen with TableLayout, TableRow, TextView, Spinner, buttons, etc.
At this moment I have more than 80 views and then I get a warning about it.
The form is divided into sections and I think I can divide it into tabs but I don't know if I will have the same problem (I'm very new on Android development and now I learning how tabs work).
What do you recommend me? I will have, probably, 160 view or more.
I recommend that you split this huge form into multiple screens / steps somehow, it seems much more useable and managable to me. You could use fragments to hold the steps, and use some paging mechanism to navigate between these fragments. By switching fragments and saving their state you can keep the number of Views on the screen relatively low.
Check out the ViewPager component for this to navigate between fragments by swiping. Or you may use the plain old button based navigation (next/previous step e.g.).
If you really need to display all the form elements on one screen and want to keep the number of instantiated Views, you may be able to do this by using the virtualizing ListView, though it seems quite awkward to me. ListView constructs the rows as needed during scrolling, and you need to tell its adapter that you have X type of rows where X is the number of form-parts.
Why don't you logically break this Enormous form and using something like a Next button show the form in multiple activities. This would keep the screen clean, won't bombard the user with too much of information and finally won't give the warning of excess views on 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.