I'd like to experiment with symbolicating after a crash. I'm building my app in C++ Builder 10.2.3 (Tokyo). How can i cause a crash intentionally in code - in a controlled manner.
thanks,
russ
Related
Since [ReactNative/NativeScript] uses JavaScriptCore/V8 JIT interpreters and not compiling it so, is it strong enough for building all types of apps e.g. (Mediaplayer, Photo Editing, etc…)?
And how do you compare it with Xamarin?
I heard Xamarin uses AOT; is it similar to (JavaScriptCore/V8) JIT interpreters?
And how often Xamarin uses AOT for all of the app or it compile the part of code to native and uses AOT for rest of it?
Many Thanks in Advance.
Xamarin does AOT for its C# code, which will be run by open source port of .NET -Mono in non windows platforms like Android and iOS. Here are some limitations on Xamarin AOT
In comparison, Nativescript with Angular 2+ can take advantage of the Angular AOT for performance boot. More details here.
Here is a detailed comparison from Progress, the company that backs NativeScript and also provides UI elements for xamarin.
With more traction towards JS open source community, JavaScript virtual machine growth vs Mono for .NET, current benchmarks, I would bet on NativeScript/React native more than Xamarin.
NativeScript / React Native is a good bet, including your media player kind of app.. here is a sample you can give it a try.
Hope it helps.
We have an android application and want to recreate it for cross platform.
What are the facts for or against Xamarin native and forms?
The advantage of native would be, we could reuse all the xml-layouts while we have to recreate the iOS view in either XAML or XIB?
Is there anything what is really a blocker?
I'll comment based on Giorgi's answer with some actual insight and refer to the copied bullet points:
This is a resume of the experience i've gathered in the past 6 months:
Xamarin.Forms is best for:
Apps that require little platform-specific functionality
Wrong. With DI you can use any device functionality you could possibly want. Check out XLabs on GitHub if you doubt this.
Apps where code sharing is more important than custom UI
Kind of nonsense really. You can write your own renderers to represent controls of each platform in the way you want. I've also written more difficult renderers for custom controls such as a SideDrawer. In android i was done in 2 days, iOS about 2 weeks (android renderer was just a wrapper for the native control)
Developers comfortable with XAML
well yeah and anyone who enjoys convenient UI development. Mind you that there is a learning curve with xaml (which i already knew at the time i started from WPF development). But from what i have seen it's not that different from android.
Xamarin.iOS & Xamarin.Android are best for:
Apps with interactions that require native behavior
While hacking your solution up natively is certainly faster you can instead be done rather quick if purchase good controls / know a good native implementation and mirror it in C#, since the API in C# is very similar to the native one.
Apps that use many platform-specific APIs
Not sure why Xamarin is doing anti advertisement against forms. I had little trouble with it so far
Apps where custom UI is more important than
code sharing
Probably true, but it's also harder to keep UI functionality inline and you will need more manpower.
Things to consider about forms:
Forms seems to be stabilizing at the moment and i am sure Microsoft will do their best to turn it into a solid, reliable product (build issues have been a nightmare in the past sometimes, but it has gotten better over time)
The XAML for Xamarin is less developed compared to WPF XAML, though very similar. Recent nuget updates however provide mirrored functionality at an impressive rate. The vast majority of features you expect and love about XAML are present.
List performance is bad if you don't do your research (here). Performance increased loads in that area.
If i had to make the choice again i'd still go for forms. While there are sometimes things which seem flawed / bad you can usually figure out a clean fix somehow, while spending most of your time actually developing the app. (sometimes you will still find things which just make you frown why something isn't implemented, like the Margin property being implemented only just after microsoft purchased xamarin)
If you end up having a requirement of nested lists, make sure to have a look at embeded native controls in order to achieve the maximum performance - this was essential for a product i was working at. See this
According to Xamarin.Forms main page:
Xamarin.Forms is best for:
Apps that require little platform-specific functionality
Apps where code sharing is more important than custom UI
Developers comfortable with XAML
Xamarin.iOS & Xamarin.Android are best for:
Apps with interactions that require native behavior
Apps that use many platform-specific APIs
Apps where custom UI is more important than code sharing
Giorgis answer is the right one, but since you added some more constraints here are my thoughts.
I would analyze the current app. How much code is business logic which can be shared? How customized is the UI, should it look more native or more the same and how will it change in the future? If you plan to change a lot in UI and platforms should look similar, it might be easier to switch to forms.
Also consider if are you planning to develop for Windows Phone? If yes, you might save a lot of time just for this third platform.
After all there is one thing which I would also keep in mind. Developing in Xamarin.Forms does not mean, you cannot develop native. It is just an additional framework. In worst case you can still do everything natively.
Personally I use Xamarin.iOS & Xamarin.Android with MvvmCross, that way I can keep full control of the native UI on each platform while maximizing code reuse.
From Xamarin website (who knows better than them?):
Xamarin.Forms is best for:
Data entry apps
Prototypes and proofs-of-concept
Apps that require little platform-specific functionality
Apps where code sharing is more important than custom UI
[https://developer.xamarin.com/guides/xamarin-forms/]
With Xamarin.Forms at runtime, each page and its controls are mapped to platform-specific native user interface elements.
With Native Xamarin.Android and Xamarin.iOS apps leverage platform-specific hardware acceleration, and are compiled for native performance. This can’t be achieved with solutions that interpret code at runtime.
"Xamarin.iOS - The best way to build native iOS apps."
Ship native app bundles on the App Store. Our Ahead-of-Time (AOT) compiler compiles Xamarin.iOS apps directly to native ARM assembly
code, meaning your app is a native platform binary.
Access any iOS API. We bring 100% of Apple’s iOS SDK to C#, enhancing Objective-C APIs with stronger types and .NET naming
conventions so you feel right at home.
Call existing Objective-C code from C#. Use your existing Objective-C code, frameworks, and custom controls in your Xamarin app
using our automatic binding generator.
Build WatchKit apps. Use Xamarin Studio or Visual Studio to build new Watch Apps, edit Watch user interfaces in the iOS Designer, and
debug Watch apps in the iOS Simulator.
Stay up-to-date with Apple. We released same-day support for iOS 5, iOS 6, iOS 7, and iOS 8 so your apps can take advantage of the
latest iOS features as soon as possible.
[https://www.xamarin.com/platform]
"Xamarin.Android - The best way to build native Android apps."
Ship native Android packages. Xamarin.Android uses just-in-time compilation for sophisticated runtime optimization of your app’s
performance, meaning your app is a native Android APK.
Access any Android API, including new form factors. We bring 100% of Google’s Android APIs to C#, enhancing Java APIs with async support
and .NET naming conventions so you feel right at home.
Call existing Java code from C#. Use your existing Java code, frameworks, and custom controls in your Xamarin app using our
automatic binding generator.
Build Android Wear apps. With access to 100% API support for Android Wear, create full-featured applications capable of running on
Android Wear devices. Stay up-to-date with Android. Xamarin stays
up-to-date with the most current APIs from Google, so you can always
use the latest features in your apps.
[https://www.xamarin.com/platform]
I'm trying to get into mobile game development with Xamarin; I am using OpenTK for rendering.
My plan is the following:
1. Make a shared library that is actually the game (and has all openTK code).
2. Make a a runnable project for iOS and Android that handles platform specific stuff (e.g. popping up alerts) and uses my shared library.
Is this possible with openTK? Does it have exactly the same API on iOS and on Android, just the linked library is different? If yes, how to avoid code duplication?
Your approach sounds very reasonable and will work with a little bit of effort.
The reason is that Xamarin.Android and Xamarin.iOS were forked from an alpha version of the library and have evolved slightly different APIs. Much of the OpenGL ES binding is identical, but some functions have annoying (and unnecessary) differences that you will need to #ifdef in your shared library.
The good news is that the Xamarin fork of OpenTK has now been open-sourced, so we are actively working towards a solution. I already have a private build of library that exposes an identical OpenGL ES API between Android and desktop platforms[1] and I'm working on fixing the differences between the iOS and Android versions.
You can follow the development of OpenTK in the official github repository.
[1] You can execute OpenGL ES code on the desktop using ANGLE or the ARB_ES2_compatibility and ARB_ES3_compatibility extensions. This makes OpenGL ES the first graphics API to work across all major platforms (Windows, Linux, Mac, Android, iOS - and hopefully WinPhone in the future.)
I have a friend who has an entry-level background in programming and is looking for a free GUI framework (IDE, GUI toolkit and GUI designer ) that:
He can use on Mac OS X to build Windows applications
It's very easy to use.
He is not interested in becoming a programmer, but would like to build an application for his work (not CS-related).
What are some good GUI frameworks/prog. languages he can use?
Qt including Qt Creater and Qt Designer is worth a try.
Especially, if your app should finally run cross-platform, on phones or on other embedded devices. Qt natively supports C++, but can also be used with 3rd-party extensions with Python (PyQt) and probably other languages.
On a Mac I have to recommend making Cocoa applications in Xcode written in Objective-C. Xcode is free to download and use, you pay if you want to submit applications to the Mac App Store.
I personally use Xcode every day and I think it's a great IDE. Currently has compiler support for Obj-C, C++, C and maybe more (not sure). More importantly for your needs, Xcode does a great job of integrating your code with its build in "interface builder" to help you quickly and easily create a nice UI.
NOTE: Xcode includes a new compiler feature (ARC) Automatic Reference Counting which is create for a new user. You can learn the language without having to worry about manual memory management.
Your friend should consider using PySide, a Python binding for the Qt GUI framework already mentioned.
With PySide you can use the Qt tools to create GUI elements interactively
and code your application logic in Python, which is a language often appreciated by non-programmers (and programmers too!) for its simplicity and intuitiveness.
Xcode includes a WYSIWYG editor for native controls and views. This was formerly a separate program called Interface Builder, but the editor was moved into the Xcode IDE at version 4.
AppKit is the framework it uses in most cases -- that's Objective-C. It's well supported. Your friend can also use it for source code editing and building and debugging apps. If he wants to write UIs programmatically, Xcode and AppKit are also good options.
Does anyone has experience in "turning" Cocoa app into cross-platform one for Mac/Win/Linux?
I was thinking of using GCC as a compiler for Obj-C and making new GUI based on wxC.
However, I never had any experience with Obj-C and Cocoa development, so I'm not sure what is possible and what is not.
If you have such experience - what widget toolkit, compiler, etc you choose and did it work?
I have tried Cocotron for that and it's quite mature. After installing Cocotron you create a new target for your project and you can create the Windows, Linux, ... (tried with Windows) from out of Xcode.
Using a remote debugger I was also able to debug the app running in a VirtualBox virtual machine from out of Xcode.
But some parts of Cocoa and AppKit are still missing so I needed to extend Cocotron quite a bit. But that's makeable because it's open source.