Android++: Native development and debugging extension for Visual Studio • Hacker News Board

Re: Android++: Native development and debugging extension for Visual Studio

#51

Post by fidotron » Mon, Jan 27, 2014, 11:26 PM UTC

lstamour wrote: post #44

fidotron wrote: post #41

Earlier quoted context omitted.

This is intriguing - I had no idea that the Mozilla experience so closely mirrored my own. The fun thing about Android is you can often spot when apps load the native code library since it generally leads to mysterious black screens during the loading of activities for exactly the kind of reasons mentioned there.

I would point out to all the above commenters, that Chrome is still largely native code, with simple wrappers on iOS and Android. http://www.chromium.org/developers/design-documents/android-...

Yes, but this also goes some way to explaining my assertion that such apps are disproportionately large and slow to start - Chrome exhibits exactly that behaviour.

When they get closer to having the OS WebView actually updated via Chrome channels then it's conceivable that the apparent startup time will come down, and it wouldn't surprise me if this is one of the main reasons for it.

If you see this recent thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink...

They even say this: "The web is quite far behind in mobile, which is why we're applying a greater amount of focus to solving the problems we have on mobile, even at the expense of nice-to-have features."

This is quite an admission, and at odds with a lot of their noise. It's also telling about their problems because Chrome suffers from a sort of death by a thousand cuts. On mobile to get the user experience people demand (they aren't wrong to be after 60fps performance as studies have shown mobile users are even pickier than desktop net users) you simply can't afford things like that anywhere, let alone right as the app starts up.

Re: Android++: Native development and debugging extension for Visual Studio

#52

Post by mattmanser » Tue, Jan 28, 2014, 12:39 AM UTC

Pxtl wrote: post #20

fredgrott wrote: post #9

I am curious, what are the benefits of VS over other IDEs? Obviously, there is the case where the code shop may have other project assets tied into the VS ecology-dev system but is that the only case?

VS has amazingly good debugging tools. Other coding features seem to be prettymuch standard, like showing you arguments for a function you're calling and good autocomplete and refactoring and jumping around to declarations. It's got all the typical bells and whistles - all manner of GUI designers, Source-control integration, test-integration, code-review/commenting, etc, although they're very mature. I mean, it's obs…

That source control integration is definitely not 'mature'. It's terrible. Forgetting that TFS is just awful to begin, the integration in VS is lacklustre and based around very poorly thought out identi-lists and identi-tables that it's hard to extract any information out of. Simple things like getting a list of changed files in a build is several clicks and barely readable when you do find it. You get lost on what screen you're in cause they all look exactly the same. You're never sure exactly what you're committing and it also likes to throw some obscure warning which 90% of the time means nothing, 10% of the time is a repo or commit killer.

Even something as basic as Tortoise SVN is a massive workflow improvement over trying to use TFS.

And test integration got vaguely good in this VS maybe? I wouldn't call it good or mature. Maybe it was 2012, they happened so fast I barely used 2012. I remember trying to use it in 2010 and clicking on failed tests wouldn't take you to the failing line or the failing test, it would do bizarre things like expand an info pane that didn't actually have the info you needed. It was such a complete failure that they totally ditched it in VS 2013 and had a whole new UI.

And don't get me started on the god awful profiler they've added, what a disaster.

Half the things they add in VS suck, but are better than nothing.

Re: Android++: Native development and debugging extension for Visual Studio

#53

Post by corresation » Tue, Jan 28, 2014, 1:50 AM UTC

fidotron wrote: post #51

lstamour wrote: post #44

Earlier quoted context omitted.

I would point out to all the above commenters, that Chrome is still largely native code, with simple wrappers on iOS and Android. http://www.chromium.org/developers/design-documents/android-...

Yes, but this also goes some way to explaining my assertion that such apps are disproportionately large and slow to start - Chrome exhibits exactly that behaviour. When they get closer to having the OS WebView actually updated via Chrome channels then it's conceivable that the apparent startup time will come down, and it wouldn't surprise me if this is one of the main reasons for it. If you see this recent thread: ht…

You seem to think that each of these posts is supporting what you claim, when it's doing nothing of the sort.

Firefox was slow because it had a very expensive abstraction layer that, while tolerable on a high power desktop, was just too much for what could be a low power mobile device. They didn't switch from C++ to Dalvik, they changed their GUI layers and how they initialize. This does nothing, at all, to support your claim about native apps being either slow to start or being large.

Nor does the Chrome bit. It's a large, full-featured browser. Further, on what is it slow to start?

Re: Android++: Native development and debugging extension for Visual Studio

#54

Post by pjmlp » Tue, Jan 28, 2014, 7:24 AM UTC

lstamour wrote: post #43

fidotron wrote: post #42

Earlier quoted context omitted.

You're making the precise mistake we're talking about: don't project from your experience of desktop Linux to Android. This equally applies for any Java platform too as the VM performance characteristics don't resemble any from the Sun/Oracle family. The key thing is to understand what is involved to get an Android app to start up. This is terrifying when considering just the Dalvik case, but what most C++ types don'…

The Google Play store will accept multiple build types and will deliver the correct builds to the correct phones automatically, no need for a fat binary. While NativeActivity is interesting, for LOB apps we're much more likely to stick to native Android UI components, which means Android/Java activities. However, Loaders might then in turn use JNI as a model layer. I'm still working out the details myself, but I feel…

Or Qt, as they support Android and iOS since version 5.2.

If you are doing commercial software, the licenses should be ok, but I am no longer sure how much.

Digia adopted the typical enterprise way of having sales people talk to you for price information.

Re: Android++: Native development and debugging extension for Visual Studio

#55

Post by pjmlp » Tue, Jan 28, 2014, 7:25 AM UTC

corresation wrote: post #50

pjmlp wrote: post #36

Earlier quoted context omitted.

So maybe AAA studios shouldn't be using Unity. Oh wait...

The overwhelming bulk of a Unity game on Android runs in purely native code (the Unity shared library). Of course the game orchestration and such runs in a managed runtime (mono), but the garbage created by simple orchestration/management running in a GC is minuscule compared to the garbage created by an entire game engine running in a GC.

Ah you mean like the Witcher 2 for the XBox 360 where the C++ engine uses a GC?