Performance of Xamarin vs. NativeScript - nativescript

all.
So, I'm completely new to programming, especially mobile development. Considering goals for a future app I'm designing, I've been thinking of using NativeScript. I was reading the book "The NativeScript Book" offered on NativeScript.org, and they were discussiong JIT vs pre-compiling (AOT I guess it is? Correct me if I'm wrong on that). They also showed how a framework like Xamarin compiles down to the native file (.apk for Android and .ipa for Apple) where NativeScript runs in a javascript virtual machine.
When reading this, it seems like code that has been compiled BEFORE and not just at the time of execution would have a significant advantage in terms of speed, especially on phones where they aren't nearly as capable as modern desktop computers.
Can someone address this concern for me? Likely it's because I am ignorant and don't understand things yet, so please enlighten me and help me learn.
THanks :)

If you are new to programming, the performance of the framework should not be one of your priorities. You should start by focusing on other aspects, like portability, or simplicity of the solution. Learning to write good software should be your top priority instead of trying to write fast software.
Nonetheless, if this is really important for you, there are some benchmarks available opposing the different mobile oriented frameworks. For instance, the NativeScript website has one :
https://www.nativescript.org/blog/nativescript-and-xamarin
Check the 'Speed' section. It states for instance :
In these tests, you can see that Xamarin is roughly 200 ms faster than NativeScript at startup time.
But as you'll notice that when comparing performances, benchmarks always target only one aspect of the solution. This one in particular targets boot time. Some others target sorting of large arrays, or HTTP requests speed.
It is impossible to get a global performance test indicating which solution is the best. I think that one good example in that regard is the comparison of Xamarin VS Native languages (Swift // Java). Check this page :
https://www.altexsoft.com/blog/engineering/performance-comparison-xamarin-forms-xamarin-ios-xamarin-android-vs-android-and-ios-native-applications/
Xamarin is close to native solutions since it uses the native SDKs, but you will notice big differences between Xamarin and native. So it would be event more complicated to compare Xamarin and NativeScript which has a completely different logic !
In my opinion, you should start by the framework you like the most. And change it based on your experiences if you are not satisfied with it.

Related

Haxe NME UI: Best practices for MVC application design

yesterday I stumbled across the Haxe NME project, which is a very promising idea. However, it is still not possible to build sophisticated UIs with this framework. In my opinion it seems to be a intimidating task to build a UI framework that targets so many different platforms, hence I think that this isn't a viable approach, because even old and mature UI frameworks like Qt and wxWidgets don't support so many platforms.
However, it could make sense to build a platform specific UI with help of some pretty UI designer tool and then connect the UI code to the UI agnostic code that has been written in Haxe. I don't know if this could work, because I couldn't find any example, but maybe someone who has already written some MVC Haxe code, that could be successfully connected to different platform specific UIs, would like to share his experiences. Thanks.
You say:
However, it is still not possible to build sophisticated UIs
Just because you haven't yet figured out how to do it doesn't mean it's not possible ;)
The reason it is possible is that in the Haxe ecosystem, the language and compiler is extremely consistent cross platform, NME/OpenFL provides a fairly strong cross platform rendering environment (HTML 5 has some quirks, but the others seem fairly strong) and so anything you build on top of these is going to cover a lot of platforms out-of-the-box. It's about being fairly high level - letting the compiler and the libraries take care of the platform quirks.
In MVC, the UI stuff is usually the "View". For View / UI frameworks, check out these libraries:
Stablex UI
NME/OpenFL, Cross Platform. Draws components using NME API. This is
the only one I've played with, but the demo works consistently on android,
flash, html5, native linux. Pretty impressive.
HaxeUI
NME, Cross Platform. Again, draws components on the stage.
Prime
Drawn using Flash API. Not sure if it has been ported cross platform yet.
See also Talk/Video from WWX conference and Slides
Guise
A really innovative way of being able to either draw the UI, or use native if available. Check out the blog post.
Basis
Another attempt at wrapping native components - has iOS and Android libraries so far. Pretty cool, but I haven't played with it yet.
For MVC, there are lots of options:
PrimeVC, mentioned above.
MMVC, based on the RobotLegs framework, but tailored for Haxe.
Lots of small options BBMVC PureMVC etc
The advantage of the MVC frameworks is that they separate your views from your application data (model) and logic (controller). Try to spend some time familiarising yourself with one of the MVC frameworks, and you'll see how you can write your apps in a way where you could use one of these, and then any of the various view engines - either native or NME-rendered. It can be a fairly steep learning curve, but this is how you build apps that are easily portable between different UI frameworks, and easily testable so you know they will scale as the app grows in complexity.
The main problem you seem to face is that there is no out of the box option that is complete and ready for you to use. The multitudes of project people are suggesting do what you want. You need to be willing to use them. A small project on github may be dropped. If so it will be dropped because jo one uses it so its up to people who would like to use it (ie: you) to keep it going.
Everyone can't siphon of others completed projects or nothing would ever be created. Participation is what opensource is about.
Doesn't make sense to have a unified UI for all platforms, every platform have diferent workflow, have you tryed to use a IOS listbox on windows , is simply ridiculous. On the other hand a good design could separate the view from the bussines logic and you can share the bussiness logic with all targets and tweak the views for every target. look at PureMVC
for a mvc example in Haxe

What are some methodologies that a solo developer should use while creating cocoa programs?

I have recently started learning cocoa development with a fairly large scale(probably Core Data based) application in mind as my goal. I have been looking into development methodologies that would be used to help build a higher quality product with better code and although I have found a couple that I am sure I would like to use, such as version control(probably with git) there are some others like unit testing that seem like they would be hard to use when the majority of the application is written with IB and Core Data. I would really appreciate some suggestions as to what tools or workflow methods a solo developer should be using.
Thanks.
P.S. First post in SO!
EDIT: By the way I primarily plan to develop for OS X and not the iPhone.
welcome to SO :-)
One thing I struggle with as a solo dev is discipline...!
Always comment, test, design ahead if you want to increase the quality of your code, reduce the amount of times you re-write something until your interfaces/class structure actually works, and have code that you can come back to in a years time and know what you mean!
Apple have a great guide for Unit Testing
As of iOS 4, Apple have added a UIAutomation framework for testing the User Interface of apps.
O'Reilly has a guide here, and you may want to have a peak at Apple's official documentation for UIAutomation
Its fairly new, but it won't hurt to take a look at it.
There has also been a query on SO about automated testing of iPhone apps.
Our own Chris Hanson did a series of posts about Cocoa and Unit Testing. It isn't as difficult as you think.
use git, it makes it really easy to go back to prior versions
comment your code, as others mentioned you'll need to look at it years later and understand it
get in the habit of building yourself reusable classes. Many tasks you perform when developing will need to be duplicated in other projects
expect that no matter how diligent your try to be, your users will have problems. As such you have to develop a methodology of allowing your customers to report their errors to you that is useful. I recently implemented this for myself. It's basically a way to get meaningful stack traces back from users through email. I learned this here.

Should app using VCL migrate?

Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.

Preferable technology that I should use to create an efficient and user friendly GUI?

There are many more technologies and tools available to build the front end for an application.
Which is the best technology/tool/platform available using which I can build a better GUI, by which I'll be able to build a nice looking as well as an efficient GUI?
Definition of "better" includes factors such as efficiency,user friendliness,better content control mechanism, navigation and many more.
I know this is a question about which GUI toolkit you should use, but your first technology for producing a user-friendly UI is pen and paper. Sketch out some mock-ups. Draw buttons and menus on construction paper, cut them out, and glue them together. Then try your mockups on about a half-dozen people. You'll quickly find out what makes a good UI.
It doesn't matter how good the UI looks or whether it uses the latest snazzy effects -- if your users can't figure out how to use it, they'll go elsewhere. You need to learn what works for your target audience before you write a single line of code.
Read Don't Make Me Think to learn how to make mock-ups and do user testing.
If' you're tracking an IP address, you'll definitely want to create your GUI Interface in Visual Basic.
Use the .NET framework in Visual Studio 2005/2008/2010 Studio. I haven't developed in any other environment, but I have been able to create nice looking apps in this IDE / Framework.
"Best" depends on what your evaluation function is.
For ease of development, and high quality UI, in a non-web based app it's hard to beat C#/VB or any other .NET language and environment for a windows-based app. Depending on the quality of the UI, MPF will give you greater flexibility and control, whereas windows form will make it easier to develop.
Having used Windows Presentation Foundation for a while now i would highly recommend it. There is a pretty big learning curve and, to be honest, MSFT should have included some controls (the datagrid being the biggest one) that were not included by default (but will be in .NET 4.0). Where WPF and XAML exceed is providing a foundation from which you can build just about anything. You can style ANY part of ANY control and build your own composite controls from scratch. A lot of thought went into binding and value converters and once you get used to the declarative nature of XAML you wont want to turn back. The company I work for has been using it for a couple of years now and the difference between the GUIs we used to develop (mainly winforms and asp.net) and what we develop now are night and day in terms of both look-and-feel and functionality. My two cents anyway...
It depends.
What device will the GUI be used on, hand held, PC, Mac?
What platform Windows, Linux, Web?
What kind of application will it be, accounting, email client, web application?
What audience will be using the application (a GUI aimed at a child may be different than one aimed at an adult)?
All of these things must be taken into account before even starting to formulate an answer to your question.
You have several choices for developing a GUI.
first, if cross platform is an issue consider using Java or Python.
you can also use Adobe AIR and develop the gui in Flex.
If you direct the product to windows only users .NET WPF is the best solution, with a very rich set of control and examples.
You can also use .NET with mono for cross platform compatibility, but WPF isn't currently supported.
Desktop, Mobile, Windows, Linux, Database, OpenGL: Nokia Qt. Wiht Python - PyQt development process is shortest and easy. Application containing all required python & qt libraries and modules is around 30MB with Inno Setup installation is 8MB and will work on Windows 2000 and newer for Python 2.6.x, Python 2.5.x based application will run from Windows 95 to Windows 7.
I think all the attributes you list -- efficiency, user friendliness, etc -- are attributes of a good design rather than a good toolkit. Just about any toolkit can be used to meet those goals. I think the question might be different if you were asking about eye candy, fancy multi-media, etc. There are definitely some toolkits that do that better than others.
If you're interested in usability first (and it sounds like you are), focus on the design then pick whatever toolkit meets your current abilities and can handle your design. For example, if you require 3D images that might narrow your choices; likewise if you need to show videos, that will influence which toolkits you can choose from.
So, start with a good design. From that, create a list of requires for the toolkit -- rich editing controls, video, 3D, etc. And then look for a toolkit that provides what you need.
The best toolkit in the world won't make up for poor design.
Personally after having used Win32, Forms and WPF then going to Mac/iPhone GUI development, I very much prefer the flexibility and high quality of visuals in the Mac/iPhone GUI.
One of the most useful examples is the fact that in NSTable/UITable controls (ListViews or similar in Windows), every cell is a fully customisable View (a Control in Windows).
Where in a ListView you have very little customisation for each cell/item in the view since you only provide details, not an actual control, an NSTable/UITable asks you for a table cell which you can add anything to, such as buttons, switches and image views.
Mac OS GUI development to me is a LOT more flexible and more consistently flexible in that regard. Everything is a View so I can my own contents to anything.
Have you considered Silverlight?
It can be used to create internet applications, but it can also be run out of browser to create desktop applications. It's has significant overlap with WPF though there are differences which might catch you out when swapping from one to the other.
Expression Blend 3 is a very good visual designer and the code it produces is quite efficient.

Where is a good place to start programming GUIs for windows? [closed]

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 5 years ago.
Improve this question
I have experience writing console and network client/server applications in C and C++, but I know next to nothing about using the win32 visual API, MFC, Qt, wxWidgets, etc. Where is a good place to start, and what method should I specialize in, so as to be future ready and robust?
This is a rather broad question, as programming GUI applications in Windows can be done in so many ways.
There are two main parts to developing any GUI app: the language and the API/framework. Considering you're interested in learning to build Windows GUI apps, the language isn't really a point of focus for you. Hence, you should pick a language you already know and work with a framework or API that can be harnessed by your chosen language.
If you want to use C you're pretty much restricted to dealing with the Win32 API yourself, in which case reading Petzold or Richter would be great places to start. The Win32 API can be quite daunting, but it's well worth the effort to learn (imho). There are plenty of tutorials on Win32 on the web, and there's always MSDN, with a complete reference/guide to the Win32 API. Make sure you cover not just the API, but other areas such as resources/dialogs as they are building blocks for your Win32 application.
If you want to use C++ you have all of the options that you have when using C plus a few others. I'd recommend going with the Win32 API directly, and then moving on to a known framework such as MFC, Qt, wxWindows or GTK so that you can spend less time working with boilerplate code and instead focus on writing your application logic. The last 3 options I just listed have the added benefit of being cross-platform, so you don't have to worry too much about platform-specific issues. Given that you said you want to work with Windows, I'll assume you're keen to focus on that rather than cross-platform -- so go with MFC, but spend some time with the Win32 API first to get familiar with some of the concepts.
When dealing with MFC and the Win32 API, it's a good idea to try and get a solid understanding of the terminology prior to writing code. For example, you need to understand what the message pump is, and how it works. You need to know about concepts such as "owner-drawn controls", and subclassing. When you understand these things (and more), you'll find it easier to work with MFC because it uses similar terminology in its class interfaces (eg. you need to know what "translate messages" means before you can understand how and when to use PreTranslateMessage).
You could also use Managed C++ to write .NET GUI applications, but I've read in a few places that Managed C++ wasn't really intended to be used in this manner. Instead it should be used as a gateway between native/unmanaged code and managed code. If you're using .NET it's best to use a .NET language such as VB.NET or C# to build your GUIs.
So if you are going to use .NET, you currently have the choice of the WinForms library, or WPF. I personally feel that you'd be wasting time learning to build WinForms applications given that WPF is designed to replace it. Over time WPF will become more prevelant and Winforms will most likely die off. WPF has a much richer API set, and doesn't suffer from many of the limitations that Winforms does. If you do choose this route, however, you'll no doubt have to learn XAML, which is a markup language that drives WPF applications. This technology is coming of age, and there are many great places to learn about it. First, there are sites such as LearnWPF, and DrWPF which have some really great articles. Secondly, there are plenty of quality books on the topic.
So, to sum up, once you've picked your language and tech, the path is actually quite easy. Just pick up a book or two, read some blogs, get into some code samples.. and most importantly ... write code. Keep writing, keep making mistakes, and keep learning from them.
As a final note...
In other words, Silverlight. If you don't want to go the MS route you might give Adobe's Flash/Flex a look see. Both Silverlight and Flash/Flex build RIA's. Which I think is where we are headed. They days of Office like apps are numbered
I don't agree at all. Silverlight is not the same as WPF. Silverlight is web-specific, and only has a subset of WPF's features. Given that the question asks for Windows GUI apps, Flash/Flex Rich Internet Apps are not really a fitting suggestion. I also don't agree that the days of Rich Client Applications (such as office) are numbered at all.
I hope that helps. Good luck :)
I don't know if I'd call it a good place to start, but if you want to be future ready, take a look at the windows presentation foundation which is built entirely for the purpose of programming GUI's for windows
My first experience writing simple GUI applications for Windows was with C# and Visual Studio. The GUI-building interface is a simple drag and drop deal that generates skeleton methods based on potential user actions. I only did fairly basic programming with this, but I imagine it would be an excellent place to start to learn the basics and extend into the more advanced capabilities as you go.
There are plenty of online Win32 tutorials:
http://www.zeusedit.com/forum/viewtopic.php?t=1218
There are plenty of compilers to choose from:
http://www.zeusedit.com/forum/viewtopic.php?t=238
I would also recommend getting the Borland Win32 SDK documentation in WinHelp file format:
http://www.zeusedit.com/forum/viewtopic.php?t=7
It only covers the bare basics of the Win32, but when starting, this can be helpful as it is less daunting and less bloated than the MSDN.
I'd never go down the Silverlight, Flash/Flex or any similar route. It does look nice, but the main problem is that the code of the engine that runs it is completely closed-box and controlled by a single company. Take, for example 64bit versions of both of those. If some new platform emerges, you won't be able to migrate your existing code to it.
For business apps, Windows Forms is very mature. It provides a gentle path from auto-generating a lot for you into allowing fine-grained control and rolling your own. There are tons of high-quality third party controls and a large body of examples, docs, etc out there. It's hard to run into a problem that someone else hasn't solved. I highly recommend acquiring some background Win32 knowledge (e.g. Petzold) as the WinForms framework lives on top of it.
I have no WPF experience, but from the sample apps I've seen it looks like a good choice for apps whose interfaces would benefit from more graphical metaphors. So if you're doing a banking app, probably not worth the extra design overhead. But if you're doing, say, a warehouse management app it could be improved by dropping pretty boxes into pretty bins.
#StephenCox: wrong answer to the wrong question. OP is asking about desktop client apps, and moreover, WPF != Silverlight.
For a simple starting point to get your head around the "event-driven" nature basically all frameworks are created around look at FLTK.
Here are some quick starting videos Link
For professional use I'd recommend Qt, expensive but often worth it in commercial situations.
Since you are already familiar with C and C++ I would recommend learning how to write a simple Windows GUI app using Charles Petzold's book. It will give you the fundamental understanding of how Windows works. It's good to understand that most everything that you see is a window (a button is a window for example) and that these windows respond to messages. I wouldnt' spend a lot of time on this though and you don't necessarily need to do this first if you are going to chose WPF. I just think it's good to have a basic understanding of this.
There was a good podcast recently on .Net Rocks called "Kate Gregory Develops in C++ for Vista!" on there she recommends that someone starting out now should not use/learn MFC (even though it has been recently updated).
As far as getting ready for the future you need to learn WPF, but it isn't complete yet, so depending on the kinds of client side apps you want to create, you will probably need to learn WinForms. The majority of people aren't using WPF yet, so it's a good time to start learning. I think you will find it easier using C# to learn it instead of doing managed code with C++.
Get your basics right first. Best tutorial I've found is: http://winprog.org/tutorial/start.html
After that, although the homepage is hatefully distasteful, the tutorial pages are good in content and aesthetics: http://www.tenouk.com/cplusmfcdotnet.html
Then of course there's MSDN.

Resources