Looking for cross platform development/framework feedback
-
(I have put various products in bold. If ANYONE has extensive experience with any of these, I'd be interested in comments on your experiences.) First, some background: I was hired to rewrite a RealBasic application. Vastly over-simplified, this is a vector drawing program which supports our cutting device and which must run on Windows and OSX. The previous job holder had decided to use C# and had written some code and did a small test with Xamarin, but hadn't gotten very far and apparently was running into problems, though since he left before I arrived, I'm not clear on what those problems were. I decided to use Qt and having been making good progress doing so. Yesterday, I was told that the higher-ups have decided that a "lite" version for tablets, especially iPad, was my new priority. I immediately started doing some research and making calls. This is an extension of that. I am looking for real world experiences, not advice based on what someone may have read or Googled. I have narrowed things down to the following choices: 1) Continue with Qt. Pros: native C++, solid, I can do a lot of development on Windows, iOS & Android support are being added. Cons: iOS & Android support are being added and thus feedback on iOS/Android capability, performance, issues, etc. is limited, runtimes are large. 2) Switch back to C# and use Xamarin. Pros: Xamarin has a good reputation. I can do a lot of development on Windows. C# has some nice things about it. Cons: performance questions, look & feel issues, previous developer was having problems. C# has some nasty things about it--I'm quite adept at it, but still dislike the non-determinism, performance issues at critical points and how often I end up P/Invoking. Mono has gotten pretty good, but is still limited. 3) One developer suggested Unity, but it's way overkill for what we need--it's very game oriented--and while it handles some of our display issues, it doesn't help much below that. 4) Go completely native. The developer from #3, who's written games for iOS and Android suggested this. Pros: best speed, look and feel, app can be more fully optimized for the platform. Cons: portability issues may cause huge opportunity costs if sales justify going to Android. Requires me to even more "jack-of-all-trades, master of none." 5) A combination of the above (something the guy from #4 also suggested); writing as much code as possible in a common library with a shim layer (like QtCore) underneath and completely native
I don't have any experience in any of these, but I stopped by hoping to get some insight for a project that will be going mobile in the spring and will need to be on iOS and Android at a minimum. I noticed you left out PhoneGap which seems to be one of the heavy hitters in cross platform mobile development.
-
(I have put various products in bold. If ANYONE has extensive experience with any of these, I'd be interested in comments on your experiences.) First, some background: I was hired to rewrite a RealBasic application. Vastly over-simplified, this is a vector drawing program which supports our cutting device and which must run on Windows and OSX. The previous job holder had decided to use C# and had written some code and did a small test with Xamarin, but hadn't gotten very far and apparently was running into problems, though since he left before I arrived, I'm not clear on what those problems were. I decided to use Qt and having been making good progress doing so. Yesterday, I was told that the higher-ups have decided that a "lite" version for tablets, especially iPad, was my new priority. I immediately started doing some research and making calls. This is an extension of that. I am looking for real world experiences, not advice based on what someone may have read or Googled. I have narrowed things down to the following choices: 1) Continue with Qt. Pros: native C++, solid, I can do a lot of development on Windows, iOS & Android support are being added. Cons: iOS & Android support are being added and thus feedback on iOS/Android capability, performance, issues, etc. is limited, runtimes are large. 2) Switch back to C# and use Xamarin. Pros: Xamarin has a good reputation. I can do a lot of development on Windows. C# has some nice things about it. Cons: performance questions, look & feel issues, previous developer was having problems. C# has some nasty things about it--I'm quite adept at it, but still dislike the non-determinism, performance issues at critical points and how often I end up P/Invoking. Mono has gotten pretty good, but is still limited. 3) One developer suggested Unity, but it's way overkill for what we need--it's very game oriented--and while it handles some of our display issues, it doesn't help much below that. 4) Go completely native. The developer from #3, who's written games for iOS and Android suggested this. Pros: best speed, look and feel, app can be more fully optimized for the platform. Cons: portability issues may cause huge opportunity costs if sales justify going to Android. Requires me to even more "jack-of-all-trades, master of none." 5) A combination of the above (something the guy from #4 also suggested); writing as much code as possible in a common library with a shim layer (like QtCore) underneath and completely native
You may look at corona-sdk[^]. I have not used it in over a year but is a great concept. Write everything in Lua and it gets compiled for most any mobile platform. Just make sure you can do what you need it too before buying it. (I ran into a few gotchas, mostly with device specific functions like GPS)
-
(I have put various products in bold. If ANYONE has extensive experience with any of these, I'd be interested in comments on your experiences.) First, some background: I was hired to rewrite a RealBasic application. Vastly over-simplified, this is a vector drawing program which supports our cutting device and which must run on Windows and OSX. The previous job holder had decided to use C# and had written some code and did a small test with Xamarin, but hadn't gotten very far and apparently was running into problems, though since he left before I arrived, I'm not clear on what those problems were. I decided to use Qt and having been making good progress doing so. Yesterday, I was told that the higher-ups have decided that a "lite" version for tablets, especially iPad, was my new priority. I immediately started doing some research and making calls. This is an extension of that. I am looking for real world experiences, not advice based on what someone may have read or Googled. I have narrowed things down to the following choices: 1) Continue with Qt. Pros: native C++, solid, I can do a lot of development on Windows, iOS & Android support are being added. Cons: iOS & Android support are being added and thus feedback on iOS/Android capability, performance, issues, etc. is limited, runtimes are large. 2) Switch back to C# and use Xamarin. Pros: Xamarin has a good reputation. I can do a lot of development on Windows. C# has some nice things about it. Cons: performance questions, look & feel issues, previous developer was having problems. C# has some nasty things about it--I'm quite adept at it, but still dislike the non-determinism, performance issues at critical points and how often I end up P/Invoking. Mono has gotten pretty good, but is still limited. 3) One developer suggested Unity, but it's way overkill for what we need--it's very game oriented--and while it handles some of our display issues, it doesn't help much below that. 4) Go completely native. The developer from #3, who's written games for iOS and Android suggested this. Pros: best speed, look and feel, app can be more fully optimized for the platform. Cons: portability issues may cause huge opportunity costs if sales justify going to Android. Requires me to even more "jack-of-all-trades, master of none." 5) A combination of the above (something the guy from #4 also suggested); writing as much code as possible in a common library with a shim layer (like QtCore) underneath and completely native
I'm not overly experienced, by any means, but I've dabbled with native and cross platform. RedGate makes a great product (I have NO association with the company) called Nomad for Visual Studio ([^]). It's a cross product/platform tool that plugs into Visual Studio. I used it enough to build an app that ran on both on an iOS and Android device, and queried web services via JavaScript. It was slick, stable, and I spent all my time learning HTML5 and dusting of JavaScript. Our company has decided to go native, but I'm not sure I agree. Yes, we use RESTful services, and yes, we're sharing simple JSON data packages from the back end, so the UI is very much able to be platform specific. So now I'm building a native Android prototype. Yes, as a C# developer Java is an easier transition, but the native stack is unique. I've had to learn about saving login information/session states when rotating screens, the uniqueness of binding to a ListAdapter, and the caveats that are the platform. It's fun, but I keep thinking that it's a blank slate the day they ask for my prototype for iOS. Yes, the business logic is in the back end, but the UI isn't light, small or a trivial task, let alone if you know you'll build and maintain at least two stacks. (We will need to support Surface tablets too, so we know we'll need three UI teams eventually.) BUT - weigh a couple of things - can you/your company afford to have an iOS team and an Android team building the same UI for a given product? Yes, users prefer native Android controls/look and feel, as do Apple users, but if you can't afford both teams, then having a cross platform product that you can sell to either consumer is more valuable (to me) than native. Also weigh how much of your consumption will depend upon the features on the device; if you're not interested in geolocation, snapping photos, or maybe don't have a need to get to native services, cross platform is a stronger option. In our case, we're very device centric now, using the camera, the GPS, the accelerometers, etc. In theory you can get there with PhoneGap, but it's a weight that must be measured. Finally, consider your audience and your application suite. My company has a large suite of products and product lines. Each app we release for the new mobile work (because we're a bit playing catch-up) has to be a quality, top notch, well-performing product. We can afford to dribble out a product within a suite at a time, one that lends itself to mobi
-
(I have put various products in bold. If ANYONE has extensive experience with any of these, I'd be interested in comments on your experiences.) First, some background: I was hired to rewrite a RealBasic application. Vastly over-simplified, this is a vector drawing program which supports our cutting device and which must run on Windows and OSX. The previous job holder had decided to use C# and had written some code and did a small test with Xamarin, but hadn't gotten very far and apparently was running into problems, though since he left before I arrived, I'm not clear on what those problems were. I decided to use Qt and having been making good progress doing so. Yesterday, I was told that the higher-ups have decided that a "lite" version for tablets, especially iPad, was my new priority. I immediately started doing some research and making calls. This is an extension of that. I am looking for real world experiences, not advice based on what someone may have read or Googled. I have narrowed things down to the following choices: 1) Continue with Qt. Pros: native C++, solid, I can do a lot of development on Windows, iOS & Android support are being added. Cons: iOS & Android support are being added and thus feedback on iOS/Android capability, performance, issues, etc. is limited, runtimes are large. 2) Switch back to C# and use Xamarin. Pros: Xamarin has a good reputation. I can do a lot of development on Windows. C# has some nice things about it. Cons: performance questions, look & feel issues, previous developer was having problems. C# has some nasty things about it--I'm quite adept at it, but still dislike the non-determinism, performance issues at critical points and how often I end up P/Invoking. Mono has gotten pretty good, but is still limited. 3) One developer suggested Unity, but it's way overkill for what we need--it's very game oriented--and while it handles some of our display issues, it doesn't help much below that. 4) Go completely native. The developer from #3, who's written games for iOS and Android suggested this. Pros: best speed, look and feel, app can be more fully optimized for the platform. Cons: portability issues may cause huge opportunity costs if sales justify going to Android. Requires me to even more "jack-of-all-trades, master of none." 5) A combination of the above (something the guy from #4 also suggested); writing as much code as possible in a common library with a shim layer (like QtCore) underneath and completely native
From tomorrow's mobile newsletter, perhaps this can help? Review: Mobile Web development frameworks face off[^]
-------------- TTFN - Kent
-
I'm not overly experienced, by any means, but I've dabbled with native and cross platform. RedGate makes a great product (I have NO association with the company) called Nomad for Visual Studio ([^]). It's a cross product/platform tool that plugs into Visual Studio. I used it enough to build an app that ran on both on an iOS and Android device, and queried web services via JavaScript. It was slick, stable, and I spent all my time learning HTML5 and dusting of JavaScript. Our company has decided to go native, but I'm not sure I agree. Yes, we use RESTful services, and yes, we're sharing simple JSON data packages from the back end, so the UI is very much able to be platform specific. So now I'm building a native Android prototype. Yes, as a C# developer Java is an easier transition, but the native stack is unique. I've had to learn about saving login information/session states when rotating screens, the uniqueness of binding to a ListAdapter, and the caveats that are the platform. It's fun, but I keep thinking that it's a blank slate the day they ask for my prototype for iOS. Yes, the business logic is in the back end, but the UI isn't light, small or a trivial task, let alone if you know you'll build and maintain at least two stacks. (We will need to support Surface tablets too, so we know we'll need three UI teams eventually.) BUT - weigh a couple of things - can you/your company afford to have an iOS team and an Android team building the same UI for a given product? Yes, users prefer native Android controls/look and feel, as do Apple users, but if you can't afford both teams, then having a cross platform product that you can sell to either consumer is more valuable (to me) than native. Also weigh how much of your consumption will depend upon the features on the device; if you're not interested in geolocation, snapping photos, or maybe don't have a need to get to native services, cross platform is a stronger option. In our case, we're very device centric now, using the camera, the GPS, the accelerometers, etc. In theory you can get there with PhoneGap, but it's a weight that must be measured. Finally, consider your audience and your application suite. My company has a large suite of products and product lines. Each app we release for the new mobile work (because we're a bit playing catch-up) has to be a quality, top notch, well-performing product. We can afford to dribble out a product within a suite at a time, one that lends itself to mobi
Thank you for your detailed response. We actually aren't using HTML5 or Javascript at all. This is a client application for buying vector images from our store, manipulating them to some extent and transmitting them to a printer-like cutting device. In other words, this is not a data driven app and is heavily user-interactive. Since I posted my original comment, I've eliminated Xamarin for several reasons and am zeroing in on Qt and DragonFireSDK. (As an FYI, to check the viability of going back to C#, I ported a section of completed code from Qt. To my surprise, it ran twice as fast as the C++ version. I scratched my head and then realized that I'd been writing files using an ACID type algorithm to prevent data loss/corruption if power was lost. However, in the specific case I was testing, I didn't really need to be doing this since I'd changed how I was enforcing data integrity [it became an all or nothing thing at a higher level.] I made the change and the C++ version ran 4 times faster than the C# version, which is what I expected.)
-
You may look at corona-sdk[^]. I have not used it in over a year but is a great concept. Write everything in Lua and it gets compiled for most any mobile platform. Just make sure you can do what you need it too before buying it. (I ran into a few gotchas, mostly with device specific functions like GPS)
CoronaSDK looks intriguing. I'm a little concerned that it uses a scripting language. One of the reasons I was hired is that our desktop app was using something similar and doesn't scale well. However, were I doing game development, this would be at, or near, the top of my list!
-
From tomorrow's mobile newsletter, perhaps this can help? Review: Mobile Web development frameworks face off[^]
-------------- TTFN - Kent
Thanks for the link. Unfortunately, our app isn't very related to HTML5, javascript, JQuery, etc. except when we are downloading customer purchases. To put it in perspective, even .NET on desktop has proved to be an inadequate solution in some situations. Qt exacts a measurable performance cost, but much less so than other solutions.)
-
Thanks for the link. Unfortunately, our app isn't very related to HTML5, javascript, JQuery, etc. except when we are downloading customer purchases. To put it in perspective, even .NET on desktop has proved to be an inadequate solution in some situations. Qt exacts a measurable performance cost, but much less so than other solutions.)
Fair enough, sorry. Cross platform just means so many things to different people. I didn't know they had Qt on mobile platforms - great news, thank you!
-------------- TTFN - Kent
-
You may look at corona-sdk[^]. I have not used it in over a year but is a great concept. Write everything in Lua and it gets compiled for most any mobile platform. Just make sure you can do what you need it too before buying it. (I ran into a few gotchas, mostly with device specific functions like GPS)
good platform, let's see how it works :-D
Libero ganar con opciones binarias - www.libertad-financiera.com
-
(I have put various products in bold. If ANYONE has extensive experience with any of these, I'd be interested in comments on your experiences.) First, some background: I was hired to rewrite a RealBasic application. Vastly over-simplified, this is a vector drawing program which supports our cutting device and which must run on Windows and OSX. The previous job holder had decided to use C# and had written some code and did a small test with Xamarin, but hadn't gotten very far and apparently was running into problems, though since he left before I arrived, I'm not clear on what those problems were. I decided to use Qt and having been making good progress doing so. Yesterday, I was told that the higher-ups have decided that a "lite" version for tablets, especially iPad, was my new priority. I immediately started doing some research and making calls. This is an extension of that. I am looking for real world experiences, not advice based on what someone may have read or Googled. I have narrowed things down to the following choices: 1) Continue with Qt. Pros: native C++, solid, I can do a lot of development on Windows, iOS & Android support are being added. Cons: iOS & Android support are being added and thus feedback on iOS/Android capability, performance, issues, etc. is limited, runtimes are large. 2) Switch back to C# and use Xamarin. Pros: Xamarin has a good reputation. I can do a lot of development on Windows. C# has some nice things about it. Cons: performance questions, look & feel issues, previous developer was having problems. C# has some nasty things about it--I'm quite adept at it, but still dislike the non-determinism, performance issues at critical points and how often I end up P/Invoking. Mono has gotten pretty good, but is still limited. 3) One developer suggested Unity, but it's way overkill for what we need--it's very game oriented--and while it handles some of our display issues, it doesn't help much below that. 4) Go completely native. The developer from #3, who's written games for iOS and Android suggested this. Pros: best speed, look and feel, app can be more fully optimized for the platform. Cons: portability issues may cause huge opportunity costs if sales justify going to Android. Requires me to even more "jack-of-all-trades, master of none." 5) A combination of the above (something the guy from #4 also suggested); writing as much code as possible in a common library with a shim layer (like QtCore) underneath and completely native
Personally I found Codename One to be a better match for my needs than QT or Xamarin. QT has some nice capabilities and I would agree with you that I would pick it over Xamarin. This varies a lot with what you are trying to accomplish though e.g. I would not use Codename One for a game just like I wouldn't use Unity for an app that isn't a game... When comparing Codename One to QT there are several big advantages e.g. you don't need a Mac for iOS development, but surprisingly native integration is better... E.g one of our apps needed Google Maps support and we were sure we'd need to go native with QT or fully native. Turns out QT doesn't support native Google Maps (or didn't at the time) and Codename One had "ready made" integration that worked on iOS & Android. To be fair the Codename One integration had some issues but we got it to work eventually.