I'm trying to find a straightforward way to consume arbitrary iOS libraries from MonoTouch. At the moment, I need this calendar functionality, but the question applies to any such component.
I've read the Xamarin article on creating iOS bindings, but the process of building these bindings looks so complex (and tedious and likely error prone) that I think it would actually be easier for me to re-implement the given functionality in C# from scratch than it would to go through this process. Creating these bindings would require a deep dive into ObjectiveC, and I'm using Xamarin precisely so I don't have to do that.
As it stands, I am torn because I really want the ability to access some iOS libs, but don't have the time to master this process enough to create these bindings. Is there any other way to access these libraries?
(I wonder if there is or could be any sort of automated binding generator? It seems to me that 95% of the work is boilerplate translation of ObjectiveC headers to C# idioms, and an automated tool could do this, and then the final tweaking could be done by hand.)
You can:
Consume the ones that are already bound: you can find many on github, in particular in monotouch-bindings, and in the (just announced) Xamarin's Components Store;
Bind them yourself. That does require some Objective-C knowledge. Some tools/scripts exists but, in the end, the manual by hand editing is where the Objective-C knowledge is needed. There are general unit test (e.g. for Touch.Unit) that you can re-use that will dramatically reduce the number of bugs in them (blog post will be coming up soon to describe them in details).
Convert (or write from scratch) some into C# components;
Related
In the expert system D3WEB, it is possible to insert\develop\use Ontology. However, I cannot get the point what's the purpose to introduce ontology in D3WEB?
The nice example on this page, https://www.d3web.de/Wiki.jsp?page=Demo%20-%20Ontology , shows how to develop an ontology in D3WEB. In my opinion, it can be more efficiently developed using Protégé. If the contents shall be changed with a real application, for instance, an ontology about 'dog', in the real application there could be instance dog A, B, C, D. It might be not feasible to 'insert' the instances into the D3WEB knowledge base. However, if the ontology changes over time, how to use the ontology in D3WEB then?
In my opinion, the best way is to develop an ontology outside of D3WEB using Java code. However, I believe the designer of D3WEB would have a nice reason to introduce ontology in D3WEB. I will appreciate it if someone let me know.
This is a somewhat common question we get regarding d3web-KnowWE, one reason might be, that our naming is somewhat misleading. So let me explain.
First there is d3web the java framework to run knowledge bases with strong problem solving knowledge, including rules, decision trees, flow-charts, covering lists, cost-benefit dialog strategies, time based reasoning, and so on. This framework in its core does not provide any GUIs, but is meant to integrate problem solving capabilities in other applications/expert systems. It also does not provide a way to properly create/author the knowledge bases it runs, aside maybe from doing it in the Java code on an API level.
To also provide proper means to author and develop a knowledge base, including some basic dialogs to run, demo, test, and debug the authored knowledge bases, we began working on the wiki system KnowWE, which today is basically a heavily extended JSPWiki. The page d3web.de itself for example is also just a build of KnowWE with specific content.
While we were working on and with KnowWE, we began to really like the approach to edit and author large knowledge bases in this 'wiki way', were you automatically support multiple distributed users to work on the same knowledge base, have automatic versioning, can add nice documentation directly beside the actual formal knowledge, can generate knowledge using script (because it's all just simple text markup), and so forth. Also, the underlying architecture of KnowWE became quite good and mature over the years.
So after some time of this, we found ourselves in the need to also author large ontologies. And yes, Protégé is a nice tool to develop ontologies, but for our use cases, it was just not well suited and we also found it to not scale very well. So we began to implement some simple markups to also allow to also develop ontologies in KnowWE. After then recognizing, that authoring ontologies the 'wiki way' indeed works pretty nicely, we decided to again also share these tools with everybody else on d3web.de. And that is why today you can author/develop both d3web knowledge bases and ontologies in KnowWE, although there is no actual connection/interoperability between both as of now. That would be nice of course and maybe we add this in the future, but for KnowWE is just a development environment for these two knowledge representation.
Maybe you can see KnowWE similar to an IDE like eclipse or IntelliJ, where the same application can be used to develop many different programming languages. KnowWE does the same for different knowledge representations.
A problem is maybe, that historically, we didn't differentiate very well between KnowWE and d3web, because KnowWE was narrowly used to build d3web knowledge bases. We also like to call KnowWE and its distribution package d3web-KnowWE for example. But maybe this should change...
Thanks for pointing this out, I will try to correct/clarify this on d3web.de
I'm starting to study Dart. It seems a nice language and in some aspects a real improvement over JavaScript. Since it claims to come with "batteries included" and to be meant for "structured web apps", though, I fail to understand how to actually structure a web app with it. Almost all the tutorials concentrate on language features, but Dart is quite simple and with many familiar bits, so that's the easy part.
Recently I fell in love with AngularJs. Now routing, two way binding, nested scope, clean separation of concerns... This actually means "structured" to me. But all the Dart examples I find are about selecting HTML elements and attaching listeners to them. This is old-style jQuery-like web programming and quite frankly the opposite of what I think of when I read "structured".
I don't want to compare a language and a framework and I know that Angular Dart is out, but I fear I'm missing something of vanilla Dart, because if it's all about a shorter syntax for lambdas, class based OOP vs prototypical OOP and the like, I don't see how it's supposed to be a game changer: there are many other languages that provide an alternative JS syntax (à la CoffeeScript) and compile to it, and they don't come at the price of losing a perfect integration with existing JavaScript libraries and tools.
Sure, it has optional static typing, which may be great, but this comes more to a matter of preferences. I'm a full time Python and Ruby developer and I'm perfectly fine with dynamic languages. Is this what they mean by "structured"?
Thanks for any clarification that will eventually come.
I work on AngularDart and have some experience structuring web apps.
When building a web app in Dart you would pick a web app framework, for example AngularDart or polymer.dart. Web app frameworks have a lot of opinion which is something that doesn't fit in the core libraries. In that respect, "vanilla Dart" is fairly vanilla.
Since I'm most familiar with Angular, I'll discuss the Angular + Dart combination. However, the rest of this post is also true for polymer.dart.
Angular provides a lot of structure to your app. We've been able to provide a similar structure for both Dart and Javascript. The concept of directives, data binding and dependency injection exist in both.
Dart provides more structure and we've been able to use that structure while building AngularDart. e.g. the directive API is defined in terms of annotations which means that IDEs understand them and can help you code.
There are a number of "structure" features in Dart. One of my favourites is tooling. With types and annotations comes better tooling support.
Types in Dart are most useful when combined with tools. Auto-complete is great but for large web projects, static analyze is even better. For example, in AngularDart, since directives are annotated classes, we can assert that the annotation is correct. Even more interesting is the potential to build tools. In AngularDart, we have a tool that extracts and analyzes all directives. This type of tooling is possible in Javascript but easy and supported by the language in Dart.
libraries, packages
integrated dependency management with pub package manager
class based instead of prototype based
scopes of variables as one would expect in a modern language
static syntax check
better tooling support like code completion
I've been browsing the DeHL repository on GoogleCode, and it looks really good to me.
Many interesting features that make basic programming tasks easier; Some neat things that are in the DotNet FCL, but are missing from the Delphi RTL can be found in this library;
Coded in a modern way, making good use of new language features;
Each class, record type, member function and parameter is documented in such a way that it'll show in the code completion of the Delphi IDE;
Well-organized and clean code;
Plenty of unit tests;
Open source and Free;
Basically, it looks like this library should've been included with Delphi, as part of the RTL.
One major drawback: The project has been discontinued. :-(
Now my question is:
Would it be safe to rely on this library for future projects, and use it as a base framework to build upon?
Basically I'd like to hear from somebody who's actually used this library whether or not it's worth it to invest time in getting to know this library, and why.
IIRC the project was discontinued because it was an over-engineered first attempt and a lot of its features turned out really messy and bloated. You should look at Alex Ciobanu's second attempt, which is simply called Collections. It contains most of the interesting features from DeHL, but leaner.
Be careful, though. It still makes heavy use of generics, which will make your binary size really big if you use it a lot, because the compiler team hasn't implemented a way to collapse duplicate code yet.
I’m writing a small application based on FParsec.
Today, I’m looking for an opportunity to make a version for Compact Framework.
Apparently, it is not that simple to build FParsec sources for .NET CF. The FParsecCS library has unsafe code and some references to the types that are not available in CF. Namely, System.Collections.Generic.HashSet, System.Text.DecoderFallbackException, and more.
I’m wondering if there’s any way to make it built. Obviously, I’m trying not to alter the code as it would be hard to update when further versions of FParsec released.
I don’t really care about performance. If there is a generic CharStream that can be used instead of high-performance one you have, that would be quite sufficient.
Thank you for your help.
I don’t have any experience with .NET CF and never tried to make FParsec run on it. However, there’s a Silverlight version of FParsec, which might be a good starting point for a port to .NET CF. The Silverlight version builds on the LOW_TRUST version of FParsec, which doesn’t use any "unsafe" code. Hopefully, the stream size limitation of the LOW_TRUST version won’t be an issue for your application.
The easiest way to deal with the HashSet dependency probably is to implement you own simple HashSet type (based on a Dictionary) that implements the few methods that FParsec actually uses for its error handling. If the DecoderFallbackException is not supported, you can just comment out the respective exception handlers.
If you track your changes with HG, it shouldn’t be difficult to merge in updates to FParsec. Depending on how extensive the changes for .NET CF are, I could also include them in the main source tree for another conditional compiler symbol.
This is closely related to another question I asked: Is there functionality that is NOT exposed in the Open XML SDK v2?
I am currently working with Open XML files manually. I recently had a look at the SDK and was surprised to find that it looked pretty low level, quite similar in fact to the helper classes I have created myself. My question is what exactly does the SDK v2 take care of that you would have to do manually when coding by hand with an XML library?
For example, would it automatically patch the _rels files when deleting a PowerPoint slide?
In addition to Otaku's links, this shows an example (near the bottom) of navigating an OpenXML document using the IO.Packaging namespace versus the SDK.
Just like Microsoft states on the download page for the SDK:
The Open XML SDK 2.0 for Microsoft
Office is built on top of the
System.IO.Packaging API and provides
strongly typed part classes to
manipulate Open XML documents. The SDK
also uses the .NET Framework
Language-Integrated Query (LINQ)
technology to provide strongly typed
object access to the XML content
inside the parts of Open XML
documents.
The Open XML SDK 2.0 simplifies the
task of manipulating Open XML packages
and the underlying Open XML schema
elements within a package. The Open
XML Application Programming Interface
(API) encapsulates many common tasks
that developers perform on Open XML
packages, so you can perform complex
operations with just a few lines of
code.
I've worked pretty much only with the SDK, but for example, it's nice to be able to grab a table out of a Word document by just using:
Table table = wordprocessingDocument.MainDocumentPart.Document.Body.Elements<Table>().First();
(I mean, assuming it's the first table)
I'd say the SDK does exactly what it seeks to do by providing a sort of intuitive object-based way to work with documents.
As far as automatically patching the relationships -- no, it doesn't do that. And looking back at how you actually state the question, I guess I might even say that (and I'm fairly new to Open XML so this isn't gospel by means) the SDK2.0 doesn't necessarily offer any extra functionality, so much as it offers a more convenient way to achieve the same functionality. For example, you still need to know about those relationships when you delete an element, but it's a lot easier to deal with them.
Also, there's been some efforts on top of the SDK to add even more abstraction -- see, for example, ExtremeML (Excel library only. I've never used it but I think it does get into things like patching relationships).
So I'm sorry if I've rambled a bit too much here. But I guess my short answer is: there's probably not extra functionality, but there's a nice level of abstraction that makes achieving certain functionality a lot easier to handle -- and if you've been doing it by hand up until now, you'll certainly have the understanding of the OPC to understand what exactly is being abstracted.
As a starting point, read this from the Brian Jones & Zeyad Rajabi blog.
I don't know of a side-by-side comparison, but the following articles/videos do discuss the two:
Using the Open XML SDK 2.0 Classes
Versus Using .NET XML Services is
a good place to start comparing the
two.
Open XML and the Open XML SDK is
a deep dive video which discusses both.
Finally, this is a What's New for 2.0 - it can be assumed that neither 1.0 or hand-coding have these benefits.