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
Our company is on the verge of picking between native Android/iPhone development and some cross-platform solution, specifically Marmalade SDK (former Airplay SDK).
We are a computer vision company, meaning we need low level access to the camera devices. Also, our applications are computationally expensive, meaning we tend to squeeze out every little bit of processing power available.
Our team has sufficient experience in both Objective-C and Java (or C) to provide platform specific solutions. However our main focus was always on C++, as such we would like to prevent fragmenting out team and rather work with a cross-platform solution.
Our biggest fear is that choosing Marmalade will either sacrifice processing speed (main concern) or severely increase development time by complicating low level access to camera frame buffer.
So my question is, besides the obvious, what are the advantages, but specifically limitations of Marmalade SDK for processor intensive video processing applications.
I have used Marmalade/Airplay for almost two years now in my indie game company. For me it's a win because I'm just one programmer, and I can do virtually all my work in Windows using MS Dev Studio (which is my favorite dev environment by far) and because it shields me from having to deal with a lot of the platform-specific details, especially with the various development tools, that could eat up a lot of the time I'd rather spend on game content.
Speed will not be an issue with Marmalade. Your C++ code runs natively. Also, access to camera and other functionality should not be much of an issue; it's either already provided or can be added using the extensions SDK, which is pretty straightforward to use.
Marmalade is a mature product and the company is pretty helpful in resolving issues quickly, even for indie developers that are using the product for free. In addition to the cross-platform-ness, it has some nice tools built in, such as a memory leak tracker, a logging system, graphics analysis tools, and others.
There are some downsides that I've experienced with Marmalade.
Even though in theory any API or third-party SDK is accessible through the extensions system, in practice the thing you need may not exist yet. As an example, a number of developers are currently struggling to get the analytics package Flurry integrated, and it's been a challenge for some. The situation is similar with lots of other third-party SDKs; they may be just a couple lines to integrate if you are doing Objective-C development, but can be more difficult via Marmalade.
Some things are less natural because of the cross-platform layer through which you operate. Some examples for me have been:
I've had trouble getting my splash screens (application start-up screens) to display properly in all screen sizes on both iOS and Android. And it's been hard to get them to show without some flickering, short black-out periods, or resizing of images as it transitions between the device load of the Marmalade app itself, and then Marmalade's step of loading your app code.
Marmalade imposes a very simple memory model, where you get a fixed heap up front, and all memory allocation is done through Marmalade. From the system's point of view the app just has and keeps a big block (or a few big blocks) of memory. This has some advantages, but I've had problems squaring this model with the iOS model of, for instance, receiving memory warnings and being expected to jettison any unnecessary resources. It appears to be a case where "one size fits all" ends up actually losing some key functionality.
You can use the extension manager and some other methods to show native UI elements, but integrating a significant amount of native-look-and-feel UI can be a challenge. So if your app is game-like and users can deal with non-standard buttons and so on, that's fine, but if you anticipate needing significant native UI, it is harder. [edit: Recent versions of Marmalade have added a native UI framework that lets you specify standard UI elements in a generic way and then implements then using the appropriate widgets for the device. I have not used this, but it looks fairly comprehensive.]
If you run into problems, it's often not clear whether it's a generic OS problem or a Marmalade problem, and it can be lonely trying to find help. For instance, I recently added in-app purchase to my game, on both iOS and Android. IAP is challenging, and even without an additional SDK layer there are lots of special cases to deal with. In my case, I had a situation where my app had been rejected by Apple for a small issue, and while it was in the rejected state my in-app purchase was also in a "rejected" state (even though there was nothing broken about the IAP itself; this is just a quirk of Apple's process). When I was trying to regression test the in-app purchase functionality (while I was submitting the fix for this non-in-app-purchase-related issue), the game was actually crashing, instead of getting an appropriate error result. I was able to determine that the crash wasn't in my game code, so it was either the OS (unlikely) or the Marmalade middle layer for handling the in-app purchase callbacks (which is what it turned out to be [update 11/28/2012: Marmalade has reportedly fixed this problem in a recent SDK update]).
So in a situation like that you can try going on Stack Overflow to get help, but really nobody is there to help you, so you are dependent on the Marmalade team to get back to you with an answer. As I say, they do a pretty good job of this, but there's no way it can compete with nearly instantaneous responses on Stack Overflow from the world-wide community of regular iOS programmers. So I'd say this last one is my biggest concern with using a system like Marmalade. It saves you time up front not having to come up to speed on the details of the various platform SDKs, but when you run into problems you are "at the mercy" of the Marmalade team (or friendly Marmalade community members) to get back to you with an answer. (Keep in mind here that I'm writing as a freebie indie developer who just gets standard priority for issue resolution. You can pay to get guaranteed quick resolution.) For me personally, it's been hard having to keep coming back to my producer and saying "I'm waiting for an answer from the Marmalade guys on this one."
(Another example of issue 3 is that until recently there was a problem with sound effects being delayed on certain Android devices. It was a Marmalade issue, and they did eventually resolve it, but it took a while, and there's basically nothing you can do in the meantime.)
Keep in mind that (as other responders have pointed out) even without Marmalade you can still have the bulk of your code base in C++ on either iOS or Android.
In spite of the long list of potential issues above, I am a fan of Marmalade, and I appreciate all the company has provided for me for free. The tool really shines when it comes to other platforms that you'd otherwise never bother with, such as (for me) bada or PlayBook. You really can deploy to a wide array of devices from the comfort of your PC and Developer Studio (or from a Mac with xcode, if you want to make your life a little harder ;). The simulator tool they have is great, and there have been only a small number of instances where I've had to debug on the device itself; in general if it works on the simulator it just works. IdeaWorks has taken on a huge challenge and they are doing a great job juggling all these features (i.e., basically every features ever offered on a mobile device) on all these platforms (i.e., all significant devices in existence, with the exception of Windows Phone 7 because it does not currently allow native code). It just comes with some caveats.
I am biased, being the CTO at Marmalade... but if your key requirements are (1) camera access and (2) the ability to "squeeze out every little bit of processing power available" then Marmalade is a great choice.
Marmalade compiles your C/C++ to native ARM (or x86) instructions... no transcoding, no virtual machines. It's very easy to bring across existing C/C++ code, nearly all the C/C++ standard libraries are supported, etc. And you can use ASM code within your project. Also, you can do all your development either on Windows or Mac, regardless of what platforms you deploy to (yes, you can even compile/test/deploy to iOS purely on Windws).
As far as I can tell you from ANDROID Development:
The Camera API from Android itself seems to be a little buggy (in example: before 2.1 there is no solution to get Camera shown in portrait-mode without scrambling the Images).
Another abstraction layer on top of that might be better (in terms of accessibility, features, whatever), or even more worse. What it does for shure: It steals resources, which may be needed for your own App.
Marmalade offers an excellent Native Extension framework
http://www.madewithmarmalade.com/marmalade/features/extensions-development-kit
WHich ultimately means that you can jump directly to a native implementation of any particular feature. You still keep the core benefits of cross platform development for your main app.
Also on android because marmalade makes use of the android NDK your c++ code for processing data will be running faster than the corresponding android Java code.
Im making games with Marmalade and the extensions and native code speed make me extremely confident of being able to deliver at least as well as a 'native' app.
I would use MoSync Android/iOS, but I would say that, since I work at MoSync.
But in all fairness I prefer the MoSync Camera API.
If you really want to squeeze out all the processing power out you should use ASM.
/Tony
Marmalade's not bad, I used it in 2013. Some bugs, some annoyances (fixed memory pools), but overall not a bad experience.
The only real disappointment is the lack of support for Linux. I cannot see how the Marmalade guys can support obscure platforms like Blackberry, but not Linux; it makes no sense. Maybe this will change as Steam OS (a Linux-based, gaming-centric platform) matures, though admittedly Steam OS doesn't bring a whole lot to the table outside of what other OSs bring, for now.
Related
All my life I've build my games and programs on top of prebuilt software, Unity,Unreal, Python etc, But I've never really learned how it's standardly done in the industry, ya engines are cool, but they also cause problems such as having limitations with what you can do, as well has having to work around bugs etc. But let's look at other software: MS Office, 7Zip, Evernote, Firefox, Youtube, Amazon Alexa app, Inkscape, Autodesk cad, Photoshop etc. These are just some random examples but they were NOT built in an engine yet manage to be cross-platform. What skills/languages are required to do that? To be clear I'm not asking for a miracle answer that can tell me everything I need to know, but I'm looking for a guide on the tools used to build things like that. Is it C++? Is it OpenGL? Am I still think too high up? I don't know much about it but are that the right direction? I've heard of things like electron but I think you could consider that more of an engine. I can't imagine these companies doing this at the binary level, I would think that would be absurd doing that for every program in such a day in age, also impossible for startups like Mozilla and Evernote to do as brand new companies without a large amount (if any) incoming revenue. In the end, I guess what I'm asking is, what is the industry standard when building cross-platform programs? What are the tools they tend to use? And what sources could I learn from to learn ore about this?
P.S. To be clear I understand things like Evernote, Youtube, Alexa App, etc have back-ends behind them, but I'm not talking about those, I primarily mean the front-end though I would think whatever the standard is would be capable of handling a back-end.
Ex-Middleware Game dev here. To make anything work on any given platform, at the lowest level you will have to start accessing the OS or hardware specific API's (So for example, on windows, CreateFile to open a file, or open() on linux). The C/C++ standard libraries build on top of those API's to provide a somewhat generic platform on which to build cross platform apps.
Realistically though, the C++ stdlib isn't overly helpful in this regard, mainly because things such as graphics, windowing APIs, etc; they are all outside of the remit of the stdlibs. Another big issue for us game devs w/r/t the C++ stdlibs on console, is that their behaviour tends to be targetted towards the 'general case', rather than the specific platform. Take for example the cmath functions. I am not, under any circumstances, going to be calling the extremely inefficient std::sin() implementation. std::sin is great in one regard - it handles denormal numbers, correctly identifies NAN/INF, and has a well described method of reporting errors.
In the games engine world, we tend to spend a lot of time upfront baking assets so that these INFs/NANs cannot make their way into the games computations ever. So handling of that stuff at runtime is a waste of time, so we usually write our own maths approximations (We aren't landing a man on the moon, we're just throwing some polys at the screen, so we usually don't need the accuracy provided by the stdlibs).
So how would a typical cross platform game be organised? You'd probably see a directory structure somewhat akin to this:
game/
platform/ //< contains all OS specific code (timers, mutexs, etc)
vpu/ //< wrappers over the SIMD instructions on the platform
maths/ //< fast versions of cmath + Vectors/Quats/Matrices/etc
graphics/ //< wrappers over the core graphics APIs
sound/ //< wrappers over the platform specific audio stuff
This is pretty much the 'platform' against which all other code is written against (in other words, we basically end up writing our own version of the C++ stdlib for each new platform). Whilst there is quite a lot of work involved in the above, it's usually reasonably straight forward to rewrite the entire code library when a new hardware platform comes along (e.g. Playstation 6, XBox 99, etc). Certainly that's less work than re-writing an entire game.
In some cases there are bits of that work that won't change (e.g. iOS and Android all use ARM CPUs, so the maths routines optimised for ARM NEON will be shared by both, as will the OpenGLES graphics routines).
With any luck, 99.99% of the games code will not need to be modified. With any luck - in many cases we aren't that lucky :( [Although its easier now than it was ten years ago!]
All to often (especially on console), towards the start of a games development you'll target your lovely abstracted core libraries, and all will be good. As you near the end of the project, you'll probably end up with a load of #ifdef XBOX defines that exploit specific performance gains of that specific hardware (we need to meet that 60fps goal, and we don't really care how tbh). In extreme cases you may find that a given platform needs so many platform specific optimisations (in say, the renderer) that it has effectively diverged into an entirely new library for that platform only.
Anyhow. This situation is a little different on PC and android - simply because the variety of hardware is significant (unlike say an XBOX, where they are all identical!). In those cases we will be writing code against an already abstracted API (e.g. OpenGL, OpenAL, D3D, etc), and we will have to insert a lot more runtime error checking than you would on console (for example, on console we may know we have 256Mb of ram. On Android it could be 32Mb, it could be 2Gb, who knows! It doesn't matter, we need to handle failures gracefully).
When it comes to desktop APPs, for windowing APIs, the vast majority of sane people just use QT now (possibly with OpenGL if they need 3D rendering).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am the only mobile developer in my job. Before I was hired, my currently boss was thinking on using Xamarin as their marketing says the words Shared code and native.
I consider myself an advanced Android developer since I've build large information systems. Right now I'm working on simple apps I could finish in a week, but Xamarin is giving me headache since its too buggy, and the reusable code is about 10% that could easily be copy/pasted into iOS, and despite the fact that you can share that 10% code, sometimes you still have to use compilation directives #if / #endif.
I mean, there is no really any advantage for me, since I already know both Java and Objective-C languages. I already have vast knowledge of SQLite and data storage with Core Dataon both iOS and Android SDK so that learning Xamarin will make it slower.
I have already tried to talk them into not going for Xamarin since its only a little code you can share, but they don't seem either to understand.
I need some good argument to convince them not to buy it, so I can do my job in a more productive and faster way. Thank you in advance.
Some good points from Lee Whitney's Blog: Why I Don’t Recommend Xamarin for Mobile Development:
App Overhead
Xamarin based apps have a built in overhead that makes them larger on
average. This affects download time and storage used on a device.
The minimum additional size is usually a few megabytes and can grow
proportionately as the code uses more of the APIs. This is due to the
way code from .NET assemblies is statically linked (as native code)
into apps as the assemblies are referenced. On Android there is also
an extra startup delay for apps for OS specific reasons. To
Xamarin’s credit this overhead used to be much greater and the company
has made great strides in reducing it. However, the impact on app
users is still measureable.
Limited Sharing of UI Code Across iOS and Android
User Interface development is not portable between iOS and Android.
This means APIs, event logic, widgets, and designers must be used and
coded differently for each platform. There are a few exceptions to
this for common, low level operations.
Xamarin would argue that trying to abstract UI APIs across very
different platforms can create unnecessary complexity or lead to a
poor user experience with an LCD (lowest common denominator) design.
They have a point here. Titanium tries to do this partially, and the
result has made many developers unhappy with the inconsistent or
unpredictable results. HTML5 apps are more successful at pulling off
this UI abstraction without forcing an LCD design, but they do not
have the native performance of Xamarin.
UI problems can be some of the most time consuming aspects of
developing mobile apps. Despite having a good justification, the
important takeaway is that for many mobile UI problems, Xamarin will
not save developers or designers time.
Limited Sharing of Code Outside of Xamarin
Xamarin does not allow creation of reusable components or modules
outside of it’s own environment. For example, code written in Xamarin
cannot be used in native or HTML5 apps. This means any code developed
by a team using Xamarin cannot be shared or reused with teams using
any other tooling for iOS and Android. How much this matters depends
on the situation, but the problem with development is we can’t predict
all of our situations. So it’s an uncomfortable limitation to have
right out of the gate.
Ecosystem and Community
This is something that is not really Xamarin’s fault. What company
has a mobile ecosystem that matches Apple, Google, or HTML5? However,
it matters. When developers are 10 times more likely to find results
when searching the web about an issue, it directly impacts
productivity. The ecosystem of available support, services, and 3rd
party components, and related tooling is, and will continue to be,
significantly smaller than for native or HTML5 based apps.
The Third Learning Curve
Some concepts and techniques require special knowledge specific to the
Xamarin environment. This effectively adds a third learning curve for
developers beyond programming language and native APIs. For example,
developers having to understand iOS reference counting to avoid
problems with Xamarin’s garbage collection
(Is this a bug in MonoTouch GC?).
Another example is data structures and generics working in subtly
different ways
(http://docs.xamarin.com/guides/ios/advanced_topics/limitations).
These are the types of issues that are hard to see before you actually
adopt a new platform, so they merit special consideration.
More Moving Parts
Xamarin introduces it’s own set of bugs that affect product quality
and developer productivity. The problem is not that Xamarin has a
bad product, but that adding any large or complex system to the app
toolchain comes with problems and bugs that do not exist in native
apps.
The historical record of these bugs can be reviewed using Xamarin’s
bug tracker (https://bugzilla.xamarin.com).
Yes, all software has bugs. The point is when you measure the
advantage of adding new tools; the disadvantage of new problems must
be factored in.
Summary
In the end we have to try and quantify the benefits of a development
abstraction like Xamarin over other abstractions, or over native
development. Is C# better than Objective-C? Yes, by far in my
opinion, but that’s only one factor. When you add everything up it
tips the scales away from Xamarin in favor of other approaches to
mobile development. As of 2013 (this stuff can change quickly) I tend
to choose a native code solution or an HTML5/Cordova solution. I like
both for different reasons and will try to explain some of the
decision factors in another article.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We would like to develop an application that runs on both iOS and Android. We cannot come to a decision however whether it is better to first create the application on one platform and once we are satisfied, replicate it on the other, or finalize UX decisions in the beginning and develop the platforms in parallel.
The application is simple and we have the resources for developing it. It is just a question of whether to develop the platforms sequentially or in parallel and if sequentially, then which platform to start with (again assuming resource allocation is not an issue).
As for me, developing both versions at the same time always means more time. You can have your design, workflow, architecture perfectly defined, but there'll always be changes during the development (not to say if there's an external client making decisions). If you're developing for both platforms in parallel, chances are that you will implement those changes twice, while if you first finish your app in one platform, you shouldn't find more unexpected surprises in the second one.
The next question then would be: which platform should I start from? I choose Android for two main reasons:
It's a lot easier to refactor code / project structure (at least for me) in eclipse than xcode.
I design the user interface keeping in mind the largest resolution (Android xxhdpi), then I cut my final png assets once using android resources naming conventions (which is more restrictive than ios), and run automated tasks for the rest of densities (xhdpi, hdpi, mdpi, iOS and iOS#2x)
Regarding cross-platform frameworks (i.e. phonegap), imho the effort will never be divided by two, and the user experience will never be close to the experience reached with a native application. Unless your app is extremely simple, I'd highly discourage these kind of frameworks.
We had the very same debate when we started developing the app we're working on.
First, I should say that if your app is simple enough (doesn't have too many heavy animations, 3D, etc), you might want to look at some multi-platform solutions:
http://mobiledevices.about.com/od/mobileappbasics/tp/Top-5-Tools-Multi-Platform-Mobile-App-Development.htm
I personally feel that multi-platform solutions are still too far behind native apps, but it might be suitable for some apps.
In the end, we decided to develop the infrastructure of our app on one platform (Android), and then start building the app on the other platform (iOS), once the strength and performance of the Android app's infrastructure was proven. When we developed the iOS app, the infrastructure from the Android app was copied.
There are several advantages to this:
After you finish designing the architecture of the app, you test it once on one platform. If the architecture failed to hold up, you don't need to start 2 projects from scratch - only one.
Once you develop the app once, at least the infrastructure, you've already gone through all the major hurdles of development. This will allow you to complete the development of the other platform with relative ease and speed.
Developing 2 projects simultaneously will probably result in significant differences in the way the code works in both platforms. While there will always be some differences, due to the large differences between the platforms, it's better to minimize the difference between the way the apps operate - this will make maintaining the apps in the future much easier. (Solutions to problems will be essentially the same - iOS & Android teams can copy their solutions off each other).
Developing simultaneously will probably be quicker, but riskier, and will cost more time when you need to maintain your app.
Hope this helps your decision making :)
That depends strongly how you develop the app. If you develop on multi-plattform, I would suggest to us a framework like phonegap: http://phonegap.com/ . With this approach your question disappears and you saved half of the effort.
If all resources are available and requirements are clear then you should go for parallel development because its not best practice to make any resource sit idle.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
So I have been working on a medium sized enterprise app for the iPhone that I may have to port to Android. I wrote the app using the native iOS SDK without any care for portability. I initially cringed at having to re-write the entire app in Java and maintaining two code bases, so I looked into some of the cross platform options.
I wrote a simple "hello world" in two cross platform applications and one using the native SDK just to get a feel for the performance and stability of each platform. This was by no means a completely exhaustive experiment, just quick and dirty test. I was surprised to find that PhoneGap and Appcelerator’s Titanium had a very noticeable startup time just to display "hello world". Additionally, both PhoneGap and Titanium crashed if I closed the application and then reopened it in rapid succession (30-40 rapid iterations). The Native app on the other had never had any problems.
Initially I thought I could live with the slower startup times because of the promise of one code base to rule them all. Then I ran into the following potential roadblocks:
Debugging support seems limited.
According to the phone gap wiki it is recommended that you debug (1) on your desktop (2) using a remote web inspector (3) printf debugging [are you kidding?] or (4) using weinre
Debugging for Titanium is slightly better but still lacks on device debugging support. There is an open request for on device debugging that is a year old so it may get fixed in the future.
Debugging may not be a problem on small projects with a few developers but it quickly becomes very important the larger the project gets and as more developers work on the same code base.
You still have to adjust the UI for each device.
This may or may not be a concern for some people but I would like our app to look like a native app and follow each platform's human interface guidelines. So I will still have duplicate code at the UI layer.
At this point given the fact that I have to have separate UI code for each device and the on-device debugging options are not as rich as a native app I don't see the savings that a cross platform development framework will give. I am thinking that the best route to go is to re-write my models in C and then I can share that code between Android (using the NDK) and iOS with each device having is own native UI.
So my question is, what experiences with cross platform mobile frameworks does anyone have? Are my fears of limited debugging and duplicated UI code unfounded? Please keep in mind I want to have an application that looks like a native app for each platform.
For those of you that have used a cross platform framework how large was the project? What problems did you run into? Would you use the framework again?
-Shane
I have used appcelerators titanium quite a bit. My general feeling is that the IOS section is very good but the android is still lacking, particularly in error messages, debugging isn't so bad as all you have to do is add a few print outs, but the issue being that 99% of the errors on android will be something like app crashed with nullPointerException with no hint as to where because its coming from the underlying java, it can be tricky to say the least.
However I will say the UI stuff is not an issue, titanium takes control of automatically scaling the apps to different device screens (when a setting is turned on - should look into this came in with 1.7). So generally the only issues you will have is device specific things, like having a right nav button in IOS, there is no android equivalent so you have to code something special for that, which is understandable given there 2 different platforms.
I'm not sure what I would do given the IOS is already fully developed, people generally go to this to avoid a learning curve for both platforms and to save time with keeping the same code base, Not sure how much benefit you will get out of this. Appcelerator is good but there are bugs in controls, it will be slower and it will take time to learn but it does have benefits.
I personally wouldn't use phonegap as I don't like the idea of it basically being a webview wrapper and I've had enough browser based issues on desktops to last me a lifetime.
In the recent weeks I have been busy with the issue of cross-platform development. That starts with the problem that I had the feeding to write a wrapper for the communication-API of MoSync (I don´t knew this SDK and others for cpd before). It should be used in our Java environment for instance to easy create a bluetooth-connection to different phones and so on.
For me the other question is now, how I can use such SDKs like MoSync, Titanium and others in a existing project? In my opinion it is not possible. Either you develop nativ or with a cpd-framework.
I would also be interested in when do you recommend this frameworks (I know already that there are some other threads about this). I personally would say that there isn´t a great future for this SDKs because of technical drawbacks and dependencies. In addition, the market for cross-platform solutions (hybrid, interpreted, cross-compiler) is at least as fragmented as the market for mobile operating systems themselves
What are your experiences?
Martin
Cross-platform implementations of any type, on mobile or anywhere, are primarily to reduce the time to market. That statement may look like oversimplified, but it more or less holds true. So, the ideal situation to use it would be to have an application/game that maybe, uses the common denominator of features across the smartphones, which could include touch, a decent UI, the network, maybe the accelerometer in some cases LBS. So, you land on multiple phones in quicker time and reduced development cost.
If you are looking to utilize a lot of hardware specific features, then we land into what's commonly known as the unknown territories. Then you have to do what people always do, gather more information about the landscape of phones to target and see if the "chosen framework" has the power to dish out the features on those platforms. In this case, you cant possibly deploy one off-the-shelf.