My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
I'm new to objective-c & osx architecture. I started playing with building a framework and then using it. I followed this great tutorial.
During the tutorial, I had to set the framework's target's Dynamic Library Install Name to #rpath/MyFramework.framework/Versions/A/MyFramework. My understanding is that #rpath will expand to the loader's (consumer's) run-path search paths.
It seems as if the responsibility of loading the framework is split between the framework author and the consumer author. Could someone please explain why the author of the framework needs to be concerned with the consumer's run-path search path? For example, if the framework-author set the Dynamic Library Install Name to point to some random directory (instead of #rpath) how would the client be able to consume the framework?
Thanks in advance.
It depends a lot on how the framework is being used. And it's important to remember that the framework construct has existed for a long time on the platform.
For a system framework, such as the ones that Apple creates, you're going to be quite happy that they keep the frameworks in a known location. In those cases, the paths that they use are fixed for the OS, and it guarantees that you don't accidentally load the wrong one. Further, as indicated in the Framework documentation, these frameworks are loaded only once on the machine, regardless of how many times they are used (see Apple:What Are Frameworks) . The benefit here is performance and it is for both the code and the resources in many cases.
Due to the recent move to randomize framework locations,and Apple's comments in the release notes that "Mountain Lion randomly relocates the kernel, kexts, and system frameworks at system boot," it certainly appears they're still sharing these resources, and thus still gaining from this benefit.
For embedded frameworks, the situation is a lot more tedious, and Apple has moved through a variety of methods over the years to make it easier to find frameworks wherever they may be. Due, again, to the shared nature, it would make sense for Applications which share common library requirements to share them on the machine, both for purposes of efficiency, and to make sure they're at the same version if they're sharing data. So, for example, if you have two separate apps that use the same framework to work with shared data, you might put the shared framework in /Library/Frameworks and have both apps explicitly look for that, making sure that some other (possibly older) version of the framework, that has been loaded by another App, is not used instead.
In the end, there's a lot of flexibility for the Framework producer and consumer the way that it currently works. It means that the developer can decide to share a framework, include a private copy of the framework, or even do both, depending upon whether the framework exists on the machine or not. However, the price for that flexibility is the complexity that we have today.
Another example of a reason you might not want to use #rpath specifically is for tightly-linked embedded frameworks (yes, people embed frameworks within other frameworks). In these cases, you don't know where the first framework is loaded, but you want to put the embedded framework inside of it, so that they stay together. In this case #loader_path is relative to the code that is loading it, so that your plug-in's framework can find its resources correctly.
In answer to your specific example about somebody setting the Dynamic Library Install Name
to a "random" location. In this case, you'd have to know that location. There might be many reasons for somebody doing this, such as wanting to discourage reuse by other programs, or because there are large resources within the framework that should only be installed in a known shared location.
I'm puzzling my head as to how some application appear to support the couple of Rotational Sensor APIs for Symbian, specifically the Sensor API and the Sensor Framework (both the 5th ed. and the 3rd ed. FP2 backport).
For example, I believe that Gravity will support rotation in N95 and also newer models from the same binary (could be wrong there...).
If I use the Sensor Framework then my app will not install on an N95 (it gives me a System Error -1), whereas if I use the Sensor API (RRSensor) then it will only install on an N95 and no other phones. This is most likely due to the available libraries on those devices.
I am trying to find some way of abstracting things such that I can use exactly the same binary for all devices. The only alternative I can see is trying to use ECOM plugins and then installing the relevant library using conditionals in my PKG file.
Does anyone know of a better/easier way?
If you need to use different APIs, I suggest making multiple DLLs that implement the same interface and selectively install them to device depending on device ID. SIS files allow that.
I'm working as a software engineer for a company. We are going to apply some software engineering standards in our development process. We need a tool which provides a repository for our peripheral products (functions, classes, libraries, ...) which is created during software development process for later use. The tool should provide some functionalities (e.g Name of the component, it's functionality, withing which projects it is used?, author, publication date, list of known bugs, user rating, comment, ...) and it's better to have a web-based interface. Does anybody know such a software?
You should check out FogBugz. Its a great project management tool which has recently released Kiln which is source control you can integrate with your projects.
A cheaper alternative is to look at something like XP-Dev.
In my experience, such a tool doesn't exist because the problem is solved differently. Companies typically use component frameworks, whether their own or 3rd party, and develop new components that conform to the component standard from their framework.
Each project then depends on the framework rather than on specific versions of specific components. This also resolves interdependencies and all related version compatibility issues.
Component framework is typically documented somewhere by its vendor and newly created components can be added to your company's wiki, such as mediaWiki.
Alternatively, the company may need some knowledge management. See the introductory videos from kbPublisher. kbPublisher is an OpenSource Knowledge Base which may be even more suitable than a groupware like mediaWiki. The free version of kbPublisher can be downloaded here.
Note each project should have a feature which displays the framework version number and configuration, as needed by staff. This way, when you are targeting a particular client, the system can be identified remotely.
Open source tools like GIT or SVN may provide source code management however they may lack in the functions you are asking particularly bugs or ratings. There are also many paid tools available in the market which not only provides source code management but also management and integrations over projects. You may explore:
TFS https://en.wikipedia.org/wiki/Team_Foundation_Server
Rational Clear Case http://www-03.ibm.com/software/products/en/clearcase
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have questions on true cross platform development and if it is possible to use ONE platform to develop software.
I have a few applications that I write that work on OS X, Windows and Linux. They all use native platform toolkits with some shared source across platforms. I have to boot to each platform, checkout, compile, etc.
I have in the past tried GUI toolkits like QT (I bought a commercial license for Win, mac, Linus, but very expensive and paying it year after year became hard). I have tried WxWidgets, development moves slow.
So what I am thinking about is there a way to run a single platform and cross compile for other platforms so I can build my products from a single platform.
I favor OS X, is there a way to write apps for OS X, Windows, Linux from OS X where I just need to test on each platform respectively. I have found information on cross compilers, stub compiling, etc, etc.
Does anyone have any thoughts? Is this even possible? Would someone make a killing creating such a beast?
In my company, we use the Mozilla Framework to develop cross platform dictionary products. These applications are based on the Gecko/Necko Browser and most of the development is done via Javascript, HTML, CSS, XSL, XUL,... Of course, our homebrew Search engine had to be cross compiled to the three platforms (with some other code which was first done in JS and then ported to moz' C++ for speed reasons).
In the end, we have a reasonnably cross-platform solution: Our developers mostly work like power web-developers (think client and server side at the same time). Because the Gecko is the same on the three platform, we know it will predictably look and behave the same way (except when there are bugs, but the platform is now quite mature on this point of view).
Our R&D knows how to port slow javascript code to rather quick portable C++ code (you do Mozilla code using the NSPR library, a cross-platform lib). Testing has always to be done on the three platform however, although with time and experience, you get to know what will break where (Font support, Audio support, Flash Support)...
Today, you should probably have a look at XULRunner which is really the Mozilla without any real browser interface (in 2002, we had to dismantle the Mozilla Browser to repaint it in our first product colour). Of course, it works well for simple applications but if you wish to make OpenGL, 3D Audio and other nifty things, XULRunner will appear too limited.
I believe Blizzard has some cross-platform framework for that kind of thing... :)
Good luck!
Pierre.
Trying to develop applications on a single platform that will be used on many platforms isn't a good approach. At best you'll make applications which feel alien to users of the platforms that you didn't develop for.
More likely, you'll run into subtle compatibility problems in areas which you never forsaw. Java is probably the best way to go if you want to go down this route. Cross compiling will lead to autogenerated code that will be a nightmare to debug and maintain.
Certainly, you may be able to use tools for porting in some cases, but I don't think that this is a problem that you can just provide an automated solution for in general.
Well, to be honest, the only guaranteed way to build an app to be cross platform in one go is to use Java, but it requires a rather large runtime to be installed first.
However, if that's not an option, I would recommend keeping an eye on recent developments in Qt - it is now available (or should be soon) under the LGPL, which presumably means you don't need to pay for it anymore. Using GCC with Qt, I've found, works perfectly when cross-compiling on different platforms, as long as you only use Qt's classes/code/objects and make sure that any non-Qt code you create or use is capable of being compiled cross-platform.
You don't mention any specific programming language (but I'm guessing C or C++ because of the GUI toolkits), so it's kinda hard to give a good answer to what you are actually asking.
If you want "true" cross platform, I would first consider if it is possible to solve your problem using a language that is less platform bound. Python, Java and plenty of others allow you to write on one platform, and run on many.
If you still want to use C/C++, GCC gives you the option of cross-compiling, and if you combine that with QT (which will soon be available under the LGPL) you should be able to get something working.
Java has tried to do the write once, run anywhere. It works well in some situations, but there are too many "unique" things in an OS. GCC provided the ability to cross-compile applications, but you run into the same sort of problems. The code will just have better performance. The RIA approach seems to work, but it doesn't feel like a native application.
Even using a cross platform GUI toolkit will not remove all your cross platform problems. There's more to an app than GUI, after all. Cross compiling will never be able to catch all the issues that a native build will catch, either. If you're going to support multiple platforms, you're going to have to at least test on each platform. But hopefully you can perform native builds with all warnings turned on, in addition to testing.
In the past few months, I found a few great videos exploring this topic of cross platform development. I hope you find them useful as well.
QTCreator
http://www.youtube.com/watch?v=aYiPvM7ZRHA&feature=channel
FlexBuilder
http://www.youtube.com/watch?v=_O_xDXRsh3Y&feature=channel
Mono / MonoDevelop
http://www.youtube.com/watch?v=U6VG_Z0aRek
I've personally had success using Silverlight / MacOS X
http://screencast.com/t/if8xenkt
RealBasic
http://www.youtube.com/watch?v=GWipoBeKSRk
For Cross Platform Development you can use Phone Gap, Appcelerator (Titanium), Corona... This all provides a framework based on JavaScript and finally able to run on different platforms. What I am using is Titanium for Mobile Development which allows us to develop applications with Native Codes.... (which is very good advantage). Phone Gap is giving a web app which is not native in general... This softwares are used for development of cross platform supports... with support on Windows, Linux and Mac OS.
Based upon my personal experience, I believe you should adopt Java: you will avoid many headaches.
You develop in whatever platform you like and you deploy in all other platforms with no need of compiling for each target platform, as you mentioned.
For example, I develop under linux, I hit "compile" only once and the resulting file is ready to be run anywhere (windows, mac, solaris, z/OS, you name it). A double click will run it on any platform (Java runtime must me installed, but most users have it installed already and if not, it's a matter of downloading, installing, "Next>", "Next>", "OK").
If you choose the "Java Web Start" deployment method, it gets even easier: the user just clicks the launch button on a webpage and the application runs (if the proper JVM is installed according to what specified in the JNLP descriptor) or the user gets redirected to the Java download page (if no suitable JVM is found).
GUI development (with Swing toolkit) is easy and powerful, especially if you use the right tool (i.e. Netbeans IDE).