I do have a custom layout with some controls written in an XML layout file.
a class is attached to this layout like
<com.project.layout ...>
<Checkbox...1
<TextView...2
<Button ...3
<ImageView..4 ...
../>
depending on the user interaction i would like to display only 3 of the defined controls like 1,2,3. With a click from the user i'd like to have 1,2,4
To do so, i developed some state classes that handle the removeView and addView.
I have some issues about this as:
1/ When can i be sure everything is created and i can interact with the UI (onLayout() & onMeasure() seem to happen everytime a control is processed)
2/ it seems that since i defined the layout with the 4 controls, even thought i write removeView, the space used by the removed control is not used by the other controls... is there a way i can ask the layout to reorder it display?
I found out , it turns out it was easy actually, there is a method i have to override called onFinishInflate().
Related
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.
i am new to GWT and GWTP and the question sounds stupid.. Can I make an abstract PresenterWidget or similiar?
Like in normal Java extending the "class" and reuse / extend the logic. But not only the class, the whole thing of View and Presenter. I try to explain my initial situation and maybe you have another idea.
The image hopefully helps to explain it. The "Main-Tab" and every other tab consists of a collection of views which have the same base structure and the same logic.
the base structure consists of
border around EVERYTHING
an image (the wwitch)
a title
a textarea
a PresenterWidget which is added to a contentSlot of the parent (the menu left)
and below the base are view specific components like buttons, text or any other widget. So a main part of the view with logic is repeading. If the switch is "toggled" the view is hidden (the textarea and any childs / view specific components) like the lowest view in the picture. Furthermore the PresenterWidget left changes the color.
The logic is working, but now I am searching a proper way to solve this without repeading code and the possibility to add child elements which are hidden as well by toggling the switch. Can I add to a PresenterWidget child widgets and define where there should be added? like: Even if this is possible, it feels a bit inconvenient.
Thanks in advance.
I just want to post the solution:
I have now a simple Composite (KPICommonView) for the switch, title and the description. It got another FlowPanel below the description, where the specific components will be added later. For this the Composite implements "HasWidgets" and overrides the "add(Widget w)"-method which is called by UiBinder if the Widget is added and has child elements.
<own:KPICommonView title="First Header" description="I am a happy description :)" anchorToken="{nameAnchors.getFirst}">
<g:Label>child component</g:Label>
</own:KPICommonView>
I am not sure if I do a PresenterWidget for every segment and every PresenterWidget has one of the KPICommonView added, or if I do one normal Presenter which adds more than one of the CommonViews.
The CommonView furhter creates the PresenterWidget for the menu item on the side. It gets the attributes from the constructor (anchorToken, title) and adds it to the slot (which happens ugly, because the View has hard coded the parent saved to call "addInSlot()". The repeading code for the switch is handled by the KPICommonView.
Okay... this is a little difficult to explain but I will try my best.
In Custom Control while adding properties in Property Definition we can set "Allow multiple instances" which allows us to add multiple instances of that property when the control is embedded in XPage.
Similarly, I need to know whether it is possible to add (and remove) Editable Areas in a custom control when it is embedded in XPage? What I plan is that I would have a repeat control inside my custom control and I would be able to put the contents in each editable area in every loop of that repeat.
Is this the right way to go about or am I looking at this problem incorrectly? Any solution not involving editable areas is also welcome :)
Update 4 Apr 2013:
A use case context I am looking for is a simple carousel where contents of each screen in carousel can have different contents. These contents would be put into each (dynamically added) editable area. The contents can be very different from each other with one screen containing only text, other only image and another both image and text.
Look at the table walker example in the 26 original exercises. It does mostly what you are looking for (conceptually). You won't need multiple editable areas. Whatever is inside the repeat gets repeated.
What you want to do is to give the control a custom property "boolean editMode" so you can render that one line to be edited - if that's the UI pattern you want to follow.
You also could consider a dojo table with Ajax which allows for a familiar spreadsheet UI
In my Android project I've already created a custom dialog: A class named SelectColorDialog, extending Dialog, that allows the user to view a large matrix of color cells in order to select a particular color. The dialog returns the selected color value (as Integer) to the dialog initiator – typically an Activity – via a callback function.
I've a similar custom dialog, SelectTypefaceDialog, to allow easy font selection. A list of available typefaces are shown, as ListView rows, each identified by name and with an associated short sample text rendered in that typeface. The available typefaces include usual droid fonts, such as NORMAL, MONOSPACE, etc. as well as any externally sourced TTF font files that the user cares to load into a particular subdirectory on the SDCard.
These custom dialogs were not initially designed to be used directly in conjunction with SharedPreferences, preferences definition XML files or with any PreferenceActivity. Instead of, each dialog can be popped up from any activity, via the user pressing a button or via a menu item. The activity classes that create these dialogs also have internal callback classes, selection event listeners, to detect when the user selects a color or font.
These two dialogs do not have OK and Cancel buttons. Instead, the user just clicks on an item - a view of some kind - in the dialog to select the corresponding color or typeface value (implicit OK) or else presses the device’s back button to dismiss the dialog with no action taken (implicit Cancel).
I would now like to go further and incorporate these two custom dialogs into the shared preferences framework via a preferences.XML and an associated PreferenceActivity.
I would prefer to base two DialogPreference subclasses directly on these existing dialogs if possible, but I cannot see how to do so. I suspect that I cannot, and that I'll need to start all over again, and copy or adapt all the java code that is presently in the custom dialog classes – for color or font display and selection – directly into the custom DialogPreference classes instead, perhaps by overriding onCreateDialogView() and/or other methods?
This question may be a bit old, but I hope to help those, looking at the same problem in future: just extend Preference instead of DialogPreference. DialogPreference is designed badly and expected "official" way to use custom Dialog - overriding protected showDialog method does not work, because this single method contains half of class logic.
I have a simple ContactEditPanel which contains a form and a number of textfields. Up until now I included an AjaxSubmitLink in this panel which, if the form content is valid, saves/updates the Contact instance contained in the Panel model. So far so simple. However now I'd like to remove the link in order that I may, depending on the context in which I use the ContactEditPanel, place the submit link at different levels of my overall component hierarchy. For instance in one context I'd like to use to flip between ContactEditPanel and ContactViewPanel with a bar of actions above the current view (edit | save , cancel). Another context would be to use ContactEditPanel in a standalone way (maybe part of a multi-step process) with just a save link below.
I was contemplating refactoring my ContactEditPanel to extends FormComponentPanel rather than Panel as described here but I'm not sure whether this is the right approach and I'm having trouble wrapping my head around this.
Any help would be most appreciated!
Many Thanks,
A
Your using the panel like a FormComponent so extend FormComponentPanel, it will allow you to keep all the validation you write contained to the component and also allow you to reuse it as you wish.
Just think of it as you've created a new FormComponent, like a TextField or DropDownChoice.