This question relates to VS2012 and Blend 5.
What are the rules governing whether or not the visual state manager is available in Blend? I've always been able to access the visual state manager in blend when developing Windows Store Apps in C#/XAML. I'm trying to do the same in Javascript/HTML5 and the visual state manager isn't there.
I can actually open C# and Javascript apps in Blend side-by-side and see that the states tab in not available in JS.
The concept of Visual States is not available when building Store apps with HTML and JavaScript. The "states" pane is only available when building XAML apps (WPF, Silverlight or Windows Store XAML). In the same way the Styles, HTML property and CSS property panes are only available when working on Windows Store HTML apps.
You can use Blend to set the CSS classes for different states. You can set the current view orientation on the Device pane. Using the css media queries you can set different properties on a similar class that is used in html. You can do this the same way as you would changing other CSS properties.
I hope this screenshot explains it a little further. In this example I set a green color to the filled state and a red one to the snapped state. The media query causes one to be picked over the other.
update:
I decided to write a tutorial about the subject that goes into a bit more detail.
Related
Is there a way to fix a single dxp file to different screen sizes ,for example i want to use same dxp to access from iphone,ipad and Moniter so it has to set automatically.
If you are going to develop mobile analytics I strongly suggest you download the Spotfire App at the Google Play and Apple Stores. This will ensure your visualization is rendered properly and provides you with mobile touching features that you may find cumbersome attempting through a mobile web browser.
Before you start building your analytic, go to Edit > Document Properties > Visualization area size and select one of the iPad options, or set a custom size. You will see the window resize in the professional client, emulating what the mobile application would look like. Personally, I'd steer free of creating one for a phone. It's just unrealistic, so much so that Spotfire discontinued it's mobile analytics which was used for phones, because, in my opinion, it didn't have a ton of value. It's hard to gain a lot from a visualization so small.
I am new to Xamarin and not sure if chose Xamarin.Forms to create a application for ios and android platform has a problem or not.
The application has some features below:
The application will be able to running some code in background without launching application by user.
The application can be launched by a href link or a notification.
The application is able to launch a builtin Camera application, and receive picture data from Camera application.
Thanks,
Bo
The features you are mentioning can be done with both. Actually, anything you can do on Xamarin.iOS and Xamarin.Android can be done with Forms. Because Forms is only an abstraction layer for the UI which is installed by a NuGet package.
Now, having that said when to use Forms or when to use iOS/Android? It is mostly about UI. Are you going to do some advanced or platform specific stuff is is easier to implement that with the platform specific project.
If you UI will be the same in both platforms and mostly consists of some lists and input fields, then that is a very good candidate for a Forms project.
Notice how I said it is easier to do in the platform specific projects. Again here, you can do anything in Forms as well by the means of Custom Renderers, it is just a bit harder to do.
Ideally try it out yourself and see what suits you best.
In regard with your need to execute code in the background. This will be tricky and is very dependent on the platform that you're on. You will definitely have to write platform specific code for that for which you can use the DependencyService to abstract it to your shared code.
However like AlancLui mentioned executing code in the background isn't something that is easy to do on mobile. On iOS it is restricted to accessing location data or playing music, but still your app needs to be running (in the background). Android has something called Services for this, which makes it a bit easier.
I have been working on maximo anywhere apps recently and have a requirement to completely change the look and feel of the work execution app, the oslc layer which talks to maximo in the backend remains the same and all the functionalities are the same but there are some new buttons, notification messages and all sorts of UX aspects to be added to the app, I have just started looking at the architecture and code of the app but does anyone know how can I make changes to the front-end or is it even possible? I could find very few documents available online and all of them spoke of customizing features and functionalities but I coudlnot find any document for adding UX aspects.
It would be great someone could point out any documents or kick-off points which I can start looking into.
Thanks.
Thanks for asking, if you're just talking about adding new fields, layouts, screens to the UI, you can do that all through the app.xml, and there are lots of examples on our knowledge center, for example this one:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.2/com.ibm.si.mpl.doc_7.5.2/config_apps/t_add_rw_fields.html?lang=en
If you're talking about changing the "look" of the existing widgets, this can all be done through css, by overriding our out of the box css classes. Use Chrome inspector to figure out which css class is being used for each element type, and just override it through standard css approaches.
If you're talking about more advanced customization, for example adding your own new widget types to our screens, it is possible to programmatically instantiate/destroy your own widgets through javascript and add them to our standard application views. This code is usually hooked on the initialize and back event of our views. But you'll be responsible for writing the code to synchronize the data layer with your custom widget. We unfortunately don't have a published example of this customization usecase yet.
We always adding new widget capabilities to our Anywhere UI framework, so I'd love to hear feedback on the new widget types you're interested in.
The team I'm on created a cross-platform application that runs on iOS, Android, and Windows Mobile that was created using Xamarin's tools and MonoCross. We're looking at MvvmCross as a possible MonoCross replacement but don't want to write the application from scratch.
Does anyone have experience with or thoughts on migrating a Xamarin/MonoCross cross-platform application to Xamarin/MvvmCross? Is it possible for the two frameworks to coexist in the same app (the ideal solution would have us migrate the app one screen at a time).
Thanks in advance.
Following Stuart's advice below I confirmed that it is possible to integrate MvvmCross into an existing MonoCross application.
In the original code a selection on View 1 initiates a call to Controller 2 using MonoCross URI navigation. Controller 2 displays View 2, passing it the data from Model 2.
Following the example in this video I created an MvvmCross View and ViewModel. A selection on View 1 still navigates to Controller 2 but Controller 2 now displays the new MvvmCross View 2. View 2 is data bound to ViewModel 2 which takes over Controller 2's functions of getting the Model data.
I don't know of anyone who's done this recently, but I originally ported several of the MonoCross samples over when I first created MvvmCross. The overall idea of one page to one "ViewModel" stays the same, although the mvvm binding offers more continuous view-viewmodel interactions than the more discrete Controller-Action model.
At a practical level:
MvvmCross itself is very modular and can be used in "CrossLight" mode where it simply provides data-binding and plugins - see CrossLight in http://mvvmcross.wordpress.com/. You might be able to use this for migrating pages one-by-one
MonoCross isn't really very interface/IoC based - so you may find that your resulting MvvmCross migration would also not be interface based either
MonoCross apps tend to use file-linking and #defines rather than PCLs - so you may find it easier to not use PCLs in MvvmCross
I suspect the best option for this migration is to let your team experiment - they already have lots of knowledge about your app and about what they do and don't need and what benefits they do and don't get from a framework.
What is your approach for creating your own set of controls aka own Extensions Library? After a few years of Xpages development we have a huge set of controls that are general purpose for building UI, some web services etc. (Probably as most other developers.) When we start a new project now we have to copy the entire stuff from one database to new one which involves controls, jars, css, images, JAVA code ... and then you completely loose control to maintain some central version of this controls & codes, everything is scattered among several projects/databases and things get messy fast.
We have thought about creating our own extension library as described here
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Master_Table_of_Contents_for_XPages_Extensibility_APIs_Developer_Guide but there is not enough documentation for this topic and the entire development process is quite complicated (at least seems to me. I tried two times based on docs above going through eclipse plugin project -> feature project -> update site and still having some bugs around)
What is your experience and approach for creating and maintaining shared Xpages controls in your Domino environment? Is there some hidden feature we miss here that can help us?
Take a look at the XSP Starter Kit on OpenNTF and the XPages SDK to setup an eclipse environment for plugin development. You'll also want Eclipse IDE for RCP and RAP Developers. Install the starter kit and SDK into eclipse and you should be all set.
The starter kit is a sample plugin with all kinds of examples of phase listeners, components, etc. Once you want to deploy your plugin, create an update site from within eclipse and use the Update Site NSF available on your server install to place your update site. Once that's done, you can replicate that NSF to any other servers that may need the plugin.
For more information about the starter kit, take a look at this slide deck. There is also a github project for the starter kit. Documentation for the XPages SDK can be found here. And a video for setting up the SDK is available on youtube. Lastly, here's the documentation for setting up the update site NSF.
While we haven't gotten to that yet in XPages, our model for regular Notes design elements is to have a central template that contains the elements that are shared, with those specific design elements marked to inherit from that template. Sometimes, a database inherits design elements from two different central templates.
That way, those centrally controlled design elements remain the same in all databases.
I would recommend looking at some example's on github for how they have library/components setup. One of the more simpler examples that has just a single component built into a Library is Steve Pridemore's App Layout Extension...https://github.com/DominoDev, Another good one is Nathan Freeman's Starterkit: https://github.com/the-ntf/xspstarterkit. Hopefully these will help you get the file structure down on which files you need and how they work.