We have been using Adobe Flex for a major project but it's just too slow.
We're considering switching to Silverlight.
The problem seems to be that Silverlight is not as widely supported by browsers as Flex/Flash is.
For example I tried to access the Silverlight showcase using Safari for Windows but it didn't work.
A web RIA platform surely has to have browser ubiquity as its foundation?
Browser Plugins are essentially native applications, so you essentially need a Plugin for each architecture.
For example, there is no 64-Bit Flash Plugin for Windows, so I always have to use 32-Bit IE for that. I also believe that there is no Linux-PPC support, but it's been a while since I've looked at that. And that new JavaFX stuff from Sun also does not run on many platforms and browsers.
For a list of supported Platforms, Wikipedia has a neat table:
http://en.wikipedia.org/wiki/Silverlight#Compatibility
IMHO Flash is the only thing that comes near perfection. Microsoft is just supporting a few major browsers.
Related
I'm planning web application and considering silverlight as development platform. Will it help to solve browser compatibility issues? The app intended to be used on desktops only (no mobile).
Yes, it will solve browser compatibility issues, and could work on both Mac OS and Windows with the very same code.
The only drawback is that, the first time your user connect to your application, he will need to download the Silverlight plugin.
Awesome you would say? Well, unfortunately some people that probably never try to do something like image processing or advanced line of business application in a browser decide that plugins are not so cool and that you would be able to do the same thing with the magic power of HTML5.
We are still waiting to have the same possibility in HTML5 that we have in Silverlight or Flash, but plugins are already dead. At least as long as no big compay want to push them again.
So, my advice would be: don't start a project in Silverlight. You will have problems, even if you do not target mobile. For example it becomes harder and harder to find compatible good tools (like ReSharper, NCrunch, or even just a decent unit testing library). And in further release of Windows and Mac OS, it will probably not be supported at all (IE for Windows RT already does not support Silverlight).
Sorry man, Silverlight is dead, you arrive after the battle.
If your developing your application for an Intranet, I would say Silverlight is an excellent choice.
If you are developing for the Internet, use an HTML based language
At my job we are developing a GIS application which will be developed using Silverlight + .NET
But, I heard that Silverlight will not be supported by Microsoft as also they are stopping Silverlight, is it true ?
Is it suggestable to use Silverlight if so with which version of silverlight we can use. ?
Thanks.,
Use Silverlight 5. Current version have 10 year support, and it better than Flash, java or damn it html.
In the future you can migrate to another .NET-based framework by easily porting code.
About silver light support, you can find these answers from Microsoft Silverlight Support Lifecycle Policy.
Keeping in mind that MS would support these browsers till 2021, I would recommend using Silverlight5 if you really have to use Silverlight.
However for new developments I would recommend you to evaluate Html5 as well.
YES! Silverlight is still the best technology to use for web based Line of Business applications. Silverlight will be supported for another 10 years and it will be available within Windows 8 desktop. Silverlight +[Arc]GIS are a great combination. It is so easy to create full functioning application and with little effort. Silverlight is not dead. It is still a great technology to use that is available on (almost) every platform.
Ultimately it comes down to:
1) What do you know: Are you an HTML/JavaScript ninja? Then use that, do you know Flex better then your own children? Or are you a skilled .Net assassin?
2) How much time do you have? Do you want to learn something new and have gobs of time? Then go for that new shiny object (HTML5) and get yourself some street cred.
This probably belongs on programmers.stackexchange.com. However:
Silverlight will continue to be supported for some time, but all signs point to it no longer being actively developed.
If you want a technology that's actively developed, I'd recommend HTML 5 for web based applications and WinRT for Windows 8+ native applications.
Ultimately, though, you should go with what works best for your situation. After all, WinForms is still used on many successful greenfield projects.
Silverlight is based on the NPAPI architecture that is no longer supported on Google Chrome (from browser version 42 upward) though you can still run it on IE and Firefox. HTML5 is supported on all browsers.
From a career standpoint, using Silverlight (which uses XAML) gets you an easier entry into developing apps for Metro/Windows Store/Universal Windows Apps (these can be developed using HTML5/JS too but you'll find a larger developer base using C#/XAML).
Finally if you're already a WPF developer, it's fastest if you develop for Silverlight. See Silverlight vs Flash vs HTML5.
I'm prospecting alternatives to develop for multiple mobile platforms, and have found Codename One, that uses Java as lingua franca, instead of HTML/CSS/JS or scripting languages.
What I couldn't find is how does it work. Does it bundle a JVM with the application for iOS and Win7, and uses Dalvik in Android? Does it translates source code to native, and do we have access to this source code? Is there other magic, considering they promise "no compromise"? What limitations should I be aware while coding agnostic Java?
Preemptive strike: this is a question about Codename One, not about which cross-platform should I choose or if I should go native or if I should go web.
Codename One has an optional SaaS approach so this might (and probably will) change in the future to accommodate improved architectures. Notice that Codename One also provides an option to build offline which means corporations that have policies forbidding such cloud architectures can still use Codename One with some additional overhead/complexity. It also means you can use it for free without ever working with the build servers.
Currently on Android the standard Java code is executed as is. Java 8 syntax is translated using retrolambda for all platforms when its used. This allows it to be compatible to all Android versions as well as other ports.
On iOS Codename One built & open sourced ParparVM which is a very conservative VM. ParparVM features a concurrent (non-blocking) GC and it is written entirely in Java/C. This effectively means that an xcode project is generated and compiled on the build servers so its effectively as if you handcoded a native app and thus "future proof" for changes made by Apple. E.g. with recent 64bit and bitcode changes to iOS builds ParparVM needed no modifications to comply with those changes.
In the past Codename One used XMLVM to generate native code in a very similar way but the XMLVM solution was too generic for the needs of Codename One.
iOS builds are compiled and signed on Macs in the cloud using xcode (the official Apple build tool). This makes them compatible with current/future changes from Apple and allows developers to use Windows/Linux while targeting iOS. You can read more about the compatibility of ParparVM to iOS here.
In the past Codename One supported Windows Phone using a C# translator that relied on XMLVM but it was not an ideal approach. Notice that the XMLVM backend that translates to C# is very different from the one that was formerly used to translates to iOS. Codename One chose to discontinue that old backend as it wasn't as powerful as the new UWP backend and doesn't match Microsofts goals moving forward and focusing on UWP (Universal Windows Platform).
For Windows 10 desktop and Mobile support Codename One uses iKVM to target UWP (Universal Windows Platform) and has open sourced the changes to the original iKVM code in the Codename One github repository.
Notice that UWP builds are done on a Windows 10 machines in the cloud thus allowing developers to use Mac/Linux or older versions of Windows when building native windows apps...
JavaScript build targets which are available on the enterprise level subscribers use TeaVM to do the translation statically. TeaVM provides support for threading using JavaScript by breaking the app down in a rather elaborate way. To support the complex UI Codename One uses the HTML5 Canvas API which allows absolute flexibility for building applications.
For desktop builds Codename One uses javafxpackager, since both Macs and Windows machines are available in the cloud the platform specific nature of javafxpackager is not a problem.
What makes Codename One stand out is the approach it takes to UI where it uses a "lightweight architecture" to allow the UI to work seamlessly across all platforms and be developed almost entirely in Java. It is augmented by the ability to embed "heavyweight" widgets into place among the "lightweights". You can learn more about this in this blog post. Notice that at this time peering is undergoing some improvements and now supports more elaborate usages such as layering.
A lightweight component is written entirely in Java, this allows developers to preview the application accurately in the simulators & GUI builder.
Codename One achieves fast performance by drawing using the native gaming API's of most platforms e.g. OpenGL ES on iOS.
The core technologies behind Codename One are all open source including most of the stuff developed by Codename One itself e.g. ParparVM but also the full library, platform ports, designer tool, device skins etc. You can learn more about using the Codename One sources here.
FYI Shai Almog, the author of this answer, is the CEO of Codename One.
Codename one took very balanced approach to portability. I would like to add a pragmatic comment.
From the user interface side, CN1 does paint all its UI on platform-provided canvas. It tries to mimic platform native look and feel, if you choose it, but has as much success as Swing had with its "native platform look and feel", because native platform constantly changes, and "native l&f" always lacks behind and in most cases feels not quite right.
But, if you choose platform-independent look and feel (which is the sort of the trend today), you are not restricted by Codenameone's default component set set in any way: it's just like Swing with its cross-platform look and feel ("Metal" etc.). Which is good.
From the language side: on iOS it is java compiled to C which is then tied to hand-written Objective-C, and it does not bundle VM, only portability layer. Most important here is the fact that java is compiled to C and not Objective-C, which make it faster then idiomatic Objective-C code, because it does virtual or, more often, direct method invocations instead of slow Objective C message dispatch. Which is good.
It also may seem little faster on Android, because, while using Dalvik/Art, it does not use Android native UI which is bulky compared to CN1's. This can make dynamic UI creation faster in runtime, which is good.
One of the strongest points of CN1 approach is its emulator (implemented over desktop JavaFX canvas) which you use to develop software. Emulator makes use of same UI code and portability APIs as on mobile platforms and lets you use IDE of choice for debugging. It restarts quickly, and edit-compile-run cycle is very sustainable compared to android. Which is good.
Second very strong point (main one!) is open nature of their UI library, all native code and bytecode-to-C translator. If you spend some effort, you can avoid building Android/iOS ports on their farms and untie yourself from their particular revision of product (but not from quite a few value-added services they offer, which are not open source!). Depending on your situation, this may (or may not!) be quite good for you!
Weak point of Codenameone is its less-then-ideal maturity, which means you can easily shoot yourself in the foot using basic UI components, if you use them the way they were not indended to be used. Also it means that its java portability layer is not big enough (and has holes in it) to cover everyone's need, and you may have to use native in some places, and port other pure java libraries, too.
Also, current state of graphics performance is sub-optimal; if you get bunch of text on screen, you'll easily miss 16msec fluid animation/repaint time limit, this can be worked around by double-buffering, but it also has its limits. Luckily, there is still room for optimization in implementation on both main platforms, hopefully they will improve it.
Overall, Codenameone has good niche as a cross-platform framework for several classes of applications; you may find a value in their services, too.
I know that you have to install plugins before you could use them in the web browser.
Will it always be like this for plugins like Silverlight?
Or do you think major browsers (Firefox, Safari, Chrome etc) be shipped with it in the future?
I think the odds of it being supplied with those browsers are very slim. It's not on Google's\Mozilla's priorities and probably will never be (Maybe unless it becomes extremely popular.. But that's a very long shot).
Let's worry about HTML5 full support in all major browser before we're thinking about that..
But do notice that all Windows versions since Vista and Server 2008 do include the WPF runtime libraries, which means they do support Silverlight.
I think it depends on what the people want and not so much about what Google or Mozilla wants. Majority rules and eventually if enough people want it then it will be preinstalled. It happened for Flash, why not Silverlight?
I am willing to develop a mobile application. I wish to have something working for android, windows mobile, symbian and blackberry.
Which is the best way to do that?
I had read here:
You could aim to wrap the sections of
the platform specific APIs (iPhone SDK
etc.) that you use with your own
interfaces. In doing so you are
effectively hiding the platform
specific libraries and making your
design and code easier to manage when
dealing with differences in the
platforms.
I was hoping there exists a framework that does this for me, but it doesn't exist or I didn't find any.
I feel that sort of things will make my code harder to maintain and perhaps it's better to have one version for each platform.
Anyone with experience in the field?
Another links of interest:
most-promising-mobile-platforms
long-term-potential-of-iphone-windows-mobile-development-platforms
Does Java not count (in various guises)
Java on Symbian
Java for Windows Mobile
Java on Blackberry
Android Java Virtual Machine
It should be simpler to manage API differences in a consistent language/runtime platform where capabilities can be assessed in-code ... and configurations of code made at build-time.
As much as I dislike Java, it is fairly ubiquitous. As for the iPhone ... apart from it being much hyped and locked down ... you can get Java to run on jail-broken phones ...
What happened to Apple's open and friendly appearance? The cynic-inside knows the answer ;)
You might want to look into PhoneGap (http://phonegap.com/). From their own description page:
PhoneGap is an open source development tool for building fast, easy mobile apps with JavaScript.
If you’re a web developer who wants to build mobile applications in HTML and JavaScript while still taking advantage of the core features in the iPhone, Android and Blackberry SDKs, PhoneGap is for you.
In addition to using JavaScript, it supports JavaScript acccess to native controls and features of the phones (GPS, accelerometers etc...).
There really isn't any magic bullet that I'm aware of. Even within just the Blackberry platform, there are tons of different devices with different capabilities, screen resolutions, etc. And that's just from one, single manufacturer; Symbian and Windows Mobile are likely even worse.
The answer is likely that you should focus on relatively new and consistent platforms (accordingly with very few and all pretty much similar devices), like Android and iPhone OS, if you really want to reduce your code forking and maximize your audience.
My advice will almost certainly change within a few years when there are nine different iPhone OS devices and two dozen Android platforms.
The first question to ask yourself is if you need a native application, if you do not then designing a mobile web site solution should give you the most cross compatibility, failing that I would make a iPhone and J2ME solution (the J2ME can then be ported for Android relatively easily) for the greatest coverage of users
Or investigate Movilizer. Supports iOS, Android, WinPhone, WinMobile, Desktop PCs, embedded devices, ... and many more. It uses a design once run anywhere approach.
http://www.movilizer.com
try out different cross platform dev tools,
Developing cross platform mobile application