... i think this may become a potentially heated debate but really i'm just hoping to hear from somebody with Crystal Ball (i.e. not interested in what's Right, what's Wrong, what's Cool and what's not) - I just want to know "what's going to happen"
While I have no doubt we'll all be coding under "Desktop" environment for years to come, that "Desktop" isn't going away. However, is this a hint that .NET is legacy? That WinRT is the shiny new API that us lowly developer should all adopt? Is M$ giving us a hint (shivers up my spline this reminds me of Silverlight M$ is very generous when it comes to wasting our time)
what I am thinking is, worst come to worst, our investment in server side will remain "Desktop" - we only consider any "Metro" development for GUI side. GUI (metro/WinRT) and server (Desktop/.NET) communicates via socket - but not sure if wiring down byte array will work or not. I am pretty sure an Int32 (what about IList/IDictionary or even DataTable) gets wired back/forth correctly serializing/de-serializing using .NET DataContractSerializer, just not sure what further complication.
Also wonder how easy/difficult will it be to port .NET code to WinRT (For example I suspect while C# be same on both platform, but platform API such as File.AppendAllLines will probably be different). Remember porting your .NET dll's to now dead Silverlight? (That SL enforces generics? sh*t that's manual changes everywhere what were they thinking - I read somewhere WinRT too they will take away all the non-generic collections)
I don't think WinRT/Metro was ever envisioned by Microsoft as a total replacement API for full .NET. After all, WinRT is a subset of .NET. I think the motivation and drive behind WinRT is the iPad. Microsoft saw (as did we all) a huge shift in consumer computing to include lightweight tablet computing (as opposed to "heavy" tablets, which have been around for a very long time, e.g. Windows XP Tablet Edition.)
Microsoft knew that if it didn't want to lose market share to Apple (considering the whole of the computing ecosystem), it needed to compete on the same grounds with the same range of offerings, rather than sticking to "desktop/laptop only". I think that's the real motivation behind WinRT. Smaller, lighter, runs on ARM.
Microsoft also wanted to make sure that unlike the iPad, that their offering had the rather novel convenience of having your portable apps run on both the "WinPad" and the desktop... something that can't be done with iOS. Since they couldn't support a full blown traditional application model on the tablet (given the storage, CPU, and battery life differences), they needed to create something new that would work on both platforms... hence, WinRT was born. And sure, Microsoft is pushing WinRT right now, and with good reason: they desperately want the WinPad to succeed. It has nothing to do with abandoning the desktop experience, or abandoning the full .NET framework.
In other words, I am very much inclined to believe that full .NET will continue to be developed by Microsoft, and WinRT is really for lightweight apps that need to be run on both "WinPad" and desktop. (Is anyone else calling it "WinPad", or did I just coin the term?? lol)
Let's say, for "giggles", that Microsoft was actually stupid enough to completely abandon the full .NET framework in favor of the lighter WinRT. What then? Nothing. Fortunately for us, Microsoft isn't the only game in town as far as .NET development goes. I've been fairly impressed by Mono, which offers a variation on .NET that's even cross platform... running on Windows, Linux, Mac, and even Android & iOS. Since Microsoft isn't the only one offering the full .NET "experience", if Microsoft jumps ship for an all-WinRT future (very unlikely IMO), all you'd need to do is switch to Mono, where your C# code should work pretty much as-is.
So, don't worry about it. Continue writing .NET apps until you know you'll need an app to run on both platforms. Then use the WinRT subset for that particular app. I think (and apparently Microsoft does as well) that there's room in the computing ecosystem for both full-on .NET desktop apps and lightweight WinRT apps. In short, WinRT is an addition to our computing ecosystem, not a replacement for full .NET.
Bottom line is that Metro is for "Windows 8 Apps", not "Windows Apps"... the latter being "real" Windows apps as we all know and love, and the former being lightweight apps that run on BOTH the desktop and WinRT. For applications appropriate for the portable space, that's probably the way to go... the *only* way to go if you want to target WinPad (Windows 8 tablets). For Line of Business applications that will require a more desktop experience, the full .NET is probably the way to go. (If portability is needed in such cases, I could see making a "light" version of an app with simpler controls and fewer features with Metro as a side-by-side addition to the main desktop app written against full .NET... that's pretty common these days for road warriors with iPhone apps that let them do some things for work while on the road, while having full features at their desk.)
Regarding WinRT appearing on the desktop, it does indeed, but only for Windows 8. (AFAIK there will be no WinRT mode ever for Windows 7, Vista, or XP.) This is done so that apps written for WinPad will also run on the Windows 8 desktop... it doesn't mean that WinRT is the "real core" of the Windows 8 desktop, or even the most important aspect. It's just something added to the desktop experience to let you use your Metro apps on both types of devices. This would be analogous to Apple creating a means to let apps for iPhone run natively on Mac OSX.
So, again, I figure it's not a replacement API, but a new additional API that has its purpose, just as the full .NET experience also has its purpose.
No. Of course it's not true. I often like to lie to people in answers because I'm a sadist who wants them to waste time.
Of course it's true. I know it because I'm doing development with WPF on Windows 8 desktop using WinRT functionality where I can, and I've run up against the limitations. For instance, you can't use the WinRT camera APIs. You can't access the contracts. There are many more things you can't do. I believe MS has documentation somewhere on what APIs can be used.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
I am trying to create a UML Class Diagram Editor and Generator of Class Files in (PHP but open to support for other language) based on the Diagram as a school project and I am having a difficulty on designing my classes to fit with the project.
for example, if I will create a class UMLEntity(these are the items that can be added diagram) base class which will be extended by UMLClass and UMLInterface that both have UMLMember (UMLProperty, UMLMethod). The problem is UMLEntity and UMLMember both have modifiers (public, protected, private, static, abstract, final etc) but limited depending on each type (ex. interface can only have public members and cannot be static, interface cannot be static). so maybe I should automatically set those members as public, but how?
Can anyone help me out what is the better way for this scenario.
Or can you please share your approach if you'll be the one to develop this project
I am trying to create a UML Class Diagram Editor and Generator of Class
That is a big project so hopefully you have severly limited the scope so you actually have a chance at succeeding at something.
The 'descriptor' class defines the entity but it doesn't validate it. Validation occurs only at input, so in your case as part of the GUI itself.
Each descriptor has methods. Each descriptor has a type ('class', 'interface'). Methods, which also have a descriptor class (type of 'method') have a an access modifier that specifies what the access is.
That's not the way the forums work. Presenting information like that would require a fair bit of code and description, and that's something that should be done through an article. The way it works is, you try something; if it doesn't work, you come here for help with the code that you've put together and we help fix that code.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington