Is cross platform Delphi heading to the correct path?

The application's current market trend is going either to web or mobile...

1. web <> native application.

2. mobile <> not for native delphi application
- iPhone: only for c/c++ without VCL
- Andriod: only java
- Windows 7 Phone:  only managed code
0
ahmoy
5/13/2010 4:38:45 PM
embarcadero.delphi.non-tech 5933 articles. 1 followers. Follow

78 Replies
816 Views

Similar Articles

[PageSpeed] 51

> {quote:title=ahmoy law wrote:}{quote}
> The application's current market trend is going either to web or mobile...

Only for consumers. The business market is still almost entirely desktop, which means native Win32.

Try again with real logic.
0
Ken
5/13/2010 5:40:45 PM
> Only for consumers. The business market is still almost entirely desktop, which means native Win32.
> 
> Try again with real logic.

Partially agree, the business decision today is normally based on Web addons or ability to use "gadgets" like tables or smartphones.
0
Utf
5/13/2010 5:56:49 PM
Francisco J Ruiz Nuñez wrote:
>> Only for consumers. The business market is still almost entirely desktop,
>> which means native Win32.
>> 
>> Try again with real logic.
> 
> Partially agree, the business decision today is normally based on Web addons
> or ability to use "gadgets" like tables or smartphones.

I also see device being used in great proportion to support larger 
desktop/webtop applications.

--
Warm Regards,

Lee
0
Lee
5/13/2010 6:50:59 PM
ahmoy law wrote:

> 2. mobile <> not for native delphi application
> - iPhone: only for c/c++ without VCL
> - Andriod: only java
> - Windows 7 Phone:  only managed code

Android also support native code with the NDK:

http://developer.android.com/sdk/ndk/index.html

Jan Derk
0
Jan
5/13/2010 7:07:50 PM
Jan Derk wrote:

> > - Andriod: only java
> 
> Android also support native code with the NDK:

	And even without the NDK you are not restricted to Java. Just the JVM,
which isn't the same thing at all.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/13/2010 7:50:34 PM
> Android also support native code with the NDK:
> http://developer.android.com/sdk/ndk/index.html

You should read beyond the first line:

"The NDK allows you to implement *parts* of your applications using native-code languages"
"Please note that the NDK *does not enable you to develop native-only applications*. Android's primary runtime remains the Dalvik virtual machine."
0
Luigi
5/13/2010 8:13:33 PM
> 	And even without the NDK you are not restricted to Java. Just the JVM,
> which isn't the same thing at all.

The problem are the framework APIs, as it was in .NET for Delphi.NET - a solution like Prims cold make more sense, but then like .NET, why don't use the "native" language as well?
0
Luigi
5/13/2010 8:15:15 PM
> 1. web <> native application.

That's just part of the market. It is true that market is more fragmented than it was ten years ago, and native applications are less used, but check how many native applications you use and how many web based - and which tasks you perform with them.
0
Luigi
5/13/2010 8:18:35 PM
Luigi Sandon wrote:

> You should read beyond the first line:
> 
> "The NDK allows you to implement parts of your applications using
> native-code languages" "Please note that the NDK *does not enable you
> to develop native-only applications*. Android's primary runtime
> remains the Dalvik virtual machine."

From that I understand, you must have a Java class with the at least
the start up main function and from there call the main function of the
actual native code application. Would that work?

Doei RIF
0
Richard
5/13/2010 8:22:58 PM
Luigi Sandon wrote:

> The problem are the framework APIs, as it was in .NET for Delphi.NET
> - a solution like Prims cold make more sense, but then like .NET, why
> don't use the "native" language as well?

	Because I like Scala and Clojure a *lot* more than Java. Hell, I
prefer JavaScript over Java.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/13/2010 8:24:35 PM
Native code is the ASM of Android. You use it when you're forced to.
It would be foolish to write an entire app that way. Even Google
doesn't do this.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/13/2010 8:25:51 PM
Craig Stuntz wrote:

> Native code is the ASM of Android. You use it when you're forced to.
> It would be foolish to write an entire app that way. Even Google
> doesn't do this.

True, but at least they provide the option to use native code for code that
needs the best performance. That would be at least pretty much any game.

It makes no sense though to write a GUI with a few click options in native
code.

Jan Derk
0
Jan
5/13/2010 8:38:29 PM
Luigi Sandon wrote:

> > Android also support native code with the NDK:
> > http://developer.android.com/sdk/ndk/index.html

> You should read beyond the first line:
> "The NDK allows you to implement parts of your applications using native-code
> languages" "Please note that the NDK *does not enable you to develop
> native-only applications*. Android's primary runtime remains the Dalvik
> virtual machine."

I am aware of that. I just wanted to point out that in Android you are not
limited to non-native Java. You can write components that need the best
performance in native code.

Jan Derk
0
Jan
5/13/2010 8:40:20 PM
Craig Stuntz wrote:

> 	Because I like Scala and Clojure a lot more than Java. Hell, I
> prefer JavaScript over Java.

I may not be a Java fan either, but when writing for Android it makes the most
sense to use it, mainly because the whole ecosystem thinks and briefs java.
When discussing code samples they will be java. The documentation has Java
samples and the Google example applications are Java. If you want to share code
with others, it needs to be Java. etc. etc.

Jan Derk
0
Jan
5/13/2010 8:44:49 PM
Give it a year or two. People are fleeing Java for other languages
these days, even on the JVM.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/13/2010 8:47:03 PM
> 	Because I like Scala and Clojure a *lot* more than Java. Hell, I
> prefer JavaScript over Java.
> 

At this time all the smartphones support native code (except Windows Phone 7) and there are some initiatives for cross-platform usage. For example the simple directmedia layer library (SDL) is supported for almost all the platforms availables WinCE, SymbiamOS, iPHONE, Palm WebOS, Android and all the classic desktop platforms . This is the way most 3D games are ported in 30 days from one platform to another. The goal is to isolate the smartphone services api.

In the other side there are some initiatives for use a WebKit (the standard Palm Webos application model) where you make applications with Javascript, HTML5 and CSS. The result is very nice because of some web advantages like the V8 javascript compiler, hardware accelerated CSS and 3D CSS (in beta) and capabilities of local DB storage of HTML 5.
0
Utf
5/13/2010 9:16:03 PM
Luigi Sandon wrote:
>> 1. web <> native application.
> 
> That's just part of the market. It is true that market is more fragmented
> than it was ten years ago, and native applications are less used, but check
> how many native applications you use and how many web based - and which tasks
> you perform with them.

Agreed.  But it /is/ changing somewhat I think.

--
Warm Regards,

Lee
0
Lee
5/13/2010 11:41:31 PM
> {quote:title=Luigi Sandon wrote:}{quote}
> > 1. web <> native application.
> 
> That's just part of the market. It is true that market is more fragmented than it was ten years ago, and native applications are less used, but check how many native applications you use and how many web based - and which tasks you perform with them.

Well, let's see, I'm using a Web app now...

I would put the real fragmentation occurring in a much shorter timeframe, maybe 3 years. What happened 3 years ago? Oh, right, the introduction of the iPhone. So now we have not only the continued advance of Web apps but also a fragmented native app market. In some ways the iPhone and follow-on devices represent a resurgent native app market, but with a twist where nearly all of them function best when they're Web-enabled, or in some cases only function when connected to the Web. 

Thanks.

-Phil
0
Phil
5/14/2010 12:31:58 AM
> {quote:title=Jan Derk wrote:}{quote}

> 
> I may not be a Java fan either, but when writing for Android it makes the most
> sense to use it, mainly because the whole ecosystem thinks and briefs java.
> When discussing code samples they will be java. The documentation has Java
> samples and the Google example applications are Java. If you want to share code
> with others, it needs to be Java. etc. etc.
> 

If everybody had followed the same line of reasoning for Windows development, every application would have been written in C and Delphi would never have existed. Fortunately they didn't.

--
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com
0
Chris
5/14/2010 12:48:23 AM
> Well, let's see, I'm using a Web app now...

I am using it just because I am behind a company firewall. But any newsreader is much faster and practical than this web app.
 
> right, the introduction of the iPhone. 

Oh well, it happened much before, just the press didn't notice until Apple told them it was cool and they should talk about it to look cool...

>  In some ways the iPhone and follow-on devices represent a resurgent native app market, but with a twist where nearly all of them function best when they're Web-enabled, 

Not at all. Mamy useful smartphones applications works without internet connectivity. Have ever you found yourself using GPS features in an area with bad or no data coverage? Or being abroad where data connection can cost a lot?

> or in some cases only function when connected to the Web. 

Oh yes, the ubiquitous "social networking", if you're not connect to facebook or twitter you're noone...
0
Luigi
5/14/2010 8:37:41 AM
> If everybody had followed the same line of reasoning for Windows development, 

The difference is Windows has a very low level API (and a C API turns nicely into an ASM API), or a language-agnostic one (COM). A Java based API in different, because the VMs are built for the language, while usually compiled languages are built to be turned into machine code. Add a framework built not as low level calls, but as high-level language classes, and the difference is big.
0
Luigi
5/14/2010 8:43:16 AM
Ken White wrote:

> > {quote:title=ahmoy law wrote:}{quote}
> > The application's current market trend is going either to web or
> > mobile...
> 
> Only for consumers. The business market is still almost entirely
> desktop, which means native Win32.
> 
> Try again with real logic.


Ken,
  ahmoy was talking about trends, not the current situation. While true
that the business market is based around the desktop there is a huge
push to mobile working with mobile devices. In my area of business
there is about a 20:1 ratio of mobile to desktop users and the mobile
sector is still growing. The real spanner in the works is the lack of a
real business use mobile device that doesn't cost a fortune. We have
been using consumer windows mobile devices for years with great
success. Now the UK market has dried up as far as windows mobile goes.
The apple and android phones have a problem in so far as the capacitive
screen will not allow signature capture. There is a large mobile
business market out there for the taking. I wish Embarcadero would do
something to target android phones. I'm sure the mobile *business*
market in the uk is far bigger than the Mac or linux markets put
together.
  I would also agree with ahmoy that there is a trend towards web based
business applications. In fact most applications used by my clients are
web based. My company is probably the only one supplying a native
application. I feel this gives me a real advantage in terms of speed
and presentation but the trend is certainly towards web on the desktop
here in the UK.

Delphi is primarily for developing business applications. I can't help
but feel that the current roadmap with its mac os and social networking
focus is really leaning towards the consumer market. Things must be
different in the US.



-- 
Regards,
  Will
0
Will
5/14/2010 9:28:25 AM
Francisco J Ruiz Nuñez wrote:

> In the other side there are some initiatives for use a WebKit (the
> standard Palm Webos application model) where you make applications
> with Javascript, HTML5 and CSS. The result is very nice because of
> some web advantages like the V8 javascript compiler, hardware
> accelerated CSS and 3D CSS (in beta) and capabilities of local DB
> storage of HTML 5.

	Given the diversity of platforms, I personally think this is the way
to go for even many "non-web" platforms. You can add to your list a
full SQL server in HTML 5.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/14/2010 12:35:27 PM
Luigi Sandon wrote:

> A Java based API in different, because the VMs are built for the
> language, while usually compiled languages are built to be turned
> into machine code.

	I disagree, there. Languages like Scala and Clojure are *first-class*
JVM tools (the languages are designed *specifically* for the JVM), and
Java APIs look native there. There is nothing "foreign" about using a
Java API in Scala.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/14/2010 12:42:06 PM
> {quote:title=Luigi Sandon wrote:}{quote}
> 
> The difference is Windows has a very low level API (and a C API turns nicely into an ASM API), or a language-agnostic one (COM). A Java based API in different, because the VMs are built for the language, while usually compiled languages are built to be turned into machine code. Add a framework built not as low level calls, but as high-level language classes, and the difference is big.

That does not mean that the JVM isn't suited to other languages as well. It appears that an important factor is the degree of type-safety in the language. Consequently, Component Pascal has been demonstrated to be a good fit even though the original implementations generated native code for both Windows and the 68000 Mac. It also works well on .NET. Other possible candidates suggested are Scheme, Sather and Eiffel. For more info see: "Implementing Languages Other than Java on the Java Virtual Machine" by 
John Gough and Diane Corney:

http://plas.fit.qut.edu.au/gpcp/JVM.aspx

--
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System for Windows
http://www.astrobe.com
0
Chris
5/14/2010 12:53:52 PM
On 2010-05-13 12:38 PM, ahmoy law wrote:
> The application's current market trend is going either to web or mobile...


The current market for "apps" (things on your cell phone) and the market 
for people who write windows applications are completely disjoint, and 
always have been. The tools for writing a mobile app
are in a state of horrible confusion.   You use one SDK to write for
palm, another for blackberry, another for iPhone, and another still
for android. And that still leaves out Windows Mobile, and a few
of the minor JVM beasties.  You can no more target "mobile phones"
as a broad swipe, than you can target "video game consoles" broadly.

W
0
Warren
5/14/2010 1:47:46 PM
Hello,

but how would those apps interact with hardware of the phone like
Bluetooth? (e.g. directly initiating a device search and then a bonding
etc.)?

This would be vastly different on most systems.

Greetings

Markus
0
Markus
5/14/2010 5:21:38 PM
Am 14.05.2010 10:37, schrieb Luigi Sandon:
>> Well, let's see, I'm using a Web app now...
> 
> I am using it just because I am behind a company firewall. But any newsreader is much faster and practical than this web app.
>  

+1
0
Markus
5/14/2010 5:23:33 PM
> {quote:title=Warren Postma wrote:}{quote}
> On 2010-05-13 12:38 PM, ahmoy law wrote:
> > The application's current market trend is going either to web or mobile...
> 
> 
> The current market for "apps" (things on your cell phone) and the market 
> for people who write windows applications are completely disjoint, and 
> always have been. The tools for writing a mobile app
> are in a state of horrible confusion.   You use one SDK to write for
> palm, another for blackberry, another for iPhone, and another still
> for android. And that still leaves out Windows Mobile, and a few
> of the minor JVM beasties.  You can no more target "mobile phones"
> as a broad swipe, than you can target "video game consoles" broadly.

Yes, but that's a good thing for developers in that it creates opportunities. That fragmentation can help niche languages like ObjC and Delphi too. If they're agile and can identify a market where they fit and can get there in a timely fashion.

Thanks.

-Phil
0
Phil
5/14/2010 5:34:38 PM
Markus Humm wrote:

> This would be vastly different on most systems.

	Less so than you might guess. There are standard JS interfaces for
geolocation, e.g., and mobile browsers support them. Those items which
don't have standard interfaces are often standardized by, e.g.,
PhoneGap:

http://www.phonegap.com/

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/14/2010 5:48:37 PM
Am 14.05.2010 19:48, schrieb Craig Stuntz:
> Markus Humm wrote:
> 
>> This would be vastly different on most systems.
> 
> 	Less so than you might guess. There are standard JS interfaces for
> geolocation, e.g., and mobile browsers support them. Those items which
> don't have standard interfaces are often standardized by, e.g.,
> PhoneGap:
> 
> http://www.phonegap.com/
> 

Doesn't seem to contain what I need and it would also have to cover a
wide variety of APIs from different vendors, as e.g. on Windows Mobile
alone 4 different Bluetooth stacks are known to me.

Greetings

Markus
0
Markus
5/15/2010 4:40:37 PM
> {quote:title=ahmoy law wrote:}{quote}
> - iPhone: only for c/c++ without VCL
 
I assume you mean "Objective C" there ?
0
Marco
5/15/2010 11:28:01 PM
Hoi Will

> There is a
> large mobile business market out there for the taking. I wish
> Embarcadero would do something to target android phones.

It would be great if they one day do, but NOT UNTIL they have delivered
a Windows 64/32 bit compiler and a Linux (at least) server target.

We cannot afford to have Embarcadero delay these promised products even
further.

Currently the lack of 64 bit compiler is major issue for a smaller
group of Windows Delphi developers, but it is a major looming problem
for most Delphi Developers, once Microsoft will start the marketing
machine for 64-bit for desktop computing. This likely will happen some
month after MS releases SP1 for Windows 7.

The best we can hope for is that the recovery from the current
financial crises drag-out and hence delay major spending in Windows 7
and general PC upgrades ;-).

Doei RIF
0
Richard
5/16/2010 11:18:41 AM
Richard Foersom wrote:

 
> We cannot afford to have Embarcadero delay these promised products
> even further.
> 

  Well, my recollection is that back in the borland days compact
framework support was promised long before 64bit... It was never really
delivered. delphi.net had a preview compiler and Prism won't do forms
design (because the CF forms designer is hard coded to C#) . Now
compact framework looks dead.
  I can agree that a 64 bit compiler will become necessary. I'm not
sure it will be pushed by M$ in the windows 7 lifecycle though. Has
compiling to Linux Servers been promised? I thought it had just been
hinted at.
  If 64 bit is what comes first I won't be complaining. Although it
strikes me that the industry I'm in has far more to be made from mobile
over MAC/64bit/Linux. That said I can use Eclipse and Java (Sigh) to
produce android apps whereas there is no way at all to produce a 64 bit
delphi app.


-- 
Regards,
  Will honor
-----------------------------------------
http://www.cohesis.co.uk
0
Will
5/16/2010 6:18:40 PM
In article <242641@forums.embarcadero.com>, Warren Postma wrote:
> The current market for "apps" (things on your cell phone) and the market 
> for people who write windows applications are completely disjoint, and 
> always have been. The tools for writing a mobile app
> are in a state of horrible confusion.   You use one SDK to write for
> palm, another for blackberry, another for iPhone, and another still
> for android. And that still leaves out Windows Mobile, and a few
> of the minor JVM beasties.  You can no more target "mobile phones"
> as a broad swipe, than you can target "video game consoles" broadly.

Don't we know it. We have mobile apps for Pocket PC, Palm and iPhone. Both 
the Palm (OS3) and Pocket PC (up to Windows Mobile 6.5) apps are, or will 
be shortly, obsolescent as the new Palm Pre and (soon) Windows Phone 7 
devices use totally different development environments to their 
predecessors. All our investment in those tools and the required 
programming expertise is lost! Now we have to learn Java to produce an 
Android version! It's a pity we couldn't start off with a web app - 
unfortunately, its not an option for our apps.

Regards...Andrew
0
Andrew
5/17/2010 7:12:22 AM
Markus Humm wrote:

> Doesn't seem to contain what I need and it would also have to cover a
> wide variety of APIs from different vendors, as e.g. on Windows Mobile
> alone 4 different Bluetooth stacks are known to me.

	That's precisely the problem. "Native" development on Windows Mobile
means writing a different app for each device, then rewriting your app
-- perhaps from scratch -- for the next OS. "Native" mobile development
isn't maintainable.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/17/2010 12:38:32 PM
> The goal is to isolate the smartphone services api.

That's why Apple explicitly forbids those libraries now. And if it works, the other will follow.

> Javascript, HTML5 and CSS. The result is 

Very clunky code, IMHO. And it's funny while striving for longer battery life smartphone should waste power parsing, interpreting, compiling and rendering what should be native applications.
0
Luigi
5/17/2010 1:34:05 PM
Luigi Sandon wrote:

> And it's funny while striving for longer battery life smartphone
> should waste power parsing, interpreting, compiling and rendering
> what should be native applications.

	That's silly. The power cost of that is close to nothing compared with
the real draws on mobile devices.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/17/2010 2:26:07 PM
Marco van de Voort wrote:

> > {quote:title=ahmoy law wrote:}{quote}
> > - iPhone: only for c/c++ without VCL
>  
> I assume you mean "Objective C" there ?

	Both are allowed.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/17/2010 2:26:23 PM
Am 17.05.2010 14:38, schrieb Craig Stuntz:
> Markus Humm wrote:
> 
>> Doesn't seem to contain what I need and it would also have to cover a
>> wide variety of APIs from different vendors, as e.g. on Windows Mobile
>> alone 4 different Bluetooth stacks are known to me.
> 
> 	That's precisely the problem. "Native" development on Windows Mobile
> means writing a different app for each device, then rewriting your app
> -- perhaps from scratch -- for the next OS. "Native" mobile development
> isn't maintainable.
> 

But web development for cases where you need to access the local
hardware in some way is also not feasible! It would only solve the UI
part. Java is also no option because it doesn't existi on many devices
or has limitations and differences.

=> each vendor of mobile OS tries vendor lock in! That's bad, but afaik
currently theres no option around it.

Greetings

Markus
0
Markus
5/17/2010 6:07:28 PM
Am 17.05.2010 15:34, schrieb Luigi Sandon:
>> The goal is to isolate the smartphone services api.
> 
> That's why Apple explicitly forbids those libraries now. And if it works, the other will follow.
> 
>> Javascript, HTML5 and CSS. The result is 
> 
> Very clunky code, IMHO. And it's funny while striving for longer battery life smartphone should waste power parsing, interpreting, compiling and rendering what should be native applications.

+1

Greetings

Markus
0
Markus
5/17/2010 6:07:59 PM
Am 17.05.2010 16:26, schrieb Craig Stuntz:
> Luigi Sandon wrote:
> 
>> And it's funny while striving for longer battery life smartphone
>> should waste power parsing, interpreting, compiling and rendering
>> what should be native applications.
> 
> 	That's silly. The power cost of that is close to nothing compared with
> the real draws on mobile devices.
> 

Most web apps would be loaded directly from the web, wouldn't they? If
yes web access _does_draw_quite_some_power_.

Greetings

Markus
0
Markus
5/17/2010 6:08:51 PM
Markus Humm wrote:

> But web development for cases where you need to access the local
> hardware in some way is also not feasible! 

	That's just a missing interface, not an impossibility. That's why
there are projects / commercial tools like PhoneGap and Appcelerator.
They may or may not have what you need at present, but they're getting
better regularly, and PhoneGap in particular is open source, so you can
tweak it yourself if you already understand the hardware.

	This is not a difficult problem. It's a mostly solved problem.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/17/2010 6:40:08 PM
Markus Humm wrote:

> Most web apps would be loaded directly from the web, wouldn't they? If
> yes web access _does_draw_quite_some_power_.

	False premise. Actually two of them in one sentence -- not bad! First,
browser-based apps don't have to be web apps. Again, look at PhoneGap.
The whole point is to avoid native-code lock-in whenever possible.
Second, the reason that web browsing draws power is because you're
using the radio and the display, not because of the CPU. For evidence,
look at the Android power meter.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/17/2010 6:43:54 PM
> The power cost of that is close to nothing compared with
> the real draws on mobile devices.

Apple forbids Flash because it is power hungry too. And what Flash does? Flash could be heavier than HTML/CSS/Js, but they require anyway more processing power than plain native applications. Then wireless connections and the display can use more power, true, but why add more power to turn text files into usable code?
0
Luigi
5/17/2010 6:48:21 PM
Luigi Sandon wrote:

> Apple forbids Flash because it is power hungry too.

	Apple has given this as one of many reasons that they ban Flash, but
has never shown this (or many of the others) to actually be true. I
tend to presume that Apple's statements on Flash carry no weight on
their own.

> And what Flash does? 

	Current Flash on Apple mobile devices is native code.

> Then
> wireless connections and the display can use more power, true, but
> why add more power to turn text files into usable code?

	False premise; see above.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/17/2010 6:52:12 PM
> The whole point is to avoid native-code lock-in whenever possible.

Why? Some would like to avoid it, for other is not an issue at all, but exactly what they need. All Delphi developers worke in a strict native code lock-in.

> using the radio and the display, not because of the CPU. For evidence,

True. But as I said, the CPU will just add more power used. Especially when it comes to complex applications and you can't take advantage of the hardware itself - i.e. performing some operations in slow interpreted or maybe jitted code instead of accessing hardware accelerated features or highly optimized machine code. And the more they mask you from the hardware, the more you are hindered to use hardware features that may be available but not pusblished.
0
Luigi
5/18/2010 8:25:22 AM
Luigi Sandon wrote:

> Why? Some would like to avoid it, for other is not an issue at all,
> but exactly what they need. All Delphi developers worke in a strict
> native code lock-in.

	Have you ever /tried/ to support a "native" mobile app? Really?
Comparing it to Windows desktop is apples and oranges. I can expect
that 10 year old "native" Windows desktop apps will run just fine on
just about any system.

	By contrast, non-trivial "native" mobile apps, as a rule, *won't* run
on diffrerent hardware or OS versions -- even within the "Windows
Mobile" family. You generally need device * OS version # of binaries.

	It's completely insane to maintain a commercial app this way. Like I
said, it would be like writing a Windows desktop app in ASM.

> > using the radio and the display, not because of the CPU. For
> > evidence,
> 
> True. But as I said, the CPU will just add more power used.
> Especially when it comes to complex applications and you can't take
> advantage of the hardware itself - i.e. performing some operations in
> slow interpreted or maybe jitted code [...]

	Nonsense. This is just blather. You're making it up, and you have no
data to support this absurdity. The power draw in mobile devices is
easy to monitor. Try it.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/18/2010 12:36:44 PM
Am 17.05.2010 20:40, schrieb Craig Stuntz:
> Markus Humm wrote:
> 
>> But web development for cases where you need to access the local
>> hardware in some way is also not feasible! 
> 
> 	That's just a missing interface, not an impossibility. That's why
> there are projects / commercial tools like PhoneGap and Appcelerator.
> They may or may not have what you need at present, but they're getting
> better regularly, and PhoneGap in particular is open source, so you can
> tweak it yourself if you already understand the hardware.
> 
> 	This is not a difficult problem. It's a mostly solved problem.
> 

Hello,

how can JavaScript access native APIs?
Or do they use some sort of wrapper for each supported plattform, the
JavaScript detects plattform and then downloads and runs the apropriate
wrapper? I'm not too firm in JavaScrip so I don't know how extensible in
such directions it is.

Greetings

Markus
0
Markus
5/18/2010 5:48:04 PM
Markus Humm wrote:

> how can JavaScript access native APIs?

	I keep suggesting that you look at PhoneGap. It doesn't seem that you
have actually done this. :(

	Not only can you access the native APIs, you get to do it via an
interface which is leveled across mobile platforms (when necessary;
there are cases, as with geolocation, where browsers already support
this without modification), and you get the source code to see how they
did it.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/18/2010 5:53:44 PM
Hello,

where please did I imply that the incresed power consumption of web apps
comes entirely or even to a big part from CPU?

In case of web apps the majority as said by you will be from using the
radio (the display would also be used for local apps so it doesn't
count). For local apps web apps should draw slightly more power than
normal apps as the HTML etc. has to be interpreted first. Even if it
might only a tiny bit more such tiny bits here and there will add up one
fine day.

Greetings

Markus
0
Markus
5/18/2010 5:56:11 PM
Hello,

that's what the compact framework was for. Only issue is/was that it
doesn't support most of those hardware related APIs, not even the MS own
ones.

Greetings

Markus
0
Markus
5/18/2010 5:57:44 PM
Markus Humm wrote:

> that's what the compact framework was for.

	Sort of, but it didn't do it very well. E.g., the code-signing
requirements were different for every version.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/18/2010 6:08:49 PM
Markus Humm wrote:

> where please did I imply that the incresed power consumption of web
> apps comes entirely or even to a big part from CPU?

	Luigi did. I read your post as agreeing with him. Apologies if that's
wrong, and you don't.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/18/2010 6:10:22 PM
Am 18.05.2010 19:53, schrieb Craig Stuntz:
> Markus Humm wrote:
> 
>> how can JavaScript access native APIs?
> 
> 	I keep suggesting that you look at PhoneGap. It doesn't seem that you
> have actually done this. :(
> 
> 	Not only can you access the native APIs, you get to do it via an
> interface which is leveled across mobile platforms (when necessary;
> there are cases, as with geolocation, where browsers already support
> this without modification), and you get the source code to see how they
> did it.
> 

I already had a short look. But only a short one as unfortunatelly my
time is quite limited these days.

Greetings

Markus
0
Markus
5/19/2010 5:30:22 AM
Am 18.05.2010 20:08, schrieb Craig Stuntz:
> Markus Humm wrote:
> 
>> that's what the compact framework was for.
> 
> 	Sort of, but it didn't do it very well. E.g., the code-signing
> requirements were different for every version.
> 

Might be but that's a issue of MS constantly fiddling around with
working solutions thus creating a mess.

Greetings

Markus
0
Markus
5/19/2010 5:31:09 AM
Markus Humm wrote:

> Might be but that's a issue of MS constantly fiddling around with
> working solutions thus creating a mess.

	Not just MS. Have you *ever* seen a phone platform where this wasn't
true for unmanaged code? (I'm counting the iPhone as "managed" here,
since it severely limits what you can access in the hardware, even
though the code itself is "native.")

	Also, except for JavaScript, have you *ever* seen any tool which would
reliably work cross-platform on phones?

	If you want to work freely, outside the dictates of phone
manufacturers, HTML and JavaScript is the *only* choice. It's also
*much* more capable than most people presume.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
5/19/2010 12:41:25 PM
> Yes, but that's a good thing for developers in that it creates opportunities. That fragmentation can help niche languages like ObjC and Delphi too.
 >If they're agile and can identify a market where they fit and can get 
there in a timely fashion.


A small team that builds Embarcadero products can not feasibly build a 
cross-platform compiler for twelve different CPUs and toolkits,
plus a "VCL for smartphones" that operates on the various disjoint 
environments, especially not for the platforms that actually matter
(iPhone, where Apple will block all non-objective-C/cocoa tech)
and Android (where non-native is required for the core application,
not including the native extensions).  The same kind of issues
will exist on WebOS/Palm, Windows 7 Mobile, etc.

It's not an opportunity, it's just an opportunity-cost.   Going
after mobile will allow someone else to eat Delphi's cross
platform lunch, on classic desktop/server platforms (mac os x, linux).

The strategy adapted by Embarcadero was carefully devised by
a whole bunch of very smart people.  So, in short,
they are doing the right things to grow Delphi.

Go team.

W
0
Warren
5/20/2010 9:02:27 PM
Craig Stuntz wrote:
> Luigi Sandon wrote:
> 
>> Apple forbids Flash because it is power hungry too.
> 
> 	Apple has given this as one of many reasons that they ban Flash, but
> has never shown this (or many of the others) to actually be true. I
> tend to presume that Apple's statements on Flash carry no weight on
> their own.
> 
>> And what Flash does? 
> 
> 	Current Flash on Apple mobile devices is native code.

 From Jobs' explanation 
(http://news.cnet.com/8301-30685_3-20003742-264.html): native code is 
still worse than H.264 which can be accelerated with special hardware.

My personal experience is from the live broadcast by YLE, 
(areena.yle.fi), which used to require Windows Media Player, but is 
based on Flash nowadays, because that is cross-platform: as a result my 
hardware (Dell Latitude 830) cannot decode it full screen with a decent 
quality any more.
0
Jouni
5/30/2010 8:16:29 PM
[snip]
> 
>  From Jobs' explanation 
> (http://news.cnet.com/8301-30685_3-20003742-264.html): native code is 
> still worse than H.264 which can be accelerated with special hardware.
> 
> My personal experience is from the live broadcast by YLE, 
> (areena.yle.fi), which used to require Windows Media Player, but is 
> based on Flash nowadays, because that is cross-platform: as a result my 
> hardware (Dell Latitude 830) cannot decode it full screen with a decent 
> quality any more.

And what makes you think Adobe couldn't come up with any means to use
hardware acceleration too?

I don't advocate for Flash, but while trying to keep off Flash from the
iPhone/iPad Apple threw out the water with the complete bath! They
simply badly formulated the corresponding paragraph and do not want to
admit that some rules set up there are simply nonsense (C-languages only
for instance).

Greetings

Markus
0
Markus
5/31/2010 6:41:52 PM
> {quote:title=Warren Postma wrote:}{quote}
> A small team that builds Embarcadero products can not feasibly build a 
> cross-platform compiler for twelve different CPUs and toolkits,
> plus a "VCL for smartphones" that operates on the various disjoint 
> environments, especially not for the platforms that actually matter
> (iPhone, where Apple will block all non-objective-C/cocoa tech)
> and Android (where non-native is required for the core application,
> not including the native extensions).  The same kind of issues
> will exist on WebOS/Palm, Windows 7 Mobile, etc.
> 
> It's not an opportunity, it's just an opportunity-cost.   Going
> after mobile will allow someone else to eat Delphi's cross
> platform lunch, on classic desktop/server platforms (mac os x, linux).
> 
> The strategy adapted by Embarcadero was carefully devised by
> a whole bunch of very smart people.  So, in short,
> they are doing the right things to grow Delphi.
> 
> Go team.
> 
> W


I absolutely agree with this. 3rd party tools for programming for mobile devices - in my opinion it's a waste of time. Either learn the native tools for that mobile platform (XCode for iPhone), or go home.

I've spent the last 2 years developing a iPhone app ()a pretty successful one). When I program it, I do a final debugging on an iPhone, not in the simulator (actually I have 2 devices to quickly test 2 major version of iPhone OS) I've seen lots of bugs that happened only on iPhone - everything was fine on the simulator. On the other hand, I do a lot of test runs and debugging in the simulator, because it's much faster that way. So, if Embarcadero makes an iPhone tool, they should make an iPhone simulator 
and also support debugging on iPhone?! And they should do that for every other mobile platform?! Looks like total nonsense.

Mac OS X is on the rise. Mac users pirate software less then PC users - they usually buy software. Many developers want to make their DESKTOP apps cross-platform (PC + Mac) - I'm one of them. I'm waiting for cross platform Delphi, and I hope that it's a good one...

I've read a rumor that Microsoft is developing a cross-platform tool (in Visual Studio) that will target Mac OS - hopefully Embarcadero manages to release cross-platform Delphi on time, and prices it right...
0
Sergiy
5/31/2010 8:35:45 PM
Markus Humm wrote:

> And what makes you think Adobe couldn't come up with any means to use
> hardware acceleration too?

Nothing. Are they going to?

I simply referred to the current explanation that I have seen. I take no 
sides in their quarrel, except my own experience. I still do not use any 
Apple device, myself.
0
Jouni
6/1/2010 7:43:52 AM
Jouni Aro wrote:

> Nothing. Are they going to?

	Unlikely, as they know full well that Apple would invent a new reason
to not lift the ban.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
6/1/2010 12:53:43 PM
> {quote:title=Will Honor wrote:}{quote}
 > Ken,
>   ahmoy was talking about trends, not the current situation. While true
> that the business market is based around the desktop there is a huge
> push to mobile working with mobile devices. In my area of business
> there is about a 20:1 ratio of mobile to desktop users and the mobile
> sector is still growing. 

Usage or development?  Mobile usage is growing, but much faster than mobile development.

That is growing too, but much slower.

 > The apple and android phones have a problem in so far as the capacitive
> screen will not allow signature capture. There is a large mobile
> business market out there for the taking. I wish Embarcadero would do
> something to target android phones. I'm sure the mobile *business*
> market in the uk is far bigger than the Mac or linux markets put
> together.

I don't think "targeting android" (or IPhone for that matter) will be the silver bullet that will
propel mobile development.

One would need a offering that models a certain business application well. Both target, 
as library, as integration with servers. The latter because I don't think there will be much
demand for custom _busines_ software development without connectivity to business systems/servers.

>   I would also agree with ahmoy that there is a trend towards web based
> business applications. In fact most applications used by my clients are
> web based. My company is probably the only one supplying a native
> application. I feel this gives me a real advantage in terms of speed
> and presentation but the trend is certainly towards web on the desktop
> here in the UK.

I've the feeling that movement is slowly reaching its saturation point. But at a relatively
high web-app level, I agree.
 
> Delphi is primarily for developing business applications. I can't help
> but feel that the current roadmap with its mac os and social networking
> focus is really leaning towards the consumer market. Things must be
> different in the US.
 
The US always had a higher mac% than Europe afaik. But yes, it does not seem
as tailored to business use as you would expect from such expensive package.
0
Marco
6/1/2010 1:28:00 PM
Marco van de Voort wrote:

> > {quote:title=Will Honor wrote:}{quote}
>  > Ken,
> >   ahmoy was talking about trends, not the current situation. While
> > true that the business market is based around the desktop there is
> > a huge push to mobile working with mobile devices. In my area of
> > business there is about a 20:1 ratio of mobile to desktop users and
> > the mobile sector is still growing. 
> 
> Usage or development?  Mobile usage is growing, but much faster than
> mobile development.
> 
> That is growing too, but much slower.

  I was referring to usage. I think the barrier to more developers
getting into mobile development is the percieved difficulty of
programming these devices. I wrote an app some years ago for Palm OS,
which frankly was a nightmare. Things are much improved now. Compact
framework is very capable but still lacks key api calls which are left
to p/invoke. Android looks good too, even though I hate Java. The other
major barrier is longevity of the platforms. Palm OS went south, now it
looks like CF.net is on it's way out. Nothing seems to last long enough
to base a business around.


> 
>  > The apple and android phones have a problem in so far as the
> capacitive
> > screen will not allow signature capture. There is a large mobile
> > business market out there for the taking. I wish Embarcadero would
> > do something to target android phones. I'm sure the mobile business
> > market in the uk is far bigger than the Mac or linux markets put
> > together.
> 
> I don't think "targeting android" (or IPhone for that matter) will be
> the silver bullet that will propel mobile development.

It won't, but it would be a good start. Android is looking like the
only credible business platform in the uk. Windows mobile is no longer
available (apart from a single phone HTC HD2). Apple is too fashionable
to be a business phone, too many would go missing. that really leaves
android as the only OS with the right capabilities.

> 
> One would need a offering that models a certain business application
> well. Both target, as library, as integration with servers. The
> latter because I don't think there will be much demand for custom
> busines software development without connectivity to business
> systems/servers.

  Yes any offering would really need a way to persist data on the
device, communicate back to servers in an efficient manner and should
be robust. My company already has this bit sewn up using a combo of
remobjects and delphi on the server side makes the mobile app an
extension of the desktop app. Something built in to delphi would be
good though.


> 
> >   I would also agree with ahmoy that there is a trend towards web
> > based business applications. In fact most applications used by my
> > clients are web based. My company is probably the only one
> > supplying a native application. I feel this gives me a real
> > advantage in terms of speed and presentation but the trend is
> > certainly towards web on the desktop here in the UK.
> 
> I've the feeling that movement is slowly reaching its saturation
> point. But at a relatively high web-app level, I agree.

  I think that with the increasing capability of web applications the
move towards web based apps is not at saturation point yet.


>  
> > Delphi is primarily for developing business applications. I can't
> > help but feel that the current roadmap with its mac os and social
> > networking focus is really leaning towards the consumer market.
> > Things must be different in the US.
>  
> The US always had a higher mac% than Europe afaik. But yes, it does
> not seem as tailored to business use as you would expect from such
> expensive package.


Yes, it's a shame really.





-- 
Regards,
  Will honor
-----------------------------------------
http://www.cohesis.co.uk
0
Will
6/1/2010 4:42:42 PM
Hello,

to close a plattform like Apple does (at least with the reasons they
officially state) is utter nonsense.

They even censor images in newspapers. What will be censored next? Apple
is no content provider! So it's not theirs to censor. Or does your local
newsagent censor the newspapers he offers as well? You can freely decide
to buy a certain newspaper/magazine or not purchase it because of some
content it contains. And even if you bought it you can skip the contents
you do not like. But contents you do not receive has already been
skipped for you by somebody else, even if you would have liked to get
that content!

Greetings

Markus
0
Markus
6/1/2010 6:19:37 PM
> {quote:title=Markus Humm wrote:}{quote}
> to close a plattform like Apple does (at least with the reasons they
> officially state) is utter nonsense.
<snip>
OK, we get the message, Marcus. Apple is evil. Apple can't be trusted. And you'll feel obligated to say that every time somebody mentions that they see potential for targeting Apple customers.

Do I consider Apple to be trustworthy? Heck no! Do I agree with all that they've done lately? Heck no!

On the other hand, like many Delphi users, I have the same love/hate relationship with Microsoft, and the same distrust of them. Unlike some Delphi users, I'm not in denial that I'm also a Microsoft customer, and that there's no way to use Delphi without also being a Microsoft customer, and (up until now,discounting the briefly-supported Kylix, and discounting web-based OS-neutral apps) no way to develop applications for others to use without indirectly encouraging those others to be Microsoft customers.



Do I personally plan to target Apple products? Nope,no plans for that, since my company supports only PCs running Microsoft Windows.

But I trust Embarcadero to be wise and alert enough to proceed with both eyes open,and back out of any deals that would be harmful to them or their customers.  I trust Delphi developers to do the same.
--
Rick Carter
Chair, Delphi/Paradox SIG, Cincinnati PC Users Group
0
Rick
6/2/2010 5:04:37 AM
Craig Stuntz wrote:
> Jouni Aro wrote:
> 
>> Nothing. Are they going to?
> 
> 	Unlikely, as they know full well that Apple would invent a new reason
> to not lift the ban.

Well, I would only be interested in H.264 streaming in Windows/Linux at 
the moment. :)
0
Jouni
6/2/2010 7:42:12 AM
> {quote:title=ahmoy law wrote:}{quote}
> The application's current market trend is going either to web or mobile...
> 
> 1. web <> native application.
> 
> 2. mobile <> not for native delphi application
> - iPhone: only for c/c++ without VCL
> - Andriod: only java
> - Windows 7 Phone:  only managed code

98% of the market is Native Desktop Development. More and more 64 bit.
0
Ralf
6/2/2010 12:17:40 PM
Hello,

I mostly agree with you. The difference is that MS doesn't censor apps
written for their OS or content provided to their users. (they do other
bad things on the other hand)

Greetings

Markus
0
Markus
6/2/2010 6:03:29 PM
Hello,

Ralf Stocker wrote:

> 98% of the market is Native Desktop Development. More and more 64 bit.

87.5% of all statistics are made up.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
6/2/2010 7:10:06 PM
> 
> 98% of the market is Native Desktop Development. More and more 64 bit.

Which market? The market for desktop applications?
0
Craig
6/3/2010 12:41:05 AM
Ralf Stocker wrote:


> 98% of the market is Native Desktop Development. More and more 64 bit.

  Where did you get that statistic from? in no way does that reflect my
experience.


-- 
Regards,
  Will honor
-----------------------------------------
http://www.cohesis.co.uk
0
Will
6/3/2010 7:54:18 AM
> {quote:title=ahmoy law wrote:}{quote}
> The application's current market trend is going either to web or mobile...
> 
> 1. web <> native application.
> 
> 2. mobile <> not for native delphi application
> - iPhone: only for c/c++ without VCL

Supported by lazarus. So don't see why Delphi couldn't

> - Andriod: only java

Native client reared its head there recently too.

> - Windows 7 Phone:  only managed code

Can't load that much on it without telco's permission (and cut) anyway. -Phone is only a very specialistic programming target.
0
Marco
6/8/2010 11:18:41 AM
Am 08.06.2010 13:18, schrieb Marco van de Voort:
>> {quote:title=ahmoy law wrote:}{quote}
>> The application's current market trend is going either to web or mobile...
>>
>> 1. web <> native application.
>>
>> 2. mobile <> not for native delphi application
>> - iPhone: only for c/c++ without VCL
> 
> Supported by lazarus. So don't see why Delphi couldn't
> 

Hello,

but nowdays no longer allowed by (stupid) Apple as the new iPhone
developer licence only allows C, C++, Objective-C or web apps with
JavaScript.

Bad, isn't it?

Greetings

Markus
0
Markus
6/10/2010 9:11:10 PM
> {quote:title=Phil Hess wrote:}{quote}
> > {quote:title=Luigi Sandon wrote:}{quote}
> > > 1. web <> native application.
> > 
> > That's just part of the market. It is true that market is more fragmented than it was ten years ago, and native applications are less used, but check how many native applications you use and how many web based - and which tasks you perform with them.
> 
> Well, let's see, I'm using a Web app now...
> 
ks.
> 
> -Phil

However, the app that the web app is running in is a desktop app.  (the browser cannot be a web app, by definition).   :)
0
Phillip
6/11/2010 3:15:45 AM
> {quote:title=Markus Humm wrote:}{quote}
> Hello,
> 
> I mostly agree with you. The difference is that MS doesn't censor apps
> written for their OS or content provided to their users. (they do other
> bad things on the other hand)
> 
> Greetings
> 
> Markus

Apple censors my apps on my iMac?  (ok, the iPhone).  If the iPhone wasn't popular, you probably wouldn't care about it.  If Microsoft censors content on WIndows Mobile, you would never know, as its inconsequential at this time
0
Phillip
6/11/2010 3:18:54 AM
Hello,

yep. But Apple might get trouble with this as well, as some US state
institutions are looking into that matter now.

Greetings

Markus
0
Markus
6/14/2010 8:16:38 PM
Reply:

Similar Artilces:

Delphi and Delphi for .Net
It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only. Your information is great appreciated, Inung On 2011-06-21 18:20:17 +0100, Inung Huang said: > It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. > I would like to know is it true all .Net application is slower than > Win32 native applicaiton or it is Delphi for .Net only. If you are only running the code in the application once then, yes, yo...

Delphi Prism and Cross-Platform
I own a copy of Oxygene . I only used it for some ASP.NET developement and never really looked at its Mono integration. Now its going to be shipped under a new brand with some new features. Now I wonder to what level we'll be able to deploy cross platform applications. Today I started a new app in Oxygene but couldn't figure out how to target mono. There are separate project templates under MonOxide category called Cocoa(Tiger), Cocoa(Leopard), WinForms (MAC OS X) and GTK#. 1) Can I start a new Windows Forms project and target it for all platforms? or 2) Should I s...

Delphi XE
I sure hope I'm wrong but I don't see any mention or even clues about the expected cross-platform support in Delphi 2011. In the first sneak peak video, we see the following: 1) When creating a new project in Delphi XE, the menu gives the same old options: "Package - Delphi", "Unit - Delphi", "VCL Forms Application - Delphi", "Form - Delphi". The absence of a "[Cross Platform VCL] Application - Delphi" is conspicuous. 2) In the closing screen, it lists all the products in RAD Studio XE. For the description for Delphi, it says, ...

Delphi Cross Platform Game Development [Edit]
A little survey Would anyone be interested in a cross platform (windows, mac, linux) game development toolkit with Delphi/FreePascal compiler compatibility? This toolkit would take care of the boiler plate platform code to get a window up, change window/display states, give you mouse, keyboard, and joystick feedback, and abstract working with files, sockets, xml, audio, and 2D/3D graphics. Programs would be quite small and compact. They would also be stand alone binaries able to run with little to no dependencies. Possible program applications might include: Cross platform gam...

Delphi 2011 and cross platform debugging / testing
We heard some clues about Delphi 2011 in this forum. One of them was "design it in Windows (IDE), run it everywhere (Windows, Linux and Mac)". Does anybody know how we will debug and/or test cross platform applications from Delphi IDE? (I think that built in or plugged virtual machines may be the best solution from developers.) Hür Hur Akdulger wrote: > We heard some clues about Delphi 2011 in this forum. > One of them was "design it in Windows (IDE), run it everywhere > (Windows, Linux and Mac)". > > Does anybody know how we will...

Delphi Prism for cross-platform projects: Started a project
As I suspected Delphi Prism is ideal for my purposes. Since I am a hobby linguist, my program is a Hebrew verb conjugation application. I am trying to formulate all necessary rules including all exceptions in Pascal. Last year I implemented a working prototype in Objective-C. http://web.mac.com/ajbrehm/Home/Software.html It worked, but wasn't portable; and Cocoa is a bit of a hassle when it comes to string manipulation since it offers no native support for unicode regular expressions. I can re-use the GUI. This is how I am planning to proceed, slowly, of course, since I am lazy an...

SEPA components for Delphi with Source Code (Delphi 5
Hi all, in the european union change next year the Bankingformat to the SEPA Format. All peoples and companies must change the bankingssoftware and the costumer data form acountnummers in the new IBAN and BIC numbers. See: http://www.arma-it.de/shop/artikelueber.php?wgruppeid=211&wgruppe_offen=211 Functions: - generate SEPA XML'S - Calc IBAN - BIC Database (DE,AT and CH) Questions: vertrieb@arma-it.de PS: Bankinssoftware for Develpoers (Germany only) http://www.arma-it.de/shop/artikelueber.php?wgruppeid=212&wgruppe_offen=212 El 26/10/13 21:38, A...

from delphi 6 to delphi 2010
Hi. It is possible, with component RX, dxforumlibrary, InfoPower3000Pro, StringAlignGrid. Accepts communication BDE. Thank by comments. excequiel arostica wrote: >Hi. > It is possible, with component RX, dxforumlibrary, >InfoPower3000Pro, StringAlignGrid. Accepts communication BDE. > >Thank by comments. Rx is dead and sources are taken over by jcl/jvcl. I dont know about the rest of the components and i have no experiences with bde over the last 9 years. excequiel arostica wrote: > Hi. > It is possible, with component RX, dxforumlibrary,...

Delphi and virus, or virus and Delphi.
Hi all. There is some discussion about a 'new' virus, that targets Delphi (and developers). The article is in danish: <http://www.version2.dk/artikel/11833-delphi-udviklere-jages-af-ny-type-malware> but refers to this article: <http://news.cnet.com/8301-27080_3-10312628-245.html> From the Danish article POV, it seems like Delphi itself is vunerable, which is not true. As far as i can see, is the attack vector, injection of (source) code in the 'Sysconst' unit. What's going on? -- Best regards Stig Johansen Perhaps checking other thre...

Delphi XE / Delphi 2010
Hello! I noticed that Embarcadero® Delphi® 2010 Version is not on the list of products on Embarcadero page. Or is it still possible to buy it? Will RAD Studio XE compile programs written in Delphi 2010 without problems.? Thanks. Am 13.09.2010 09:04, schrieb Petra Nemec: > Will RAD Studio XE compile programs written in Delphi 2010 without problems.? As always you will probably have to recreate the projects as the import is still a bit -- special. Christian Hello! Does anybody know if it is still possible to get a Delphi2010 trial version (if yes where)? ...

Cross-Platform Delphi
All current versions of Windows NT can run x86 code. Obviously 32 bit Windows can. 64 bit Windows uses either compatibility mode (x64) or a built-in (into Windows) emulator (IA-64). A 64 bit (i.e. x64) compiler would be useful but isn't strictly needed for crossplatform purposes in the Windows world. Most installations of Mac OS X can run x86 code. I am pretty sure support for PowerPC is not required for new developer tools. But Linux is all over the place. Most Linux installations can run x86 code. This includes x86, x64 and IBM PowerPC installations. But software deploymen...

ANN: RealThinClient W/A Framework for cross-platform development with Delphi
A new update for the RealThinClient SDK (v3.11) has been released. RTC Web Applications Framework (included in the RealThinClient SDK 3.11) is now compatible with Delphi for Windows *and* Lazarus/FPC for Windows, Linux and MacOSX. RTC W/A Framework is very flexible and straight-forward, so that new components for cross-platform development can be added by anyone experienced enough in Delphi, but the purpose of this new framework is not to write components, it is to allow developers to use ready-made components for rapid rich cross-platform internet application development. An...

Delphi 2007 to Delphi 7
I've written a class in Delphi 2007 that is not supported in Delphi 7. What would be the best way to achive what I've done in Delphi 2007 in Delphi 7? Thanks, Tom type BondConstants = class { Bond Types } type BondType = record const TREASURY = 3; AGENCY = 0; CORP = 1; MUNI = 2; SBA = 5; MBS = 4; CMO = 6; end; { Day Count Methods } type DayCount = record const ACTUAL_360 = 2; ACTUAL_365 = 1; ACTUAL_ACTUAL = 1; d30_360 = 0; ...

Delphi 7 to Delphi XE2
Hi, Still using that old workhorse, Delphi7, but am going to the conference in London hosted by Embarcadero on Delphi XE2. Although I would like to "move with the times" and am keen to get the UNICODE and 64-bit support offered by the latest IDEs, I confess to being more than a little scared about all the UNICODE/String/AnsiString and 32/64 bit issues I'm probably going to fall over. Anyone recently upgraded from Delphi7 to one of the latest Delphi IDEs? Thanks, Alain On 03/02/2012 08:55, Alain Dekker wrote: > Still using that old workhorse, Delphi7, but...

Web resources about - Is cross platform Delphi heading to the correct path? - embarcadero.delphi.non-tech

Platform - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...

Woden bus interchange platform closures in place
Urgent maintenance work has forced the closure of three Woden bus interchange platforms after peak hour on Tuesday morning.

How Anomaly Shanghai Built Its Own Content Platform in China
... the start of the films, the Anomaly logo flashes on the screen. The films are part of the agency's intellectual property play a content platform ...

Medium: An Ideal Content Marketing Platform?
... takes a look at why Medium might be the perfect choice for content marketing. For those unfamiliar with Medium , it’s a blogging platform with ...

Bank Simpanan intros virtual teller technology on Cisco platform
MIS Asia Bank Simpanan intros virtual teller technology on Cisco platform ATM Marketplace (press release) Malaysia's Bank Simpanan Nasional, ...

Power struggles between the biggest mobile platforms and the underdogs that are gaining ground
Google's Android and Apple's iOS dominate the smartphone platform market, controlling a combined 95.7% of the installed base in the US. But the ...

How three old-school companies became digital platform players
For more than 120 years, McCormick & Co. seasoned its growth by adding new products, slowly simmering its spices, sauces and packaged foods into ...

Transform your mobile into a full-on gaming platform
The more our phones become a platform for high quality gaming, the less adequate the touch screen feels for keeping up. With the Phonejoy GamePad ...

DC Official: Metro Platforms Are Too Crowded And It Is Putting People In Danger
DC Official: Metro Platforms Are Too Crowded And It Is Putting People In Danger

Showtime Previewing ‘Shameless’ & ‘Billions’ Premieres On Multiple Platforms
Demonstrating the increasing importance of the network’s original programming in bringing in new customers, Showtime will be providing subscribers ...

Resources last updated: 12/30/2015 3:59:54 AM