Google (as of Feb, 2017) returns only 7 results when searching for "MvxNavigationPage", where only one of them is more or less related to this class and provides no any particular knowledge of it.
MvxNavigationPage<T> is not presented neither in any (basic) documentation of MvvmCross, nor in any examples (more or less gathered) about this framework.
So, can somebody give me a hint of how to use it in XAML?
MvvmCross fully supports Xamarin.Forms only since May 2017 (version 5.0).
Also MvvmCross is fully open source so nothing stops you from reading the source code and knowing exactly what any class in the framework does.
You can even search whole GitHub for all references to MvxNavigationPage if you need to.
Your question is very attacking. Please keep in mind that the people behind MvvmCross do it for free in their free time and are bringing great features and regularly updating the framework. They are also very active here one SO with most questions being answered at the same day when they are asked. There is only a few frameworks that are this active, so it deserves recognition rather than any offensive.
To answer your question. You use MvxNavigationPage in place of the Xamarin.Forms NavigationPage where required. It is derived from MvxEventSourceNavigationPage which in turn derives from Xamarin.Forms NavigationPage. The advantage of MvxNavigationPage is that it fully supports MvvmCross, like including the typed ViewModel and integrating into the MvvmCross lifecycle.
Related
I'm looking for some guideline what's the difference between #fluent-ui/react and #fluent-ui/react-northstar. This documentation (READMEs) are super imprecise. I'm don't understand which one to use for what.
I'm writing that react-component to be ran in webapp and the word plugin. Do you know which one to go for? They both look a bit different and feels that theming works a bit different.
You should use fluent-ui/react-northstar if you want to develop apps for Microsoft Teams, else you should use the normal fluent-ui.
If you look at a simple example of a dropdown, you will see that there is quite a lot of difference between the two. Northstar's dropdown combines the features of the dropdown with combobox.
northstar:
https://fluentsite.z22.web.core.windows.net/0.51.4/components/dropdown
normal:
https://developer.microsoft.com/en-us/fluentui#/controls/web/dropdown
https://developer.microsoft.com/en-us/fluentui#/controls/web/combobox
Another to take into consideration is that Northstar's scope is limited to Web / Desktop at present.
https://fluentsite.z22.web.core.windows.net/0.51.4/faq
I'm about to start a new Titanium project. So far, what I've written is what's now considered as "Classic Project" (I've been writing Titanium apps since before Alloy).
I was wondering whether or not it's worth while to switch to Alloy for my new project. I know that basically, Alloy compiles to "Classic" Titanium code before compiling down to the java project or objective-c project. I also know about a big advantage in that "pre-compilation" process, which is to mark in alloy code that are relevant only for Android or iPhone and not including the other in the compiled "Classic" code.
My main concerns are flexibility - as with "Classic" I feel like I have more control over the code and what's going on.
Second concern, I have controls (like open sourced sliding menu) that are not written for alloy - how will I be able to have them as part of my project?
I started asking myself rather to use Alloy or not after finding (introduced in TiConf 2014) TI UX (https://github.com/jaraen/Ti.UX.Templates) which is written for Alloy.
few other questions:
how can I have old UI code run inside Alloy?
Can I have controls written for Alloy run in a "Classic" project?
Can "Classic" project also map out code not belonging to iOS/Android?
is there a difference in performance between Alloy projects and Classic projects? what about other flexibility issues?
Thanks
Just in case someone sees this question and needs an answer:
I have also posted this question in the Appcelerator Q&A where I got some answers here: http://developer.appcelerator.com/question/177739/appcelerator-titanium---alloy-vs-classic
The answer I was given is partial, and more info could be found in a questions asked here: http://developer.appcelerator.com/question/177542/classic-vs-alloy
I felt that the switch to Titanium Alloy from classic was right for me. I felt that classic Titanium development wasn't structured enough nor provided me with enough guidance on a good way to structure my app. Alloy provides a MVC structure to your code, but classic didn't completely prevent you from rolling your own or using one of the community libraries with MVC capabilities. In this respect I guess I would say it is more flexible to use classic over Alloy, because you can choose how to accomplish your structure, rather than fitting into Titanium Alloy's structure. That being said, I've never felt limited by Alloy.
How you develop in Titanium is your preference. There is no right answer to using Alloy or using classic. If one works better for you, use it. I feel that the structured approach to Alloy's separation of display and business logic provides me a structure that makes sense to me when developing an app.
I have not found that Alloy is less flexible than classic. Since you can use classic code in your Alloy project, you can pretty much do everything in Alloy that you can in classic. I'm sure that are some edge cases, that I haven't run into, where one might be easier than another when coding a specific type of application. It may be that classic is less flexible because I don't think you can use Alloy in your classic app. I don't believe the compiler would know how to build that.
Whenever I assess if I'm going to use a particular technology, I make a series of experimental mini programs to make sure all the capabilities are present for my application's requirements. If I feel that it doesn't fit or it is too difficult to reach those requirements, I don't use that technology. For example, when I switched to Alloy, I made sure the Ti.Paint library would still work. If it didn't I would still be using classic.
Just like classic, there are controls for Alloy. There is a pretty slick Alloy-based sliding menu module out there already. I use the Ti.Paint library, which existed before Alloy and isn't an Alloy specific module.
http://gitt.io/ is a decent starting point for finding Alloy modules/widgets.
index.xml
<Alloy>
<Window id="win">
<View id="content" />
</Window>
</Alloy>
1) In your index.js file, you would have the following to use classic coding to manipulate an Alloy view.
index.js
var myview = Ti.UI.createView({
backgroundColor: 'green'
});
$.content.add(myview);
2) I don't think you can use Alloy code in your classic project. As you mentioned before, it needs to do translation on the code and a classic project would likely skip that step in the process.
3) Are you asking if you can include or remove parts of the code based on if it is Android or IOS specific? You could probably do this with include/require statements strategically placed between if (Ti.Platform.osname == "android") statements to require in or not the code you want. If the code is for Android, require this one, if it is for IOS, require in that one.
4) Never attempted to check the performance between classic and Alloy-based projects. I think, since I switched and never noticed an issue that bothers me or my customers, I never put much thought into it. It is entirely possible that Alloy auto-generates code that is in some cases slower. I've never noticed it.
I feel that the efficiency I gain in using Alloy far outweigh that as an immediate concern. Plus, if I felt that I didn't like the way a particular control was created through Alloy, I could use the classic code and define that control myself having all the control of a definition from a classic project.
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
A friend of mine and I are looking to start a project looking into accessible user interface (for blind users) design. There are a number of projects making existing GUI's accessible by tagging them with audio information but we're looking to work from the ground up and actually take input from a ML and create an accessible application.
I'm trying to figure out what ML to use and am torn between three at the moment. The three I'm considering are XAML,MXML, and XUL. Currently, I'm leaning towards XUL because it's open but I was wondering if anyone could think of any pros/cons that I might be missing? I know that XAML is the most popular but does it do things that XUL can't? How similar are they?
I should add that whatever ML we end up using we will be extending the syntax so that we can provide additional information to the audio system.
I have already addressed this question to some extent here.
The pros/cons of XUL are:
it's open
it's cross platform
it's well established with a large community
it still basically has to be run in a browser that supports XUL (firefox)
one of the comments from my question stated that XUL is a bad choice because firefos is buggy
The pros/cons of XAML are:
it'll work on Windows/Mac
it has a well established drag-drop IDE (VS 2010) to create GUIs
it has a massive support community
it's closed source
it's a closed platform, IE. it not an open standard (not covered under ECMA like .NET and C#)
there are legal issues regarding the use on non microsoft/mac plagforms (see my post)
it requires either a browser with a the silverlight plug-in or the .NET framework to use it on the desktop
it's developed/controlled by MS. This isn't an attempt to troll. Seriously, look it up on google. There are a lot of people who are suspicious of MS's intent behind creating XAML and it has garnered a lot of negativity behind the platform. It might be worth taking into consideration.
The pros/cons of MXML:
it's cross platform
it's closed source
it runs on a closed platform
it requires adobe flash (which, a lot of people claim is a dying platform now that Apple is rejecting to support/allow it).
it requires a browser with a plug-in
Note: I can't really say much about MXML because this is the first time I've heard about it. I just pointed out the obvious pros/cons for completeness. I'll have to research it and add an entry to in the question I linked.
XUL application can be run under XUL Runner because after Firefox 4, remote XUL application execution within Firefox browser is prohibited
Does anyone know of any good free libraries providing Windows Forms controls for displaying schedules/timetables in .NET? I'm really looking for something similar to what the guy who asked this question was seeking, with a couple of differences:
I don't need any help organizing the underlying data or generating the schedule (that's all set) -- I just want a clean way of displaying it.
I'm actually looking for a custom control in Windows Forms, not an ASP.NET control.
One thing I've considered doing is just using a TableLayoutPanel control, but ideally I'm looking for something that will be more straightforward code-wise (as in, something actually designed for displaying a timetable) and sharper-looking visually.
How about this control? It is very similar to the calendar in Outlook. It does come with source code, so if it's not quite what you need you could maybe use this as a base for your own implementation.
Download the source code for http://www.monocalendar.com
He built a control (CalWidget) that you can easily recompile in your own project that's pretty nice. I recompiled it in .net 4.0 with little problems.