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.
Related
Not sure if this is the correct way to represent the flow between the "Home" page button, "Culture" page button and the "Song" page button (as all these buttons are present in all of the pages, where the user is able to click any of these buttons and perform certain activities)
This seems very messy as the arrows are pointing in all direction, which is why I am stuck on how to represent this.
UI of the application:
Why did you choose an activity diagram for this purpose? A state machine diagram is more appropriate. Clicking on a menu option transfers the application to a different state. You can use a superstate to model the transitions that can be made in any application state.
I would use an activity diagram to visualize the paths through a complex use case, not all UI actions.
See my paper 'Which UML models should we make', pages 12 and 13.
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.
So I have a part of my game where the character is selecting an area of the map. And it opening up a panel. I have made it so that happens but an=m now stuck on the other part of it. I want only certain area of the map to be intractable, so that I can bar the player from selecting areas of the map that they aren't ready for. I have no idea how to make game objects in the game uninteractable. I have looked on Stack overflow, Youtube an d the Unity API to no success. Can someone help me with that.
How to make things un-interactable will vary depending on your situation. I'll be presuming that you're map is broken up into a grid of sorts.
The basic setup would involve a bool, probably called 'CanAccessZone'.
Then you'll need a class, to store any access info and popup logic, by popup logic I mean make the element either non-interactable or show a popup, with the shown popup being dependant on 'CanAccessZone'. This class can then be set up by your Map class when the level is loaded, or you could let the popup class grab the necessary values from the Map class.
If you're using Unity's UI buttons for the map pieces, then you could set interactable to false, until you want to let the player access the zone. If you want to display a popup informing the player that they can't access the zone, then your button will be interactable, but the click will delegate to your popup logic method.
It's a similiar principle if you're using gameobjects as buttons. You'd be using any of the OnMouse events to handle click events. https://docs.unity3d.com/ScriptReference/MonoBehaviour.html
Hopefully this'll lead you in the right direction.
I am creating a new footer sublayout in sitecore for use in multiple sites (we run a multi site environment). Currently a sublayout called StandardLayout is used, but I would like to change this across several of our sites to a new layout GlobalFooter.
The problem is that child items of the Home Page have overridden layout components, so what I would like to know is if there is an easy way to change the layout without losing all of the overridden components (as I expect that I may need to reset the layout in order for the flow down to occur)?
I am hoping to be able to just change the top level element (Home) and then have this flow down to the child elements, otherwise this task will become very long and tedious if I need to go through each item and change the presentation to use the new footer.
The icon circled in red in the image above indicates that the presentation has been overridden for that particular sitecore item.
To answer your question, directly, there is no way to apply an update of the presentation details of a template to templates that inherit from it that have had their presentation details changed without losing the changes.
The solution described in the blog post you linked to is the best solution for updating inherited presentation details in this manner. IMHO, I believe that this functionality should have been built into Sitecore long ago as a separate button on the ribbon, and you may choose to add one if you are so inclined. If you do not have the time to do so however, creating an admin page that you later delete from the site after using is a perfectly viable solution as well.
This post appears to detail a way that I can achieve my goal, basically I would create a admin page that does not publish and put the code in the blog into it to update the layout via a button trigger.
https://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/09/Programmatically-Update-Layout-Details-with-the-Sitecore-ASPNET-CMS.aspx
Is there a way to get a callback when a View appears/disappears on the screen?
I need this for analytics purposes - eg. I need to check how many times people saw a view versus how many times they clicked on it.
I can tell whether a view is on screen at a certain point in time but I'm wondering whether there is a callback for that.
Also note that I'm not interested when a View's state becomes VISIBLE and not even when a view gets rendered (because eg. in a ViewPager the Views of the second page are rendered before they actually appear on screen).
We did several workarounds for certain scenarios but I'd like to have something which is more generic. We need it in ListViews, GridViews, ScrollViews and ViewPagers and each one of them presents different challenges.
Does ViewTreeObserver.OnGlobalLayoutListener help? I have never used it myself though.
See: http://developer.android.com/reference/android/view/ViewTreeObserver.OnGlobalLayoutListener.html