On Mon, 23 Jul 2012 08:59:32 +0200
"Paulo Pinto" <pjmlp@progtools.org> wrote:

> >"Nick Sabalausky"  wrote in message news:20120723010439.00006efc@unknown... I wouldn't know. I haven't actually dealt with the android SDK directly, only Marm. When I saw google saying you use either Java or straight natively-compiled C++, I guess I assumed that meant an actual C++ API.
> 
> No, actually you are still dealing with JNI. Google's position on
> native code, is that
> you should use it just for code hotspots, gamming or to port "legacy"
> code.
> 
> [quote]In general, you should only use the NDK if it is essential to
> your app—
> never because you simply prefer to program in C/C++.[/quote]
> 
> http://developer.android.com/tools/sdk/ndk/index.html
> 
> The native activity is actually a Java Activity with a specific set
> of methods defined
> as native methods.
> 
> http://developer.android.com/reference/android/app/NativeActivity.html
> 
> You are only allowed to access these libraries:
> 
> - libc (C library) headers
> - libm (math library) headers
> - JNI interface headers
> - libz (Zlib compression) headers
> - liblog (Android logging) header
> - OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
> - libjnigraphics (Pixel buffer access) header (for Android 2.2 and
> above).
> - A Minimal set of headers for C++ support
> - OpenSL ES native audio libraries
> - Android native application APIS
> 
> The Android native applications APIs are C wrappers around JNI calls,
> meaning you get a performance
> hit when calling them due to marshling. This is described in the
> STABLE-APIS.html document delivered
> as part of the NDK.
> 
> [quote]Starting from API level 9, it is possible to entirely write an
> Android
> application with native code (i.e. without any Java). That does not
> mean that your code does not run inside a VM though, and most of the
> features of the platform will still need to be accessed through
> JNI.[/quote]
> 
> Java is the main language to develop standard applications on
> Android, everything else are just
> workarounds, even if we don't like it.
> 
> Another example are the new low level Codec APIs in Jelly Bean, which
> are only  exposed directly via JNI to
> Java.
> 
> http://developer.android.com/reference/android/media/MediaCodec.html
> 

Gah! What the fuck is this, 1998?!? (Why can't we finally just let Java die as the wretched idea it always was?)

I've always seen Android as a slightly-less-shitty clone of iOS. But
every time I turn around, I discover another way Google seems hell-bent
on proving me wrong. They ape most of Apple's bad ideas and then
toss in some of their own.

How the hell is it even *possible* for another company to compete this well with Apple on retarded design decisions?

I suppose with the death of Jobs it was inevitable for another company to successfully surpass Apple's horridness, but I always figured it would be from Apple getting slightly less crappy or fading back into their 90's obscurity where they belong - not from others sinking down to sub-Jobsian idiocy. I'd never even considered that a possibility. Very depressing. I miss Woz's computers. Fuck, I even miss the days when Microsoft ruled the world with an iron fist. At least back then platforms were open and software/hardware designs were relatively sane from a user's standpoint (even if the code behind them wasn't).

On 2012-07-23 05:04:39 +0000, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> said:

> Personally I like abstraction layers for GUI: it means you don't have to
> deal with twenty different system-specific (and idiosyncratic) APIs.
> For example, I hope I never have to touch Win32 directly again.

Win32 is a special case. It's old and low-level, no one wants to touch it. Even those who build directly on it abstract it with a layer of their own.

Abstraction layers for GUI are not inherently bad, but they also tend to blur platform specificities. This often results in apps that feel a little alien on every platform. So whether you should use them or not depends on your priorities.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On 2012-07-23 13:21, Michel Fortin wrote:

> Abstraction layers for GUI are not inherently bad, but they also tend to
> blur platform specificities. This often results in apps that feel a
> little alien on every platform. So whether you should use them or not
> depends on your priorities.

I think a system where the common widgets, i.e. windows, buttons and similar, are abstracted but still lets you easily access the native API would be a good thing. This mean you would still need to be able to access the Objective-C and WinRT object model to be really useful.

-- 
/Jacob Carlborg

On Sat, 21 Jul 2012 23:11:02 +0200
"Adam D. Ruppe" <destructionator@gmail.com> wrote:

> On Saturday, 21 July 2012 at 20:17:11 UTC, Nick Sabalausky wrote:
> > - Adam's HTML DOM (And I cached partial and full results in memory, of course, so I wasn't DOMming it up on every request)
> 
> DOMing it up every request rox. That's what I do and so far the impact of those have been negligible in the profiling.

I never actually benchmarked, so it's entirely possible I was just doing a premature optimization. Does it do anything special for the sake of speed?