Apple to Announce 3rd Party iPhone App Development?

[Transeau]

a Razr? What do your friends do for a living? Most of mine would shrivel up and die without their precious blackberry or treo. Besides all the other points being made in this thread, Apple drastically needs to get *some* type of mobile word/excel support, outlook sync, enterprise email compatibility (exchange), and enterprise WPA2 wifi security compatibility. With those features, can you imagine the huge business smartphone market that would open up?

They are people like me, with a 3.5G (HSDPA for those that don't know there there is life beyond EDGE and 3G) ExpressCard or Mini PCIe card in our notebooks. My phone has support for what I need in a pinch. (email, web, Remote Desktop and ssh) But this is way off topic...

Most of my friends prefer NOT to be "in touch" that easy. In this industry, we are in constant contact, when we get in our cards, or go to dinner, we prefer not to be reachable THAT easy.

That said, if a server goes down, we receive a simple sms with the details. (a RAZR does that just fine) Then pull out the MBP and pop in the XU870 and fix it.

So, yes... I can live with a simple razr. as to the people I work with

 

[goosnarrggh]

You know whats ever worse if true, Christian? When you look up the model number of the ARM chip running the iphone, it says it has HARDWARE support for running java bytecode natively. Now unless they made a custom chip for Apple and used the same model number or removed/disabled the java support or something, Native java bytecode support could be sitting right now in the iphone.
I can't even imagine what that would be like. Has anyone seen anything like this before where a chip can run java bytecode natively? Does anyone know if this capability is truly in the iphone processor? What did the tear down people say?

It's not unheard of for high-end embedded application CPUs to include a native Java bytecode interpreter built in hardware. What isn't included in hardware, though, is any of the basic class libraries which would be required to do anything interesting with Java bytecode or to interact with any components of the hosting application or operating system.

A good portion of the J2ME would still need to be ported in order to provide those class libraries. And even if native applications are ever able to achieve Apple's blessing, there'd still be little incentive for Apple to spend any time developing any of those class libraries, because OS X's built-in API's should be more than adequate, and in such a small hardware ecosystem, cross-platform compatibility is of questionable value.

 

[cwolves]

Multitouch gestures/arbitrary input recognized by javascript? I highly doubt it.
This is one of the main points of contention I have with web apps (besides the slooooooooooow execution of javascript, lack of accelerated graphics, dependence on the internet, inability to receive phone calls while using the apps, etc)

Why? Simply give access to two "mouse cursors" and voila you have full multi-touch support. Leave it up to developers to create libraries to recognize gestures, etc.

 

[winterspan]

It's not unheard of for high-end embedded application CPUs to include a native Java bytecode interpreter built in hardware. What isn't included in hardware, though, is any of the basic class libraries which would be required to do anything interesting with Java bytecode or to interact with any components of the hosting application or operating system.

A good portion of the J2ME would still need to be ported in order to provide those class libraries. And even if native applications are ever able to achieve Apple's blessing, there'd still be little incentive for Apple to spend any time developing any of those class libraries, because OS X's built-in API's should be more than adequate, and in such a small hardware ecosystem, cross-platform compatibility is of questionable value.

Thanks for the info, I have no experience in the embedded market.
When you say the J2ME libraries would have to be ported, do you mean ported to the ARM architecture or "ported" as in interfaced with OSX?
Wouldn't the former be unnecessary since the chip can run the bytecode natively? Bytecode is the same for all platforms, correct? kinda of like MSIL code when talking about the .NET platform?
If Im wrong on that, wouldn't there already exist those J2ME libraries since so many cellphones/pdas (some of these being ARM?) have mobile java runtimes?

I appreciate the help...

 

[winterspan]

Why? Simply give access to two "mouse cursors" and voila you have full multi-touch support. Leave it up to developers to create libraries to recognize gestures, etc.

it just seems to me like that would be alot of (unnecessary) work to modify the JS runtime to support that. And with the javascript performance pretty slow, I wonder if a multitouch gesture such as a "pinch" would be so unresponsive it wouldn't even be worth it. Those type of user interface features have to run almost seamless or it will ruin the "illusion" of control in your brain...
But I don't know, maybe they will do something like that. It still seems much easier to just create a *** secure sandbox with access to a subset of the iphone APIs.. all the hard stuff is already written -- let people jump in and add the innovation...

 

[winterspan]

They are people like me, with a 3.5G (HSDPA for those that don't know there there is life beyond EDGE and 3G) ExpressCard or Mini PCIe card in our notebooks. My phone has support for what I need in a pinch. (email, web, Remote Desktop and ssh) But this is way off topic...

Most of my friends prefer NOT to be "in touch" that easy. In this industry, we are in constant contact, when we get in our cards, or go to dinner, we prefer not to be reachable THAT easy.

That said, if a server goes down, we receive a simple sms with the details. (a RAZR does that just fine) Then pull out the MBP and pop in the XU870 and fix it.

So, yes... I can live with a simple razr. as to the people I work with

First of all, I don't know if most people do that or not, but I don't call HSDPA/HSUPA at least in their lower speed incarnations "3.5G". 3G itself seems more fitting. Although I guess they do try and get away with calling EDGE "3G" sometimes. I have a CDMA phone, so EV-DO is "3G" for me.
Since only EVDO and HSPA have what I would call "broadband" speeds, I usually refer to them as 3G.

I have used EVDO rev A. express cards, and they seems to work well. I'm sure HSDPA cards work just as good, although without HSUPA, Im sure the upload side would be miserable. But as a replacement for an Iphone/smartphone, I would ask if you drive/take a subway/walk to work and to get around, since you apparently carry a small laptop around all day?

 

[goosnarrggh]

Thanks for the info, I have no experience in the embedded market.
When you say the J2ME libraries would have to be ported, do you mean ported to the ARM architecture or "ported" as in interfaced with OSX?

Sorry for the ambiguity. I mean in terms of interfacing it with the mobile version of OSX. The libraries themselves are already written, and published in Java bytecode. But you can only go so far before you need to put something up on the screen or wait for user input. The portions of the class libraries that deal with these sorts of issues must be at least in part tailored to the particular host OS and CPU.

Although it would seem that a lot of the work would be done already from the desktop version of OSX, that likely isn't really the case. In the desktop version of OSX, the Java runtime is interfacing with a virtual machine encapsulated within a running OSX process.

In the ARM version, assuming the full hardware support was in use, other issues would complicate things, such as the need swap the CPU in and out of the ARM and Java instruction set modes, and to swap data between the two. So it couldn't just be as simple as direct copy of the existing OSX implementation.

(In the handful of implementations I've studied, the two modes are mutually exclusive. It's sort of like the existing disparity that's already present for ARM cores that can execute the full-featured 32-bit instruction words, but can also be switched to the more compact but less-feature-rich 16-bit THUMB instruction words. Or the way in which PowerPC's (except for the G5) could be switched back and forth between big endian and little endian.)