Develop Reference

Question about building a program from scratch

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).

How do I tell my boss working with Xamarin will not make it faster [closed]

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.

Cross Mobile Options

I created an Android app. While creating one specific app was an interesting challenge, I'm now looking into creating a group of similar apps.
I'd like to create a group of similar Android apps and then move on to creating the same on tablets and iOS... (anything mobile).
I've considered doing so with a product called PhoneGap or doing a web based mobile app. Both of these options seem less than ideal. Doing the Android app I've been frustrated by Java's lack of control and low level constructs. Moving to something like a web based app seems like the exact wrong direction.
C++ is my language of choice. It has the ability to work at a low level, is highly portable across platforms, and has significant support for generic coding which would be useful for generating a group of similar apps. However, the Android documentation suggests to not use C++ unless your goal is porting existing code or dealing with computationally heavy tasks.
I'm leaning towards using C++ anyway, but are there other options I've not considered?
Thanks

You could in theory write your logic in C++ and then have UI layers on top that make use of it. If you are really comfortable with C++ that might be the way to go.
Almost any other parts (networking, UI, animation, etc) are better off being done in the native language of the platform. Use of cross platform solutions always limits you in some way, and usually leads to an application that is not as good as it could be for any platform.

Well, Google's recommendation to not use C++ is based on the following, I believe. C++ is low level, so you can get extra performance out of it if you know what you are doing. Google makes the reasonable assumption that many programmers do not. It is easier for an inexperienced programmer to do harm in C++ then to get a performance boost.
But, if you know what you are doing, it can help you. UI elements on both iOS and Android are implemented in their main language (obj-c, and Java respectively) so there is not a great way around that, but you can write core logic and other functions in C++ and it will be portable between them (iOS can use C++ directly and Android can use it via the Native Development Kit).
There are a few other options available. The one I ended up using is Appcelerator Titanium but please stay away from it. If your project gets complicated or large at all you will hate yourself for choosing it, as I did. Another interesting one that uses C++ instead of Javascript is Marmalade. I haven't used it though, so I can't comment on it.
A non-free solution that I hear good things about is Xamarin, who have ported both environments to C# and a .NET using Mono. However, you still have to write two versions of your code for the UI as far as I can tell.

Sharing code between Android and Windows Mobile

I'm doing some initial research on smart phone development, and I noticed that Android and Windows Mobile both support c++ for application development. I was curious if anyone had any experience trying to manage shared files between both Android and Windows Mobile, and to what extent that code can be shared? e.g. no user interface can be shared, but web service and business logic classes can be shared, etc.

I can't speak to the WinMo side of things, but on the Android side you should really really really avoid using native code for anything except performance-critical processing algorithms. JNI/NDK stuff does not play nicely with the normal Dalvik lifecycle and can be a source of all sorts of ugly unpleasant bugs and memory leaks. From what I understand there also aren't on-board NDK libraries for more complex high-level functionality like HTTP (just more basic/performance-oriented libs like libz and OpenGL), so you'd probably have to compile that stuff and ship it with the app as well. I would definitely not recommend coding your web service classes in C++, even if it's technically possible; it'll be less buggy and nicer to write C#/Java and you should be able to make mostly the same architectural decisions for consistency.
That said, if you have a performance-critical bit of image processing code or the like, it actually can be fairly straightforward to get that working across Android to other platforms (I've seen it done quite well with some image-processing C code used in an iPhone app and then used via the NDK in an Android app).
Check the documentation on the NDK for details on what it can (and can't) do, and see similar SO threads like this one.

Android Adverse To Dynamic Languages

I believe I read at some point that due to Android running on the Dalvik VM, that dynamic languages for the JVM (Clojure, Jython, JRuby etc.) would be hard pressed to obtain good performance on Dalvik (and hence on Android). If I recall correctly, the reasoning was that under the hood, in order to achieve the dynamic typing, there was quite a bit of fiddling done with the java bytecode and that the bytecode->dalvik translation wouldn't pick this up easily.
So should I avoid a dynamic JVM language if I want to develop for Android?
EDIT: I guess I should have provided a bit more context. I was considering using Clojure to develop apps for Android. I was thinking about using Clojure for a few reasons:
I want to learn FP
I don't really care to learn Java
Clojure seems to have some very
interesting language concepts (STM
for example).
However, when I tried to write apps for Android in Clojure, I found that there is a performance issue that is unacceptable. But I found a blog posting that said that dynamically typed languages (Clojure for example) would have problems due to the bytecode manipulation needed to get the dynamic typing. So I was sort of looking for independent confirmation that this is true or it isn't. I should have known better than to make the assumption that in this particular issue all dynamically typed JVM languages could be treated as the same. I guess I did ask a fairly broad question so I guess I shouldn't be surprised that people didn't quite understand what I was asking.

Dan Bornstein gave a presentation on Dalvik at Google I/O. It's worth watching to learn about the system in general, including the constraints you care about. The specific issue of non-Java languages compiled into Java bytecode comes up during the Q&A.
Remco van 't Veer has a github project where he's patched Clojure to work on Android. Tim Riddell has written a tutorial on how to use it.
As mentioned here by #sean, there is sometimes a bigger problem than just performance. Dan Bornstein discusses it when asked about Jython, at ~54:00 in video. There is currently no support for dynamic languages which generate bytecode on-the-fly, (because the bytecode translation is not available at runtime).

Android just got scripting

There are some patches to make clojure work.
http://riddell.us/tutorial/clojure_android/clojure_android.html
I think the real issue is the use of byte code generators by some dynamic languages; they won't generate byte code for the Davlik VM. Therefore eval will not work.

Given the relatively speaking cramped hardware of the phone running you probably should just target java and not worry about a dynamic jvm language. They dynamic languages on the jvm aren't going to be as efficient as the java to my understanding.
Besides the Android SDK is pretty sane and easy to write for I don't think you'll experience very many benefits using something else.

dynamic languages for the JVM would be hard pressed to obtain good performance on Dalvik
Dynamic languages are hard pressed to obtain good performance, period. If you want performance, use a statically typed language like Java (or C#, F# etc.).