Where I can find in Dart SDK an implemention of the UnmodifiableSetView?
In C# language exists System.Collections.Immutable.ImmutableHashSet<T>.
In Java language exists Collections.unmodifiableSet().
But I cannot find anything similar in Dart SDK.
Where I can find it in Dart SDK?
P.S.
I use Dart language not for compiling it to the Javascript language.
I use it (as is) for the computations and I need UnmodifiableSetView but I connot find it in Dart SDK.
There is an UnmodifiableSetView in package:collection.
This is an official implementation of an unmodifiable view of a Set created by the Dart team.
There is no similar class in the platform libraries. Unlike Java and C#, the Dart platform libraries are limited in size, and functionality that can just as easily be implemented in a separate library are made available as packages instead.
It's always a question about the trade-off between convenience (making everything immediately available) and size/discoverability (don't overwhelm the user).
If you are looking for functionality in, say, dart:collection, and doesn't find it, then the package:collection package is a good second location to look. Not all dart:-libraries have corresponding packages, but some do.
Related
I understand that there could be many reasons but when the developer community has already adopted ES6 and is working hard to make it better then why dart and not JS?
Is there anything special which makes dart such a good fit for Flutter?
That's an FAQ and already answered extensively
https://flutter.io/faq/#why-did-flutter-choose-to-use-dart
https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
I'm not sure why you wrote ES6 and "dart js".
Flutter has nothing to do with JavaScript.
While Dart can be compiled to JavaScript, Flutter doesn't use this feature.
For Flutter Dart is compiled to native binary code.
I did a little research after being asked the question by a couple of colleagues and thought it would help by summarising what I have read and thought about (it's a very important question for my colleagues)
Language requirements for Flutter
AOT and JIT compilation for fast reload and fast released code
A good garbage collector to clean up after creating and destroying many objects
Single threaded to avoid locks and therefore jank
An arm compiler to avoid having another engine running the code on the device (aka React Native)
Dart meets all these requirements. JS (I think) meets all the above pretty closely too, apart from the AOT and JIT compiler part.
Why didn't Flutter choose JS and build a JIT and AOT compiler? (initially they did choose JS but they switched) I could guess at the following...
Dart was built with to-binary compilation in mind from the beginning
Dart already had a to-binary JIT compiler, it added the AOT compiler later
Dart is more structured and simpler (it is type safe and has no eval)
JS could implement new language features that might jeopardise flutter dev
Dart can be optimized for Flutter without needing to worry about other uses of JS
Historically long wait times for new JS functionality (last 3 years has been better)
The Dart and Flutter teams can work together closely
Saying all of that I can imagine that a JS solution could happen but it might be costly and a more complicated solution. Dart is pretty good and Dart2 has really improved things with inherent type safety.
Dart has a declarative and programmable layout that is easy to read and visualize. Hence, Flutter doesn't require a separate declarative layout language like XML. It is easy for Flutter to provide advanced tooling since all the layout in one language and in a central place
Dart is much faster than JavaScript, as it can be compiled both AOT and JIT which helps building apps in several ways as using JIT compilation can speed up development and AOT compilation can be used during the release process for better optimization. This technique has been used in Flutter.
follow the link
https://medium.com/hackernoon/why-flutter-uses-dart-dd635a054ebf
https://insights.daffodilsw.com/blog/why-flutter-uses-dart
i am new to Unity and i am try to understand plugins. I have got the difference between a managed plugin and a native plugin, but what is not very clear to me is:
what is the difference between a plugin and a dll? what should i expect to find in an sdk to make it usable in my unity project?
Thanks a lot
To expand on #Everts comment instead of just copying it into an answer, I'll go a little into details here
What is a plugin?
It's a somewhat vague word for a third-party library that is somehow integrated with the rest of your game. It means that it neither is officialy supported by Unity, nor is it a part of your core code. It can be "plugged" in or out without altering its internals, so it must provide some kind of API that can be used by the game code.
For example, you'll find many plugins that handle external services like ads, notifications, analytics etc. You'll also find a couple of developer-tools that can also be called plugins, like tile-based map editors and such.
Plugins come in many forms - DLL files are one example but some plugins actually provide full source code for easier use. And of course, other plugins will provide native code for different platforms, like Objective-C for iOS or .jars for Android.
So to answer your first question:
DLL is simply a pre-compiled source file that can be a part of a plugin
A plugin is a whole library that can consist of multiple files with different formats (.cs, .dll, .jar, .m etc)
What do you need to use an sdk?
First of all - documentation. Like I said before, and like you noticed yourself, not all plugins give you access to the source code. And unfortunately, not many sdks have extensive and developer-friendly documentations so it can be a tough task to actually understand how to use a given sdk.
Secondly - the code. Many sdks give you some kind of "drag & drop" library, a single folder with all the neccessary files inside that you simply add to your Unity projects. I've also seen sdks that use Unity packages that you have to import via Assets > Import Package > Custom Package.
Once you have the code and documentation it's time to integrate it with your game. I strongly recommend using an abstract lyer in your game as, in my experience, you often have to change sdks for various reasons and you don't want to rewrite your game logic every time. So I suggest encapsulating sdk-related code in a single class so that you have to change only one class in your code when switching from, say, one ad provider to another (and keep the old class in case you need to switch back).
So you basically need three things:
Documentation (either a readme file or an online documentation)
The code (precompiled or source)
A versatile integration
I would like to know the minimum Android API level AndroidAnnoatations supports ? I could not find any info on their website .
regards,
Felix T
I think there is NO specific minimum Android API Level that AndroidAnnotations can work with.
Since it's a compilation tool, I mean it's related with the Java files and it's related not with Android API.
If you build an Android project with AndroidAnnotations, then some intermediate java files will be generated, which will be the final java file for Java compiler, and that's all. It's just used for convinience of your development. The generated apk file will not have information about AndroidAnnotations - it's something like a conversion tool (shorter exprssion to long complicated expression, which is not visible to you).
I think that you can use AndroidAnnotation from Android API Level 1.
Maybe some of the annotations cannot be used in Android API 1 project, but even if such case happens, just removing only that specific annotation in your .java file will make it work.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/
Is this statement true:
com.sun.xml.internal package is an internal package as the name suggestes.
Users should not write code that depends on internal JDK implementation classes. Such classes are internal implementation details of the JDK and subject to change without notice
One of my colleagues used one of the classes in his code, which caused javac task in Ant fail to compile our project as the compiler couldn't find the class. Answer from Sun/Oracle says that this is expected behavior of the compiler as user shouldn't use the package.
Question is why the classes in the package made public in the first place?
Thanks,
Sarah
Sun classes in the JDK are prefixed sun.* and are not part of the public supported interface so should be used with care. From the Sun FAQ:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java., javax.,
org.* and sun.. All but the sun.
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun., that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.
packages are not 100% Pure Java. In
other words:
The java., javax. and org.* packages
documented in the Java 2 Platform
Standard Edition API Specification
make up the official, supported,
public interface.
If a Java program directly calls only
API in these packages, it will operate
on all Java-compatible platforms,
regardless of the underlying OS
platform.
The sun.* packages are not part of the
supported, public interface.
A Java program that directly calls
into sun.* packages is not guaranteed
to work on all Java-compatible
platforms. In fact, such a program is
not guaranteed to work even in future
versions on the same platform.
It's because Java visibility modifiers (especially at the type level, where there are only two options) don't currently have the granularity to achieve the sort of visibility you're hinting at. I don't know the specifics of the internal class or classes you're using, but basically making the classes private would have made them unfit for their intended purpose, so the only other choice was public.
Sadly JAXB (bundled with Java6) seems to rely on a non-public class "com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper" to allow you to specify namespace prefixes when marshalling to xml.
You have to really go out of your way to get this compiling with ant:
http://pragmaticintegration.blogspot.com/
Summary:
Option 1.
Add jre libs as bootclasspathref
Add property: includeJavaRuntime="yes"
Option 2.
Use JAXB-RI libs - change property to "com.sun.xml.bind.marshaller.NamespacePrefixMapper"
Also mentioned here:
Define Spring JAXB namespaces without using NamespacePrefixMapper