What browsers is supported by stable Dart 1.1.1 - where can I find such information or results of tests done on browsers. I want be sure what I can except in future version.
It is not clear for me what mean "major browsers" since it is not clear if it is tested. I plan to use dart since can be nice in doing advanced application.
I think only about compatibility of Dart/JavaScript - not interested in pure Dart in Chromium.
From the Dart FAQ:
Q. What browsers do you support as JavaScript compilation targets?
We’re currently aiming to support the following browsers:
Internet Explorer, versions 9 and 10.
Firefox, latest version.
Chrome, latest version.
Safari for desktop, version 6.
Though "We're currently aiming to support" certainly doesn't inspire the same level of confidence that "We support" would.
It's not really an answer but to long for a comment:
Dartium is intended for development only.
JavaScript generated from Dart is currently the only supported scenario of Dart for production use.
Dart or more specific the generated JS helps a lot in abstracting browser differences away but there are also still a lot of open issues, some with known workarounds and some without.
I doubt there can or will be a perfect solution even in the future.
How good or bad someone finds the support of one of the browsers listed in #PixelElephant s answer is mostly based on opinion and/or what features someone wants to use.
If you have issues with some of these browsers, post an issue. Common features are likely to be fixed in the short therm others may take longer (also depending on complexity).
Related
There have been posts in various places over the last few years about WebVR in Electron, and the answer has always been (very reasonably) that it is not a core part of Chromium and so not supported in Electron.
However, WebXR is now a core part of Chromium. As long as you have an OpenXR installation Chromium runs WebXR with no need for special command line options or flags. However, the versions of Electron based on these versions of Chromium still do not allow XR. navigator.xr is present, but attempts to get a webXR session always fail. Is there any information about when we can hope for WebXR support?
This is probably better as a feature request or question for the Electron community, not StackOverflow. My guess is that although WebXR APIs might be part of Chromium now, the underlying OpenXR integration is still up to the project that uses Chromium. So you're really just seeing the stubs of the API, not the actual implementation itself.
As you can probably guess, my knowledge of coding is very limited. Nonetheless, I do know a little Java. I have Eclipse and was wondering if I could use it to code for iOS iPhone/iPad applications. I know that I would almost certainly have to use a language other than Java, but I'm clueless as to what packages or plugins I would need to install in Eclipse to use it to code for iOS. If you guys could answer this question in extreme detail or link me to a very good sequence of video tutorials, I would be extremely grateful.
Yes you can!
If you can live with coding ActionScript, which should be easy to learn with a Java background, you can use Eclipse & AIR to code for iOS (and Android at the same time)
Some resources:
http://flex.apache.org/
http://labs.adobe.com/technologies/flashruntimes/
http://blogs.adobe.com/flashplayer/
http://flashdaily.net/
Be aware that many apps in the store have been build on this platform, and the community is pretty alive and supportive.
The short answer is, "not natively."
Apple pretty much restricts "native" iOS development to XCode which, as #Bob said in his answer, is only available for OS X. So that means no Eclipse or Java-based development. However, there are several cross-platform development frameworks and tools that work to varying degrees of quality. Here are a few, in no particular order:
PhoneGap
Appcelerator
Corona
Adobe AIR (see answer by #dogsgod)
There are others, but those are ones that I've at least heard of and might have tried a little bit. Some, like Appcelerator, have IDEs built on Eclipse, so at least the dev environment would be familiar.
IOS apps are written in Objective-C or Swift using XCode. (This also means you'll need a Mac to do so. XCode is only available for OSX.)
So unfortunately this means the answer to your question is no. You cannot use Eclipse to write an iOS app.
I am just wondering if is it possible to run extension like colorzilla / firebug in xulrunner.
In fact I am creating my own extension now and I was trying addon_sdk but this is very problematic to put extension icon/button next to location bar.
So I decided to work with xul, and I know that problem doesn't exist here. And Of course the best way to learn is analyze other code, a changing it. But I can't run any extension in xulrunner. Any hint / help ?
xulrunner is just a runtime or platform. You'd need an actual app on top of that. In that regard, Firefox, Thunderbird, Seamonkey, InstantBird, etc. can be considered (complex) xulrunner apps.
Existing extensions may run, with or without modifications in such a xulrunner app. Well, likely with modifications, as most extensions use APIs specific to Firefox or Thunderbird or ...
The add-on SDK is not generally isn't a good fit for generic xulrunner apps: It is too much tailered against Firefox specifically.
I get the "BASE SDK Missing" when re-opeing projects. (I got the latest build of xcode, and latest SDK installed.)
It seems to be happening when I quit a project, (not exiting xcode), and re-open the project after a while. I have tried both, with and without my iPhone plugged in. I have tried to fix the problem like described here, but it does not help for me. - It just makes it even worse! (unrecognizable SDK)
The only way I have managed to get it back to normal, is to do a manual re-boot of my mac, plugged in my phone, waited until it has checked my iPhone, and then, opened xcode. Time consuming and annoying!
Why does it happen and what is the trick to fix this?
Your recent upgrade of Xcode likely removed the earlier SDK that your project was set to use. There are a couple of solutions for the problem. The most simple solution is to always select the "Latest" SDK in your project's settings and not select a specific option. You may be uncomfortable with the idea and want to run your app on an older device but it's important you understand that all of the newer SDKs can generate code that works on older versions of iOS. There's a separate hard to remember option for setting the deploy target. (It took me a while to learn how/why to use this but it's well worth it.)
The second option is to actually find a version of the SDK that your project is set to and attempt to reinstall it. I suggest going this route only if necessary as it's not guaranteed to work in each case. Older SDKs may or may not work in later versions of Xcode (Eg. SDK 3.0 might not work in Xcode 4.3.2) due to major changes in the toolchains. Tools like gcc/gdb are deprecated in favor of llvm/lldb. Still, you may have a valid reason for using an older SDK. You may have to fix a bug that is present only when using the older toolchain or you may need to reproduce a problem that only happens with builds generated from your build server. In many of these cases it might be easier to upgrade where the problem occurs (Eg. upgrade the tools on the build server) or downgrade your dev environment. (Install an older version of Xcode.)
The reasoning behind the frustration is that Apple highly encourages rapid adoption of it's latest tools and technologies. It creates a better product as the dev community is forced to stay current and competitive while the users are forced to maintain upgrades to ensure apps continue to work. This is in contrast with the traditional model of backward compatibility allowing developers to support revision -n of a product/platform. It is also great for business since rapid adoption of the latest often encourages purchase of newer hardware and products to get the best experience. The rapid adoption ensures the more robust software along with bug fixes, enhancements make it to the majority of consumers overall increasing their penetration in the market.
You have to set your target and project's base SDK to "Latest" and not an explicit option. If you choose one explicitly it seems to break if you update xcode versions.
Background info:
Over the past week, I have been messing around with Chrome extensions and had no problem creating my extension. Great, Chrome rocks for making the development process very easy to learn, and, well... just easy!
Now I have it in my mind that I'd like to create this extension for as many browsers as I can, so I decided on Firefox next.
What a mess! There documentation has done nothing but give me a headache and waste my time so far, VERY convoluted and just generally unorganized.
I have managed to locate a code sample for a simple extension that I think I can use as a starting point and have begun messing around with - fine...
I have learned that this sample extension will not work with anything less than Firefox 4, as it uses the bootstrap technique to make the extension installable without a browser restart. Ughhhhhh....
Now we arrive at my questions:
Is it possible to develop an extension for Firefox 7 that will work with previous versions of Firefox? I don't even care about anything prior to Firefox 4, if that's the cutoff point for restart-less installations. It would be nice to know that what I am spending all this time making will work consistently and for more than a week when the user is prompted to upgrade next.
How about the reverse? Can I create an extension that is compatible with Firefox 3.5 through Firefox 7? I realize it would require a restart to install, but that would be acceptable if it resulted in a working extension regardless of the version.
Can anyone with experience on this stuff share a bit of what I'm getting myself into here? It seems like this is a nightmare of a platform to develop on, and that I will be constantly fixing my extension.
One last piece of relevant information:
The extension I am developing is purely javascript based - this stuff should work (I think?) because it's dependent on just one feature "content scripts" that really shouldn't be changing in implementation between versions at this point... right?
So what exactly am I missing? How do you create easily manageable Firefox extensions that will work in all versions of the browser?
Thanks everyone! :)
You have to distinguish between "traditional" extensions and extensions built with the Add-on SDK. The former are far more powerful given that they have direct access to all APIs the browser uses - but that's also the reason why they are more complicated to write and why the documentation is rather unordered (there are simply very many things that you could do, far more than you could with Chrome). They are also more likely to break as the browser changes. The Add-on SDK on the other hand gives you a limited API much like Chrome. The Add-on SDK currently supports everything from Firefox 4 onwards (yes, because of restartless installation), with the promise that browser changes will merely require your add-on to be recompiled with a newer version of the Add-on SDK. In fact, that recompiling will likely happen automatically in future for add-ons hosted on addons.mozilla.org. On to your questions:
Is it possible to develop an extension for Firefox 7 that will work with previous versions of Firefox?
Sure it is. The Add-on SDK currently marks your add-on as compatible with anything between Firefox 4 Beta 7 and Firefox 8 Alpha 1. Even as traditional add-ons go - starting with Firefox 4 the differences between particular browser versions are rather small, most things work in all of them. You can also stay compatible with Firefox 3.x but depending on what you do it might require some effort. Important information:
Firefox 4 for developers
Firefox 5 for developers
Firefox 6 for developers
Firefox 7 for developers
How about the reverse? Can I create an extension that is compatible with Firefox 3.5 through Firefox 7?
It doesn't matter which way you go. I wouldn't recommend spending much time on Firefox 3.x support however. With Firefox 3.5 no longer supported the only relevant version is Firefox 3.6. According to the statistics of my add-ons roughly 18% of the Firefox users continue using it. In the next few months this percentage will get significantly smaller, especially when Mozilla announces end-of-life for this branch. So for a new add-on supporting it is usually not justified.
Can anyone with experience on this stuff share a bit of what I'm getting myself into here?
Depends on how complicated your add-on will be. Given that you are developing an equivalent to a Chrome extension, you will most likely be using the Add-on SDK which means that there won't be any compatibility problems. As traditional add-ons go, simple add-ons that don't rely on some obscure implementation details also typically don't have any trouble staying compatible (I have two add-ons that didn't need a single adjustment since Firefox 3.5). Add-ons that go deep down into the system are more problematic of course.