Hi guys,
Don’t you think it’s time to consider to merge your great open source libraries into a single repository ?
macoslib is the absolute reference for Mac OS.
So, let’s begin to build the one for iOS…
[quote=176771:@Martinho Dos Santos]Hi guys,
Don’t you think it’s time to consider to merge your great open source libraries into a single repository ?
macoslib is the absolute reference for Mac OS.
So, let’s begin to build the one for iOS…[/quote]
MacOSLib has been around for a great deal longer.
Xojo iOS is very young and far from perfectly stable. A merge of libraries is premature, until it is stable.
Besides, each one of our iOS declare gurus needs to work on his own project to enjoy the discovery, and his achievements are the rewards. We all benefit from a friendly competition.
Yes, keep them apart!
Please don’t make a general library!
From what I see, the libraries in development use a multitude of different approaches, each with its own benefits and drawbacks. So, as long as they don’t conflict with each other, there is some sense in building different ones. Just need one piece like location services? Insert one of Antonio’s snippets or a plug-in. Want full feature access? Take one of the libraries.
From my point of view, those working on libraries are vividly cooperating. I don’t mind someone taking something from my library to include in his, and I do look into the other libraries to get inspration and helpful hints. As they are all different in structure, we cannot exchange the code (or compile it into one) completely, but I would say it is indeed a very friendly, cooperating competition like Michel said.
There is one huge issue with having all these separate libraries. At the rate things are going, conflicts are going to arise that end users are not going to be able to resolve.
To avoid duplicating code, you really need to duplicate the iOS library hierarchy. If everyone creates their own NSObject class, there is a high potential for no ones libs to work together.
I think the most frequent problems will be those with conflicting global methods and constants. Hiding a constant like “UIKit” in a framework would mean a lot of typing, so laziness makes one put this global which the compiler won’t like when it finds several of them. Mabe we could establish a common global module that is shared between all those implementations. UIKit and the NSStringfrom/to Foundation calls come to mind.
About conflicting core objects: This would make snippets like Antontio’s impossible. But on the other hand, keeping track of ownership clearly needs inhertited class structures. As long as the libraries know what they created, they should be able to cooperate, but I wouldn’t know how to implement such a structure into the controls-on-demand idea behind Antonio’s code. But enforcing the user to install a complete lib when he just needs one addition Well, I’m think youre right: There will be situations when the user has alternatives but cannot use all at once. And Christian’s advice on using unqiue classnames is clearly a very good one.
I’d prefer an “official” Xojo library.
MacOSLib started when ? 2007 or so ? Xojo iOS was released only last January. Libraries created during beta and early release are showing some issues with the next release currently in Beta, mostly due to 64 bit.
Besides, as Ulrich pointed out, every developer has his own approach, and every library has it’s own advantages and possible bad sides.
Until the smoke clears in the nescent Xojo iOS world, I think it is a real asset to have different developers working on enriching that environment. Already, it has produced amazing results, and even a great commercial product.
I think Christian is right, it should not be too difficult to suffix methods names, or like Ulrich suggested, to come up with a common library.
Incidentally, common libraries are not immune fro possible issues : I recently discovered in the Windows Functionality Suite a plethora of SendMessage methods, with each different ways of calling the framework, that can cause conflicts.
Also, the example of MacOSLib and its HUGE set of modules that one has to dump all at once in a project has to compare with the possibility to pick and choose plugins in MBS, or simply use snippets.
I am not sure the existence of a centralized library would alleviate all possible conflicts. For the time being, I would rather see as many new controls and methods as possible, rather than a more limited unique source.