AndroidCoding is my Dreams

[the.weavster]

OpenFL and HaxUI are too reliant on Flash. XDK is HTML5 which always has problems publishing on IOS store.

How are they "reliant on Flash"?
Flash is one of their possible targets not a dependency.

[TI-994A]

The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

Google’s introduction of the V8 engine is a real game changer, it allows JavaScript running in Chrome browsers and Android mobile devices to be compiled to machine code before execution. This means is runs blisteringly fast, enabling a whole host functionality that was previously out of reach for JavaScript based applications. You can now do amazing things involving image processing, 3D graphics and physics simulation that were simply impractical before the creation of V8.

Source

I'm pretty sure that there's a point that's going to be torn to shreds in that post of yours.

If there's even a point to begin with.

[the.weavster]

I'm pretty sure that there's a point that's going to be torn to shreds in that post of yours.

If there's even a point to begin with.

This DroidScript and this droidscript are not the same project.
Repeat after me: "DroidScript uses V8 not Rhino"

Have I explained that clearly enough for you? I know you struggle.

[TI-994A]

This DroidScript and this droidscript are not the same project.
Repeat after me: "DroidScript uses V8 not Rhino"

Incorrect, as usual. One DroidScript uses Rhino, while the other uses V8.

And still no point.

[tj1010]

OpenFL and HaxUI are too reliant on Flash. XDK is HTML5 which always has problems publishing on IOS store.

How are they "reliant on Flash"?
Flash is one of their possible targets not a dependency.

You're correct it's just a build option.

I'll eventually do test builds with these two engines and see about UI support. They have GPS and sensor support for sure, but I want to see the range of widgets there is, and how much like Java they look.

Something with a range of UI widgets that works on Android and IOS would be ideal. Most of the 'easy' languages out there don't even implement sensors.

The current economics of indy dev for apps is a nightmare, unless it's primitive screen switching button apps like you see some people churn out in a week and act like they're launching a business with..

[the.weavster]

This DroidScript and this droidscript are not the same project.
Repeat after me: "DroidScript uses V8 not Rhino"

Incorrect, as usual. One DroidScript uses Rhino, while the other uses V8.

And still no point.

First, let me remind you of the context because that's a real failing of yours:

DroidScript makes creating apps for Android very easy.

I suspect their "native" builds are just static JS resources and they sub-class webview like others. If you don't need short-term port to IOS it's probably the best option I've seen.

I'm wondering how they pay for development though? No ads and no sales regulations. It's also beta.

See which DroidScript was being discussed?

Then let's look at what you said:
First you said this:

The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

and then immediately followed up with this:

There's an APK-builder plugin that's offered as an in-app purchase.

Are you saying you knew you were talking about two different projects?

[Danilo]

You're correct it's just a build option.

I'll eventually do test builds with these two engines and see about UI support. They have GPS and sensor support for sure, but I want to see the range of widgets there is, and how much like Java they look.

Something with a range of UI widgets that works on Android and IOS would be ideal. Most of the 'easy' languages out there don't even implement sensors.

See also the hundreds of available libs at Haxelib (cross-platform, and target-dependent ones).

And projects like HaxeD and Dax for conversion to/from D. Interesting stuff for languages-interested people.

[TI-994A]

Are you saying you knew you were talking about two different projects?

No. I believe that the current version of DroidScript is a fork of the original version which ran on the Rhino engine. The fact that it had upgraded to the V8 engine has no bearing on the comments that I had made.

Which brings me back to the elusive question: What's you point?

[the.weavster]

No. I believe that the current version of DroidScript is a fork of the original version which ran on the Rhino engine.

Why do you believe that? There's absolutely no similarity between the APIs never mind the underlying JavaScript engine.

Which brings me back to the elusive question: What's you point?

It was a very simple point for most people to understand but let me help you out (again). This:

The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

is incorrect.

[TI-994A]

There's absolutely no similarity between the APIs never mind the underlying JavaScript engine.

This:

The JavaScript code runs atop an embedded Rhino Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

is incorrect.

Besides the difference in the underlying JavaScript engine, which we've established, how so?

[Tenaja]

As he said, the V8 engine is used, which compiles to native machine code (i.e. x86, ARM, etc)

[tj1010]

This is one of the earliest powerful tools I came across, but the license costs are steep and the most economical language is object pascal.

http://www.embarcadero.com/products/rad-studio

I'm looking at the Intel tool right now.

[the.weavster]

I'm looking at the Intel tool right now.

I'm intending to figure out a nice workflow between SpiderBasic and the XDK but I've got wrapped up in something else at the moment (and it's summer). It will be better once this feature request has been implemented anyway.

[tj1010]

I'm looking at the Intel tool right now.

I'm intending to figure out a nice workflow between SpiderBasic and the XDK but I've got wrapped up in something else at the moment (and it's summer). It will be better once this feature request has been implemented anyway.

I have a game done in SB. I basically did a 800x480 fixed borderless screen and put it in a iframe. I use PHP and SB/JS timers but no long-polling or websockets because I use cheap hosting for the back-end.

I'll probably eventually scale the screen using HD bitmaps and detection I didn't have time to research screen mode switching though. No way I'm going to try and hack SB css.

To me it's all about economics. This is the bottom line of doing stuff around markets and employers. SB is pretty good but I'd imagine it'd be hard to get on to IOS store or signed using a webview even if you put it all in a resource and don't use networking.

[TI-994A]

As he said, the V8 engine is used, which compiles to native machine code (i.e. x86, ARM, etc)

And as I've said, we've established that the underlying JavaScript engine for this new version is different. Either way, the statement holds true:

The JavaScript code runs atop an embedded Rhino/V8 Engine which acts as an interpreter to the Java environment. It is not compiled to Dalvik bytecode.

Rendering his post pointless; as always.