On the Rikulo documentation I see at Attributes of Layout and Profile for sometime now that the layout are of the following types:
none
linear
stack
tiles
table
Is there any timeline for the table layout to come on stream?
Sorry, we don't have any plan to deliver both tiles and table layout yet. You are welcome to contribute one:)
Related
I'm trying to let the user change the layout of the Main Activity via settings. So for example someone can select the newest layout or the original older layout. What would be the best way to do this. Thanks.
All your layouts should have the same number of views, with the same IDs.
If you do so, then you can have a ConstraintLayout as the root layout, and create clones of the layout with the child items arranged in different ways. Then, based on the setting, you would apply the constrains from a specific layout to the master layout.
Check this for reference
Context context = this;
mConstraintSet2.clone(context, R.layout.state2); // get constraints from layout
setContentView(R.layout.state1);
mConstraintLayout = (ConstraintLayout) findViewById(R.id.activity_main);
mConstraintSet2.applyTo(mConstraintLayout)
I'm developing an Xamarin Android Mvx5-beta application. When running on a small-screen device, I want to show a drawer navigation using the Toolbar and the hamburger-icon. On larger devices, e.g. tablets, I want a different layout conaining three columns. No drawer navigation but a static panel with navigation options and two other panels for content.
I started with the examples XPlatformMenus and Fragments to get a drawer navigation layout combined with the use of activities (with fragments) in different layouts qualifiers, like:
Question:
Using this approach, Android automaticly looks for an activity with the same name (e.g. main_activity.axml) in the appropriate layout-qualifier folders. But on the larger screens I don't need a drawer layout and I do need an extra column. The Mvx-viewmodel does not yet know what layout to render, so it just calls:
ShowViewModel<HomeViewModel>();
ShowViewModel<MenuViewModel>();
These ViewModels, for example MenuViewModel, are registered for fragments that require a navigation_frame, as shown in here:
[MvxFragment(typeof(MainViewModel), Resource.Id.navigation_frame)]
[Register("mydemoapp.droid.views.fragments.MenuFragment")]
public class MenuFragment : MvxFragment<MenuViewModel>, NavigationView.IOnNavigationItemSelectedListener
{
<..>
}
So, rendering this same Activity in layout-sw600dp requires a navigation_frame. Which I don't want on these larger displays.
What would be the preferred design choise in this situation? I can think of two:
Show/hide elements in the Activity programmatically by querying the screen info
Don't make use of layout qualifiers, but design complete seperate Activities for larger screens and based on screen size let MVX Show ViewModel-A or ViewModel-B.
Any advice would be appreciated, many thanks in advance.
I think it depends how different your layout need to be between large screen and small screen form factors.
Few UI differences
In addition to using different layouts, you can define a bool property in your XML values resources that is different between standard and sw-600dp
values
<bool name="is_large_screen">false</bool>
values-sw600dp
<bool name="is_large_screen">true</bool>
You can then read this value in your Android views and prevent methods like ShowViewModel<MenuViewModel>(); firing when on large screens by altering the method calls from the view.
Many differences/Structural differences
If they share the same business logic but have very different UI requirements and you want to keep large screen code separate. Then I would suggest sharing the ViewModels but creating two separate Activites and layouts to handle the UI presentation. Using this method requires a bit more setup as you have to override some default MvvmCross behaviors as by default you can not register multiple Activities/Fragments to the same ViewModel. Overriding the MvxViewModelViewTypeFinder view lookup FindTypeOrNull you can intercept the lookup and filter types base on naming conventions. For example all large screen views end with "Tablet". Using the is_large_screen bool you can flag which views to register.
this is not a technical question, but one for advice regarding the best practices in designing an Android tablet UI.
I've got my concept of an Android Phone app pinned down.
The first activity (master view) launched contains a tab bar with three fragments from which the user can launch detail view activities of different sorts.
Both the master-view activity and the detail-view activities have actions in their action bars. Different detail views have different action items.
My question is: How should I organize and display the action items on a tablet, where an activity combines both views side by side?
The problem is the unified action bar for both the master-view fragment and whatever kind of detail fragment is shown. I do not think it is a good idea to start messing with the contents of the action bar whenever a different kind of detail view is opened.
The Android Design Guide does not tell you much on that front. There is a sample of a Contacts app in the "Multi-pane Layouts" section, but it does not actually deal with the problem. It evades it, by putting the single relevant action as an icon inside the detail view fragment.
Any advice with regards to best practices and references are appreciated.
I would suggest leaving your master details icons in the action bar, whilst putting your details view icons in another view/area within the details fragment.
My reasoning would be that icons in the action bar affect / are associated with the whole app / view on screen. Whilst your details icons only affect the details view and therefor should not be in the action menu when showing multiple fragments.
I guess you will have to see how the designs look..
I am not a fan of the action bar icons being changed from within the same activity (even if it contains multiple fragments), however when you load a new activity (like in your phone design) then I say yeah throw them in the action bar.
If I understand your question correctly, which I think is basically a question of how multiple Fragments (i.e. when on a multi-pane layout such as on a tablet) should contribute to the single ActionBar, it's quite straightforward and it is actually briefly discussed in the documentation here. Essentially, you can have the multiple Fragments all contributing their own menu items / action items to the single action bar, via some simple API calls.
Hi I am just a week old with Monotouch, the task that I have in hand is to display a table on an ipad with multiple rows and multiple columns i.e. a grid like structure with many cells and each cell containing some data which can later be edited too.
My application should look somewhat like the figure below, except that it has to be working on an ipad.
The only useful link I've found is this, but this article discusses how to do so using Objective C(now since I am using Monotouch & c# so I am not comfortable with Objective C so I cannot understand this solution).
So my question how to achieve the same (i.e. a table with many columns and rows - a grid) using Monotouch.
Please help! Thanks in Advance.
Ajit,
If you want to use the UITableView'to render your data, you should effectively make it so that each "row" can render the columns in the way that you need.
What you need to do is to create a UIView subclass that can render the elements in your columns. There are various ways of doing that, you can:
Create your own UIView that implements a draw method and draws on demand.
Create a UIView that is a composite and merely has some children views
Once you have the view, you can add this to your UITableViewCell
You can follow some of my recommendations for creating those UITableViewCells here:
http://tirania.org/monomac/archive/2011/Jan-18.html
But 2-D browsing using a 1-D design is not optimal. Chances are that all that you want is to render your various items in a grid, so you might as well just use the UIScrollView directly and add all of your child UIViews there.
The only difference is that UITableView is designed to recycle/reuse some expensive objects (each row) while a basic design that stashes everything on the view will not have any of those benefits.
A more advanced option would be for you to create/destroys the views that are shown/hidden as the user scrolls.
I have a UI design which should contain a text data and this can be dynamic so i need a scroll view after the TextView is over i need a list view, Now this list view onItemClick of a cell should expand and contract to show details, Any sample project or code from where i can achieve this UI design, Please help me with this one.
It is strongly not recommended to have Nested Views that scroll.
What you can do is have a TextView followed by the ListView. You can use expandable listView for your expansion requirement. All the examples are present in APIDemos shipped with Android SDK.
Try some of the stuff and get back for more help here.