I would like to present XP application with Metro style UI.
I think of three unique styles:
1) App launcher (aka Navigator from LN client) showing boxed "links", what is common image of Metro: http://en.wikipedia.org/wiki/File:Windows_8_Consumer_Preview_Start_Screen.png.
2) List (aka View) - scrollable bars representing documents in view: http://www.brianbondy.com/static/img/blogpost_135/screenshot-filepicker.jpg
http://www.purplesquirrels.com.au/?p=940
3) Form - sorry, images of metro theme are not very common for this kind of usecase.
Options:
Wait for Dojo framework to include Metro styled mobile components (no signs of this plan at Dojo site).
Wait for IBM to include Metro on Extlib mobile themes (probably not going to happen).
Make own theme definition and/or controls (lot of work...)
Forget it, it is just waste of time.
Did any of you think about making metro.theme for XPages?
If I where you I would try to create it yourself. Its not that difficult. Its actualy a bunch of boxes ;) which is perfectly possible with html/css ( and thus with xpages ). The only thing you need to take or of is what to do after a user clicked on a box. I dont see the problem in creating it yourself...
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 started using Tizen SDK to develop a native app. And I have to make a form into a form. Actually, it works, but I've some bugs with it. I mean, the footer bar is bugged, when I click on an item from the footer. The app crash immediatly...
Do you know how to resolve it ?
Thanks
I don't think it a good choice to make a Form into a Form. If you want reuse UI form, it's better to use Panel instead.
Here is description of Panel from dev guide.
Tizen::Ui::Controls::Panel class is a general rectangular container that you can use to group UI controls, or even other panels. Panels can be used to create a custom background for a defined area, or for organizing and aligning UI controls. However, by default, the look-and-feel of a panel does not differ from its surrounding Tizen::Ui::Controls::Form control.
I'd like to display a UIWebView within a CCLayer for a Cocos2d 2.x project. I found the CCUIViewWrapper, but didn't get it to work with 2.x.
I don't really care about handling rotation and animation. I just wan't to display content from a web page on layer and also have a sprite to be able to go back to the previous scene.
Please help!
// Johan
If you don't want to use new version 2.0 features (I'm not using them myself at this point), then you can mix UIViews with Cocos by simply adding other views to your root view controller. After all, Cocos is itself a single view on the controller (if that's how you have it set up), and just add another view.
You can then easily tell the view controller to show the other UIViews by using the NSNotificationCenter, which I recommend in general over trying to communicate with the view controller from the Cocos layer.
I am using the XPages Extension Library mobile controls to create a mobile web interface for an existing Notes app.
When displaying a document with a large number of fields I would like to use an accordion type UI so that parts of the page can be expanded or collapsed to show or hide the fields in each pane (similar to sections in a traditional Notes client app).
Having looked at the "Accordion Outline" in the Ext Lib demo app I started to build the page using the Outline control. Within each entry (node) of the Outline I, ideally, want to place a rounded list and then put my fields & controls inside that.
But it looks like the nodes in the Outline can't contain this type of content - unless I'm missing something?
Any suggestions as to which controls I can use this type of UI?
Thanks
You can any time use an xp:panel and assign it the dijit.accordeon (look up the exact name please) dojo type. Then you can put anything inside including repeat controls etc. I would guess it might make sense to build your own CC to hold the content for each accordeon panel
I am using the Extension Libraries Application Layout Control and need to have a banner graphic placed in the .lotusBanner div on the right. How can this be done as it seems that the Application Layout Control can't be modified.
You could use the utilityLinksFacet on the extended control that Steve Pridemore did.
http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&documentId=CED2E61A75526CD086257997006DA95B
or you could use onload javascript to add it.
I was able to place a graphic in the upper right of the Application Layout Control in the Banner area by doing the following:
In the control under the Banner > Utility links I added a Basic node. For the node I specified the href and image. This worked and placed the image n the correct spot.
Artifacts of this were the location of the Banner Application links. To remedy this I used some CSS for the .lotusBanner ul.lotusLinks {margin-top: 45px;position:absolute;}
The margin-top was to push the links down so I could enlarge the logo that is used by the Application Layout Control.
The applicationLayout control in ExtLib is, as you have found out, locked down to only allow certain aspects of the configuration to be changed by the developer. You can add links to different sections of the applicationLayout but nothing beyond that.
One possible alternative is to NOT use the applictionLayout control itself but create your own approximation of it in a custom control, You would need to add all the necessary panels/divs with the special oneUI2 classes in all the correct places and then add editable areas and callbacks within these panels for the parts that you would want to customize throughout the application. All of the other sections in the applicationLayout control, like the bannerUtilityLinks are created using the ListofLinks control that is also found in the Extension Library.