Programming
Xml parsing and serialization for Mac OS X and iPhone OS
Apple provides the NSArchiver and NSUnachriver for object serialization / deserialization, but this can not handle any custom xml schema. So filling an object structure with the data of any custom xml schema has to be made manually. Since the iPhone developer community is rapidly growing, a lot of newbie programmer are despairing to deal with the available xml parsing possibilities.
The iPhone SDK only provides NSXmlParser for xml parsing, which is more useful to read certain parts of an xml file, than filling a whole object structure, which really is a pain.
The other possibility is the famous libxml library, which is written in ANSI C - not easy to use for someone who starts programming with objective-c and never learned proper C before. Event there are a lot of wrappers available, dealing with xml can be a pain for newbies.
And here my idea takes place. An XmlSerializer library which fills an object structure automatically could makes it a lot easier and increase the app quality for many programmers. My Idea should work like this:
The xml file:
<Test name="Michael" uid="28">
<Adress street="AlphaBetaGammastrasse 1" city="Zürich" postCode="8000" />
<Hobbies>
<Hobby describtion="blabla"/>
<Hobby describtion="blupblup"/>
</Hobbies>
</Test>
The business objects:
@interface Test : NSObject {
NSString *name;
Adress *adress;
NSArray *hobbies;
int uid;
}
@property (nonatomic, copy) NSString *name;
@property (nonatomic, retain) Adress *adress;
@property (nonatomic, retain) NSArray *hobbies;
@property (nonatomic, readwrite) int uid;
@end
@interface Adress : NSObject {
NSString *street;
NSString *city;
int postCode;
}
@property (nonatomic, copy) NSString *street;
@property (nonatomic, copy) NSString *city;
@property (nonatomic, readwrite) int postCode;
@end
How the xml serializer should work:
XMLSerializer *serializer = [[XMLSerializer alloc] init]; NSData *data = [NSData dataWithContentsOfFile:@"~/Documents/Test.xml"]; Test *test = [serializer deserializeWithData:data];
So I started a project for this idea. If you are interested in, the project can be found here. If you would like to join the project, so don’t hesitate to use the provided mailing list and ask for access.
NUndoManager project started
Since I miss the amazing undo manager from Apples Cocoa Framework, I started to implement my own version of an undo manager, using the same recording techniques.
The so called NUndoManager is the first .NET 3.5 undo manager, recording lambda expressions of methods reverting the state of an object. Additionally NUndoManager groups single operations for undoing at once. Reverted undo operations are automatically to the redo stack.
The project is hosted here. Have a look or join the project if you want to add your own ideas.
Model view presenter - make your live easier
The MVC (Model View Controller) patter is a well known object pattern for GUI abstraction, which is taught on every it school. But many programing language don’t support the programmer to use this pattern from scratch.
For example Java, or C# .NET are based on a inheritance topology, the IDE’s create subclasses of the GUI components, resulting in huge source files, which are mixed up with everything. Not to mention that there is no compatibility to other GUI components, e.g. ASP .NET.
Apple with it’s Objective-C / Cocoa framework made a good step in the right direction, the programmer is forced to use the MVC pattern, since the GUI is described in so called NIB files. A controller class contains the code. The NIB file can theoretically be changed without changing the controller.
Also .NET 3.5 has a good answer to this technology, the windows presentation foundation. The GUI is described in XAML files, which are linked to classes. The XAML file could also be exchanged without changing the source code.
These technologies are based on the MVC patter, which still has a string connection between view and model. Further the controller has direct references to the controls within the view. If we want to change a windows forms view with a ASP .NET view, or change the model, the MVL pattern is not flexible enough. This is where the MVP pattern starts to unfold its strength.
The MVP, or more precisely the passive model view pattern is based on three simple interfaces; Model, View and Presenter. View and model are independent entities, only the presenter links the three parts together.
Passive Model View Presenter pattern
Compared to the MVC pattern, the presenter has no direct connection to the GUI controls of the view and the view does not know the model.
The presenter can observe the view and the model, if any changes happens within the model, the presenter gets notified and tells the view what to do. The same procedure happens, if any user interaction happens on the view; The presenter gets notified and has to handle the interaction.
In this case, we can easy implement the view in ASP .NET, Windows Forms, WPF etc. and run it with the same model and presenter.
In some cases, we need a container view, which can maintain any sub views. For this, we extend the passive view pattern with a sub view. The presenter of the container only knows the presenter of the sub view. Sub views are added by adding the presenter of the sub view to the presenter of the container view, model and view are not referenced by the container view presenter.
Since the container view needs no know the sub view, the presenter forwards the sub view to its own view. With this MVP pattern and IoC (Inversion of Control) it’s also possible to use different technologies to implement the views with only one restriction: All views need to be compatible among each other.
MVP - Sub View
The most nice advantage at all is, that we can use dependency injection to create our object structure. To describe this technology would be beyond the scope of this article, but I can provide you some links:
How to check whether a class implements an interface
If we work with objects, it is not difficult to determine if a class implements an interface. This can be done with the is keyword.
But it gets difficult if we work with reflection. The type object of a class, contains a method called IsSubclassOf, but if we try to use it with an interface it returns false in any case and if we try to get all implemented interfaces and search the one we need, we’ll have to much work with this simple issue.
So how can we do this in a very easy way? I found the answer here. To shorten this long description, I’ll give you the answer right here:
typeof(IFoo).IsAssignableFrom(bar.GetType()); typeof(IFoo).IsAssignableFrom(typeof(BarClass));
The method IsAssignableFrom checks whether the type can be assigned from another. It takes a type objects as an argument an returns true if the type can be assigned.
Debbuging trick for Xcode
If you make an error which throws an exception, its sometimes quite hard to trance the error. Usually you have to set a breakpoint and step thru the code to find the line which throws the exception.
Woudn’t it be better, if the debugger stops automatically at the line of code, which throws the exception? I say yes, such things can make life easier and it is possible, since Xcode provides a feature called symbolic breakpoints.
To achieve this behaviour go to Build/Manage breakpoints/Add symbolic breakpoint and enter objc_exception_throw.
Now create a programmatical error in your code (e.g. try to get an object in a NSArray with a non existing index) and start the debugger (Apple + Y). The debugger will stop exactly on the line of code, where the exception has been thrown.
Check nullable types
C# provides a feature for object-relationship mapping. Since a date time field on the database can be empty but the DateTime type in C# can not be set to null, there is a solution called nullable types.
The syntax for is:
DateTime? date;
The problem is, the type of this object is not DateTime, so how it’s possible to check a nullable type?
It’s quite easy since all nullable types are of the type Nullable<>. To compare the previous variable date you can use following code:
date.GetType() == typeof(Nullable)
JStringLocalizer 1.0.b1 released
I’m glad to announce the release of the JStringLocalizer library version 1.0.b1. The beta version contains only the basics of the planned features, and is hardly tested. But so fare it should work, if you find some bugs, please let me know, I’ll fix them as soon as possible.
Release notes 1.0.b1:
- Localized XML files based on number tags (id).
- Debug mode (Sets an ‘!’ in front of each string to mark the already localized strings)
- Tag information (Sets the string tag after the string to see the localization tag information on the running system.)
Planned for version 1.0.b2
- Swing localizer (Should localize every component on a frame)
- JAR / ZIP resource file loading
License:
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, o any later version. This library is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.
Download:
JStringLocalizer project started
I started a small java project for the localization of java applications. The localized strings are stored in a XML file where every string has its unique identifier, called language tag. For every addition language you can add a translated XML file.
The localizer will have at least followeing features:
- Debug mode (It will be possible to switch in a debug mode to see which strings are localized.)
- Tag information (You can switch on the identifiers for viewing these tags directly within the application.)
- SWING Localizer (Localizes directly the swing elements of the application.)
- Resource files directory vs. resource jar loading.
In one or two days I will release a first version, testers are very welcome.
Interfaces with explicit methods
Have you already been in a situation, where you are forced to extend a class and can not inherit from another class anymore, but you would like to make a proper structure? Usually interfaces are used in this situations, but its quite boring to implement it twice or three times exactly in the same way. Since .NET 3.5 there is a solution for this problem - Extension Methods.
Lets have a look on this solution. First you make the interface:
pubic interface IFoo
{
...
}
Then you create the extension method:
pubic static class IFooExtension
{
public static void DoSomething(this IFoo foo)
{
...
}
}
Next you create an implementation of the interface:
pubic class Foo : IFoo
{
...
}
And finally, you can use it:
Foo foo = new Foo(); foo.DoSomething();