I am stuck with this issue and I cant seem to solve it. I have my logic in a PCL and a a .Droid and .iOS clients.
I need to use the [serializable] attribute in my logic so I need to add a reference to system.runtime.serialization. The problem is there is a different dll for android and iOS how can I manage this? I did not encounter this problem before because I used shared files between the projects so each project had its own reference to the correct system.runtime.serialization and I could use the [serializable] attribute with no problems.
Have I missed something?
Thanks
Amit
In general I'd recommend avoiding trying to use the SerializableAttribute in portable code. That type of serialization is basically not portable. However, if you really need to do it, that attribute is actually treated specially and is represented by a bit on the type as opposed to a normal attribute. So if you define your own attribute with the same name and namespace in a PCL, the compiler will emit the bit and everything may just work like you need it to.
Related
So i have a table which lists some appointments. These appointments belong to an event. The goal here is to list all the appointments and get the information of the event that they belong to.
So far everything works fine until i try to get the information of the event. I get an object which looks like this:
Now if i use something like this : {appointment.event.title} it will give back NULL.
That means that it doesnt access the properties. In TYPO3 v8 it works perfectly, but not in TYPO3 v9.
If i activate the <f:debug>{appointment}</f:debug> and get the whole object as debugged, then this {appointment.event.title} works! I can get the title.
The question now is what have changed since TYPO3 8 and can not access these properties anymore and how can i regain access?
In use: TYPO3 v9
Mode: Composer
Best regards,
I found the solution to my problem.
Thanks to #Claus Due i visited my Model to see if the getters und setters are there. They were there BUT before my getter, the #lazy parameter was present. After i removed, everything worked as it should.
Thank you!
Probably one of the following is true:
You forgot to add a getter method for the property you try to access and you are confusing the output of f:debug with what is actually gettable from the object. The debug ViewHelper outputs also protected properties.
You constructed the model object with __call or __get so you are affected by https://github.com/TYPO3/Fluid/pull/438 which is solved but not yet released (current Fluid version is 2.6.0, patch will be included in next version).
You don't say which TYPO3 version you use, nor if you are using composer, so it's hard to tell if your versions of Fluid are the same - they should be, since both TYPO3 v8 and TYPO3 v9 use the same external Fluid library.
The solution in either case is to add proper getter methods to your domain model object and always remember that the output of f:debug does not 100% correspond to what you can actually access: f:debug will for example not show virtual getter methods that don't have a property associated with it.
The generated designer.cs properties are private by default (at least without manual tweaking of generated code). This makes coding against something like a UITableViewCell feel much different than if I were doing this in Objective-C.
The popular way in the case of UIxxxViewCells, at least from what I can tell, is for the UIxxxViewDataSource to populate the IBOutlet properties, and that the cell should only be responsible for anything related to drawing/rendering the view.
With Xamarin.iOS, we are unable to access these properties from the data source, and instead are required to provide additional setter methods to populate the cell. In this way, the cell is responsible for setting it's own properties.
Is this just "The .NET way" of doing things?
It's so that we don't break encapsulation by default.
The outlets belong to the object they're on, it should be able to choose whether they're able to be modified from the outside. The fact that they're properties is an implementation detail of the Xamarin.iOS outlets system - you should think of them as private fields.
If you wish to expose them, you can create properties that do so - preferably read-only.
It was probably done that way because that's how the other GUI designers in MonoDevelop worked at the time (still do). Auto-generated bindings to the native controls used by the user-designed control for toolkits like Gtk# are also created as private.
I'm not sure if other UI designers for .NET work (I've never used Visual Studio to develop GUI apps using Windows.Forms or WPF).
Feel free to file a feature request on https://bugzilla.xamarin.com to make them public - I'll gladly implement it, I think it probably makes more sense for them to be public. I haven't changed it mostly because no one has expressed that they wanted it be any other way.
I tried the simpledroid with INotifyPropertyChanged and ICommand successfully.
I want to do the same with monotouch and xib designer,but without TouchDialog. Is there a way to implement without inheriting from mvx class as in monodroid?
Is it possible to do the same with MonoMac without Dialog as Portable Library in MonoMac or XaMac in supported now?
I understand what is your goal.
I think you want to start learning MvvmCross for Monotouch with a basic application example as you probably did with SimpleDroid. I tried to do the same without success.
Why ? Because SimpleDialogTouch is an "Advanced" example in my opinion. When you learn Monotouch, you use xib to design your view. But the sample tells you to learn a new tool "Monotouch Dialog" which is a way to display controls programmatically.
You get those errors because the sample implements the ViewModel only for Dialog and not for xib or classic binding.
Finally, you will have to dig into MvvmCross to build your own SimpleTouch implementation. The problem is that you don't have a lot of documentation, but Stuart is the best supporter for a beginner or you can switch to advanced Mvx features if you don't need to understand the underground of MvvmCross. There are a lot of samples, tutorials and posts to tweak Mvx.
Hope that helps.
Is there a way to implement without inheriting from mvx class as in monodroid?
I don't believe this is supported in the current source.
There is an effort underway to separate out the databinding code in MvvmCross so it can be used more easily with other frameworks - e.g. we might try porting MvvmLight across too. This is where my effort is currently focused.
If you need this now, then I think you could fairly easily create this simple binding yourself if you wanted to - but you'd have to take a look at what the SimpleDialog version does - it's not too big a code to copy across to the XIB version - https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Dialog.Touch/Simple/MvxSimpleTouchDialogViewController.cs
But... why not just implement a proper portable MvxViewModel instead?
Is it possible to do the same with MonoMac without Dialog as Portable Library in MonoMac or XaMac in supported now?
Portable libraries are not supported in any release from Xamarin yet - there is an unofficial installer that Jeff very kindly provided - but it's not a release...
For MvvmCross MonoMac/XaMac support, there is one non-PCL version from #deapsquatter around, but I don't believe this has data-binding yet.
I will be working on a PCL and data-binding release for MonoMac or XaMac - but it's on a spare time basis - no-one's come forward with a customer project to fund that work yet. If you or anyone wants to assist with this port, then you are very welcome... but it will be quite technical work - there are changes I intend to make 'under the covers' - so the easiest place for others to help will probably be in later work - adding more views, more bindings, doing QA, making samples, etc.
Note: "Simple" bindings are not the future for MvvmCross and may get dropped from a future release. However, this will only happen after I've separated out the Binding code so that it can be used with other libraries - the first of which will probably be a simple binding example.
I personally don't see much difference or advantage in using these so-called Simple bindings... but maybe I'm missing something...
I have two c# projects within a solution.
The first project is a winforms project with several classes and is called QuantumGUI. The second project is a class library project with several classes and is called QuantumDAL.
My objective is from a class in QuantumDAL to access and set variables in a QuantumGUI class or and in Form.cs.
I have tried adding a reference to QuantumGUI in my QuantumDAL project but received the following error: “A Reference to ‘QuantumGUI’ could not be added. Adding the project as a reference would cause a circular dependency”.
I received a similar error message trying to add Project Dependencies. When you think about it, the error message makes sense.
I’ve tried other, what I consider possible ways of doing this but came up empty. I believe there must be a clever way of getting this done.
If I’m going about this in a wrong way, is there a way to have a “global” class that can be accessed by code in both projects?
Thank you for taking the time to look at this.
There are two problems with what you're trying to do:
First, as the IDE is warning you, you're about to create a circular dependency. This means that the compiler would need to build project A before it can build project B, but it would need to build project B before it can build project A. Neither project can go "first".
The second problem is that your WinForms project is most likely an executable, and you cannot add references to *.exe files via the IDE. You can add those references via the command-line, but the fact that Visual Studio is trying to stop you from doing it should be a red flag that it's a really bad idea.
The correct way to do what you want is to refactor the common classes into a third class library that you reference from both other projects. If needed, you can wire up events (in particular, look at the INotifyPropertyChanged interface and its event) that notify interested observer objects when things change.
I have a custom control which needs to configure a MultiBinding in code, which requires a IMultiValueConverter. Is it good practice to use FrameworkElement.FindResource and require the Converter be definied as a resource or should I instanciate the converter in code?
I could have this in the theme Resource such that it is always there, but this seems a bit prone to mistake.
I don't follow your question, but maybe I can help anyways.
It usually just boils down to whether the converter makes sense outside the scope of your control. If not, declare it in your control. If it does, why does it? Should you perhaps be exposing properties on your control rather than the converter itself?
As for how you create it, you might want to check out this post that helps to keep your XAML cleaner.