I am starting developing Windows 8 Metro apps. It seems that there are 3 different approaches available for creating one:
C#/XAML
C++/XAML
JS/HTML5
Do these approaches have the same functionalities and power?
I mean that if one develops an app in one these three, is it possible to recreate it in any of the other two?
Well, a simple application can be built on any of these platforms. Their won't be much difference. C++ code is generally more faster, if speed is a matter for you got that way!
There are some tools like DatePicker and all which are available only in JS/HTML but NOT on XAML(Alternatives are available though).
So yes! there is a bit difference in the API's available for each of them.
Their is a question already on the site explaining difference between C# and C++.
I personally prefer C#/XAML because it is easy and comfortable.
You may refer to it here:
What are the pros and cons of writing C#/XAML vs. C++/XAML WinRT applications in Windows8?
Happy coding :)
You can write the basic engine with the C# language and the mainview with HTML5.
If you know web development technologies, you can develop a Windows Store app using HTML5, Cascading Style Sheets, Level 3 (CSS3), and JavaScript.
If you have developed .NET, Windows Presentation Foundation, or Microsoft Silverlight applications, you can develop a Windows Store app using XAML, with code-behind in C++, C#, or Visual Basic.
If you know DirectX, you can develop a DirectX Windows Store app using native C++ and HLSL to take full advantage of graphics hardware.
Related
We are a Win8 & WP8 (new) development shop that must develop a one-of internal use only LOB app that runs on Win7 (preferably out of browser). Since most of our client-side app knowledge is with XAML/MVVM, I'm thinking our best option for that app is to do it in SL5.
So, how much of our XAML/MVVM knowledge can we leverage for SL5 development? Can we actually share some amount of code between SL5 & Win8 if we design with MVVM clearly in mind? What are the pitfalls?
Silverlight? No need.
The answer is simple and straightforward. Move as much logic and types into one or more portable class library projects. These can be used on WP8, Windows Store apps, and desktop apps, so there will be minimal effort using them in these types of applications.
For windows 7, go with WPF for your UI. You may find that the API is slightly awkward to deal with, as it lacks the asynchronous patterns that you have to use for WP8/WS applications, however developing the UI via xaml is exactly the same. I don't think you'll find much of a difference at all between the two.
What are the differences between these two programming choices
I know that the following features are supported by only HTML/Javascript
1. Flyout control
2. Header Menu
3. Rating Control
Do they have any other difference in terms of controls, integrations, connections, deployment?
html/javascript
html5 and js are open web standards. That's why they work (and act) in nearly every browser the same way. That is the reason why you can develop html5 applications for Mac OS and port it without many extra coding to Windows.
Microsoft however wants to have as many Apps inside the market as possible, that's why they made confession to the web developer and implemented a native looking support to html and Javascript. But there are a lot of Javascript functions, that are only supported by IE10 (in fact, nearly every function you can find in the WinJS-File). If you want to port Win 8 Application to any other Operation System, you have to review your code.
A good example for this is the click-eventhandler in WinJS, which has a event.pointerId to identify multitouch. This is a good easy way but not standard.
XAML/C# or VB
XAML is .NET and so it is fixed to this Framework. You cannot easily port a XAML Application to a mac os. Therefor XAML and C# is very good implemented into Visual Studio (Intellisense,Blend and Design-Views) and has some nice features like LINQ and DataBinding. Also the MVVM pattern allows to split up designers and programmers. In my opinion the documentation on msdn is better for XAML and C# than for Html5 and JS. For games there is also a DirectX implementation which is a better choice because of higher performance.
What to choose?
The decision which way to program is really hard. The following Questions should help:
Which programming language are you more familiar with?
IF OOP -> C# and XAML
IF web and prototype based languages -> HTML and JS
Which type of application will you code?
If it's fixed to Win 8 -> XAML and C#
If it should run on more than one platform -> HTML and JS
Do you like Visual Studio?
If yes -> use XAML and C#
If no -> use HTML and JS, you can than
first develop the app with your common IDE and later import it into
visual studio to create the application.
What is the difference between Metro apps written in web-development technologies and ones written in XAML/C#, etc.? Does Microsoft Metro API provide hooks for Javascript, where it's all native for C#? Should they work hand in hand, or is it the developers choice which route to go?
Is there certain functionality that cannot be implemented if using JS (other than OpenGL hardware capabilities)?
The reason I'm wondering is to know which technologies are necessary for building extensive Metro apps, so that when I get to a certain point I'm not stopped by a brick wall, letting me know that I used the wrong technology.
Microsoft has put in a lot of work to make Javascript a first-order language on par with C# for WinRT development. Both Javascript and C# have direct access to the WinRT API via language projections. That is, there is a unique binding specific to the language to the underlying API. So neither language is any more "native" than the other.
You should be able to write an equivalent Metro app in either language. At a high-level, it really does come down to which language/environment you are more comfortable with.
However, there are a couple of differences that should factor into the decision. First, WinRT components can only be written in C# or C++. Javascript can only consume thse components. If there is an intent to create reusable/shareable components, should keep this in mind.
Second, although the Windows Phone 8 SDK has not been released yet, there are indications that Windows Phone 8 apps can only be written in C#. If there is an intent to create similar apps for both the tablet as well as the phone, this is probably a serious consideration.
There haven't been a lot of performance-based studies comparing the two in a Metro app, so it's hard to say whether that will become a factor or not.
Then, there is also 3rd-party support to consider. C#/XAML is well established and has a lot of 3rd-party support. But similarly, Javascript has a lot of 3rd-party libraries available (e.g. jQuery) that for the most part can be brought in and used in a Metro app as well. I would give a slight edge to C#/XAML, but it seems like support is good for both.
We can’t just leave our customers that are not able to upgrade to windows 8 for a long time in the larch. However there is demand for a “tablet”/”touch” version of our app.
So how can we support both touch with Metro on Windows 8 and our current customers from a single code base?
When WPF come out, after a lot of “Pushing” Microsoft saw since and make it work on Windows XP – has anything like this been talked about for WinRT.
(I am not expecting any solution to work on XP, as XP support is being wound down.)
See Also: Can the ARM version of Windows 8 only run Metro (WinRt) style apps?
The best answer is that you do not want the same application to run on Windows 7 and Windows 8 Metro style. The UI that works best for mouse and keyboards (windows 7) will not work well for a touch-first presentation and visa versa. It is important to re-imagine the UI for the two different worlds.
That said, you have 2 options if you want to share a lot of the code:
1) Write it largely in JavaScript/HTML5. This will let you re-use many of the assets (especially the business logic parts).
2) Write it in (desktop) Silverlight. The Silverlight XAML is closest to Windows XAML. WPF is further away and will require more re-work later.
In either case, you should look at and follow the principles used when writing cross-platform code. Understand the platform dependencies and isolate them behind indirection boundaries. You want to localize all of the code that will have to change. For instance, you don't want calls to the .Net System.IO.File APIs which you know will have to change to Windows.System.Storage calls being scattered throughout your code. Instead, you want it localized in one function that can be modified later.
The only way I can think of is to implement your application in HTML5/CSS3/JS, and avoid using WinRT APIs inasmuch as possible - this may be feasible depending on what, exactly, your app needs to do (e.g. portable 2D graphics is easy with HTML5 canvas).
Then, for Win8, you'll package this as Metro web app. For Win7 and below, you write a simple app that embeds your browser of choice (not IE9, since it doesn't work on XP - so Firefox or Chrome) with all chrome hidden, and loads your HTML5 app inside that embedded browser.
As others have noted, you would not want to have exactly the same application working in Win8 Metro and Win7 / Vista Desktop. If you structure your application properly, using a suitabel design pattern, it is possible to share quite a bit of code between the various version that you would require. For the Win8 version, you will be using WinRT, for Win7 / Vista you have a choice of Silverlight or WPF.
I have published a couple of articles that demonsrate how this can be done, they include quite a bit of code as well:
XAMLFinance – A Cross-platform WPF, Silverlight & WP7 Application - while this article does not cover Win8, it does share code from WPF to Windows Phone 7, which is a very similar problem.
TweetSearch – A Cross platform Metro UI WinRT and Silverlight Application - this article shows how to use the same techniques to share code between WinRT and Silverlight
It is unlikely that we'll see Microsoft push the Metro-style
application framework back to past releases due to the level of
re-architecting that went into Windows 8.
I agree with Zac on this point. It appears Microsoft is definitely pushing both the technology and usability forward with the introduction of Windows 8 (and Windows Runtime).
The Metro UI is a different UI paradigm. If your using the current
Win32 controls (which includes WPF controls), your application will
look really dated in Metro. The only way to fix that is to
re-implement the UI (your View classes in an MVVM design) using Metro
controls. However, C# and majority of the .NET APIs are first class
citizens in this new environment. The rest of your application should
be fine.
As you already have what I assume a rather large application your best solution would be separate your view from your model-viewmodel. Then you can continue to develop both Windows 8 Metro full-screen touch-friendly awesome interfaces and the "classic" window interface (what we have done for the last x number of years). With good separation, design, and an excellent source control solution (i.e. Perforce) you will able to share a lot of the code base.
In addition to the answers given to your recent question on Windows Runtime Bill Wagner (one of the many C# bloggers that I follow) has posted summary on WinRT and managed languages conference sessions; it is an good read and recommended if you have a few minutes. One of the things that his summary clarified (in the FAQ at the end) was that the future of .NET as the branding for the framework we use is going to be replaced with Windows Runtime.
Another piece from Bill's blog post:
Some of the .NET APIs are changing for WinRT. I don’t have an
exhaustive list, and I’m not sure there is one yet. Other APIs are not
exposed via WinRT. (They are still available as .net APIs, just not as
Metro / WinRT APIs.)
It is unlikely that we'll see Microsoft push the Metro-style application framework back to past releases due to the level of re-architecting that went into Windows 8.
Like Pavel said, if you kept your application from using as much of the WinRT libraries as possible, it is possible but then again, you're now building a regular web app.
I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.