Page 1 of 2 12 LastLast
Results 1 to 10 of 11
Discuss Convincing Apple to give us a real (supported) API at the Free Toolchain Software (Cydia App's) - Hackint0sh.org; Apple must finish Leopard, then stabilize the iPhone classes and APIs before they will consider ...
  1. #1
    Newbie Array

    Join Date
    Aug 2007
    Posts
    4
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    0

    Default

    Apple must finish Leopard, then stabilize the iPhone classes and APIs before they will consider opening it up. Once the SDK is available Apple has a duty to keep compatibility with apps. They do not want to take that on until they have solidified the APIs. You can bet that something as sophisticated as the iPhone has a ways to go before it will be solid enough for Apple to commit to supporting developers and maintaining compatibility.



  2. #2
    Professional Array

    Join Date
    Jul 2007
    Posts
    59
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    9

    Default Convincing Apple to give us a real (supported) API

    Hi all

    I've been giving a lot of thought lately to Apple's decision to keep the iPhone API closed (conclusion: It sucks) and trying to think up some way to entice, or prod, them to loosen the reigns a little. To at least give developers something more powerful and interesting than writing glorified web pages.

    I realize the dev tools available on this site already allow iPhone development, but the simple fact is, the market for hacked apps will always be microscopic compared to the consumer market, unless they can attain the aura of legitimacy. Until some legitimacy can be conferred, the only customers we can hope for are those willing to take risks with their phone and the large majority of iPhone buyers simply won't take that risk. So, unless Apple can be convinced to change their minds, native third party development will be relegated to a fringe activity with few customers and little potential.

    The question is: How can a rag-tag collection of tinkerers and coders influence the Apple juggernaut? Apple is at the absolute top of its game at the moment and everything they do, on both the hardware and software fronts, is top notch. So how to affect a company that seems to sincerely believe they don't need third party developers? How to apply pressure to a company that thinks no one in the world can hold a candle to their least effort?

    Here is a potential two-pronged approach

    Step one: What do developers really want?
    I can understand Apple's desire to avoid as many problems as possible in the iPhone and if developers whittle down their pie-in-the-sky dreams of total device control, to a core set of feaures we could live with, it would make it easier for Apple to create these frameworks and support them.

    Personally, I'm a high level programmer and never descend into assembler. I confine my activities to C, Objective C, Javascript, PHP and MySQL. I don't need (or want) to write kernal extensions, device drivers, or pore over hex code for hours on end. So, in addition to the normal Foundation classes like NSString, NSArray, NSDictionary, NSURL, NSXMLDocument etc... my personal API wish list would be quite small.

    Classes:
    - NSIPhoneFile: Class that allows apps to open, read and write to permanent storage. Apple could still sandbox reads/writes this way and developers could write apps that could actually store a user's work.

    - NSWirelessConnection: Wifi/Bluetooth class that gives developers very high level interface to send and receive data from other wireless devices. Apple would maintain control for all internals of the class so their hands wouldn't be tied by compatibility issues, new protocols/hardware, etc.

    - NSAccelerometer: Application developers would register for accelerometer notifications at desired sampling rates and Apple could keep all the hardware/implementation details to themselves.

    - NSMultitouchDevice: Class that posts notifications about where users are touching the display and the pressure they are exerting (not sure if display registers pressure info. but if so, it would be greate to have access to it)

    Tools
    - InterfaceBuilder extension that allowed building GUIs using CSS/DOM rather than the complex widget heirarchy on Cocoa. Apple is already advocating this with their AJAX recommendations but it would be nice to have an Interface builder-like app to perform the layout. Behind the scenesm the files would be javascript/DOM based nibs rather than Cocoa based nibs. That way developers could hand edit GUI's and widget style sheets which is much easier than the Cocoa way.

    Functionality
    - Desktop iPhone visibility (ie: when plugged in it appears on users desktop like any other drive)


    Step two: I'm an iPhone, I'm an open iPhone.
    There are a lot of smart people around here with a lot of good ideas but so far, development resembles a herd of cats each chasing their own mouse. If we could put our heads together and come up with a couple of really interesting killer apps, write them and distribute them, it would serve as a sort of viral marketing for opening the phone.

    So, to wrap this tome up. What do other developers want? Could you live without total access to everything on the phone if Apple gave us some powerful, sanctioned API tools? What ideas do you have for really cool, "out of the box" apps that would make the Apple goliath take notice of us little programmer ants scurrying around its feet?

    Id be very interested in hearing what classes and APIs others would like in their "top 10" must have tools and what wild and crazy ideas are floating around for killer apps. The killer apps might be best to discuss via email off-forum so shady characters don't steal them. If anyone has any interest in this, maybe a trusted gatekeeper (Sam perhaps? If hes willing?) could serve as the bouncer to the killer app club.

    To be completely upfront, my goal is to prod Apple into supporting native development so that those who want to make some money programming for the iPhone (like me) can do so without the threat of Apple wiping out all our hard work on a whim. As to the killer apps themselves, I think they should be completely free but there needs to be some degree of managed access so prowling thieves don't rip us off.

  3. #3
    Rookie Array

    Join Date
    Jul 2007
    Posts
    17
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    0

    Default

    Interesting thoughts. I think "killer apps" are important, but the experience outside those apps are just as important.

    I think the more polished the experience of installing, removing, and managing apps (and the more polish those apps have) the more users will install and use 3rd party apps. The more users install apps, the more incentive Apple has to work with 3rd party developers, and, perhaps more importantly, the more incentive they have not to work against 3rd party developers.

    The PXL daemon & plugin, and the appearant willingness of the PXL devs to work with the Installer.app devs (and vice versa) are all good signs for the app management experience.

    It would help to have a smoother experience for getting apps, files, ringtones, etc on and off the iPhone (which doesn't suggest any lack of respect for Nate True or iBrickr) for windows users.

    The other thing that I think would really help with broader acceptance is some sort of restore-resistance. Apps, data and settings from 3rd party apps should be backed up automatically (somehow), and easily restored if a full iPhone restore is necessary for some reason. I should note that not even Apple gets this 100% right, as I learned when all the photos I'd taken with my iPhone got wiped after I did a restore.

  4. #4
    Professional Array

    Join Date
    Aug 2007
    Posts
    94
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    11

    Default

    Great package management actually *is* a killer app. Installer.app is like the apt-get experience with Debian Linux - it just makes everything so much easier, and gives you at-your-fingertips access to a whole bunch of great apps.

    Other than that, real IMAP IDLE, a great native IM client that runs in the background flawlessly, a media player that can stream video/audio as well as play all the major video files from the local drive (I guess a VLC port would do all of this? or mplayer?), and a working Flash plugin (there's already a port of GNASH, the open source Flash clone, to iPhone's Safari in the works - it already runs on ARM and works in Konqueror, so the port shouldn't be hard).

    The combination of those apps, and a great package management experience would make the iPhone hands down the most powerful smart phone/handheld device out there.

    And those apps would be so compelling that Apple wouldn't have any choice but to at least accept the third party app/developer community, since the installed base of a suite of apps like that would become huge fast.

    Other very iPhone specific "killer apps" would probably be neat accelerometer-based things. Games that two iphone owners play against each other via Bluetooth or over the internet that take advantage of the accelerometer, for example.

  5. #5
    Professional Array

    Join Date
    Jul 2007
    Posts
    59
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    9

    Default

    Quote Originally Posted by goodbrain View Post
    Interesting thoughts. I think "killer apps" are important, but the experience outside those apps are just as important.

    I think the more polished the experience of installing, removing, and managing apps (and the more polish those apps have) the more users will install and use 3rd party apps. The more users install apps, the more incentive Apple has to work with 3rd party developers, and, perhaps more importantly, the more incentive they have not to work against 3rd party developers.
    Good points

    It would help to have a smoother experience for getting apps, files, ringtones, etc on and off the iPhone (which doesn't suggest any lack of respect for Nate True or iBrickr) for windows users.
    On the Mac side, iNdependence is a great start. I have a few ideas to make a transparent wireless "volume" appear on the user's desktop with attached kqueues (or perhaps AppleScript folder actions) to make it seem to the user as if the folder is just a normal window into their iPhone's drive. Won't be able to get to this for a few more weeks though as I'm finishing up a big project and can't spare the time.

    The other thing that I think would really help with broader acceptance is some sort of restore-resistance. Apps, data and settings from 3rd party apps should be backed up automatically (somehow), and easily restored if a full iPhone restore is necessary for some reason. I should note that not even Apple gets this 100% right, as I learned when all the photos I'd taken with my iPhone got wiped after I did a restore.
    Hmmm... Perhaps an XCode template that has built-in .Mac and/or desktop synching. If such a base app could be hashed out amongst a large enough segment of iPhone developers, it would ensure that everyone started with a battle tested safety net for user data.


  6. #6
    Senior Professional Array

    Join Date
    Jul 2007
    Posts
    151
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    16

    Default

    Quote Originally Posted by cuzco View Post
    Tools
    - InterfaceBuilder extension that allowed building GUIs using CSS/DOM rather than the complex widget heirarchy on Cocoa. Apple is already advocating this with their AJAX recommendations but it would be nice to have an Interface builder-like app to perform the layout. Behind the scenesm the files would be javascript/DOM based nibs rather than Cocoa based nibs. That way developers could hand edit GUI's and widget style sheets which is much easier than the Cocoa way.
    As a programmer that actually programs on the Mac, let me tell you that the idea of using CSS/DOM for building GUIs is, by far, more work for both the programmer of native apps and for Apple as a toolmaker than just doing it using NSButtons, NSViews, etc and using IB as it is. Advocating the mixture of CSS/DOM into Cocoa is a surefire way to discredit yourself.

    A native app developer will not have a use for CSS/DOM in making GUIs because, for starters, the usage of it implies a guaranteed performance penalty.

    Other than that, yes, a sandboxed set of APIs would be nice, but there's little in the way of making this possible. The only one I can think of is changing the iPhone's GUI to allow multiple users to run apps drawn to the screen. One which is admin, and is Apple's, and then one user with lower priviledges, which is who the GUI would launch apps as on a user's phone. Even this idea is still fraught with security concerns since it makes malicious apps still easily possible.

  7. #7
    J to the T. Shaken, not Stirred Array thecompkid's Avatar

    Join Date
    Jul 2007
    Posts
    1,152
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    75

    Default

    You come up with complicated solutions, that, although well thought out, are doomed to fail. We do not need to impress Apple to get their attention, we need to tell them how to impress us. If you realize just one thing about Apple make it this: they exist to amaze us, the consumer, with technology. If there is anything they can do to make us even more impressed without compromising customer service, they will want to hear it. The problem rears its ugly head around that second part, the customer service. Though the iPhone development community may seem large, we are but a tiny fraction of a percent in a sea of happy iPhone owners. These average people could care less about our desires for an API, they just want the iPhone they paid good money for without the hassles of installing software. I know, no one is forcing them to install software if they don't want it, right? That's true, but what is the consumer going to think when they go to install an AIM client to chat with all their friends and something happens. They will blame the problem on Apple because they know no better. This is Apple's worst nightmare, and is surely not something they will be setting themselves up for.

    That being said,

    We should all take a cue from what happened with the iPhone price drop. Everyone was in a rage, and what happened? We got what we wanted. Just like a spoiled child in a toy store. Was this all a big setup by Jobs. I am a firm believer that Jobs planned the whole thing from the day the iPhone was released. The marketing strategy was ingenious. But anyway, back on topic, someone get the petition ready...

  8. #8
    Professional Array

    Join Date
    Jul 2007
    Posts
    59
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    9

    Default

    Quote Originally Posted by hachu View Post
    As a programmer that actually programs on the Mac, let me tell you that the idea of using CSS/DOM for building GUIs is, by far, more work for both the programmer of native apps and for Apple as a toolmaker than just doing it using NSButtons, NSViews, etc and using IB as it is. Advocating the mixture of CSS/DOM into Cocoa is a surefire way to discredit yourself.
    I stand discredited.

    I also program the Mac and have been for 12 years. For some things, I agree it's more work to do it in Javascript/CSS but for custom controls, where you want a nice unified but non-standard look throughout all your gui stuff (Think iTunes, iPhoto etc..), it's trivial to change a graphic url or font in a CSS style and "BoomŪ" your entire app updates without compiling.

    Think of what a pain it is to create scrollbars with a completely custom look. You have to Subclass NSScrollBar, cache your custom graphics, write your own drawRect method, Recompile the Application to make sure it all looks right rinse repeat.

    By contrast, in CSS you can simply change a few fields of a style relaunch the app and you're done. No need to recompile.

    Quote Originally Posted by hachu View Post
    A native app developer will not have a use for CSS/DOM in making GUIs because, for starters, the usage of it implies a guaranteed performance penalty.
    There is a performance hit but surprisingly for a large chunk of GUI widgets (buttons, sliders, collapsible views etc...), it makes no difference. The user can't tell whether a button clicked in .0001 seconds (Cocoa) or .001 seconds (Javascript) To them, the experience was instantaneous.

    I've done extensive custom widget programming in Javascript/dom and for a majoity of things, there is no discernable difference, at least at the user level. As programmers we may know Cocoa is faster but that speed advantage is unimportant.

    Other than that, yes, a sandboxed set of APIs would be nice, but there's little in the way of making this possible. The only one I can think of is changing the iPhone's GUI to allow multiple users to run apps drawn to the screen.
    If your app uses a WebView subclass as it's main screen, you can easily add javascript hooks to to any method in any of your app's classes.

    Code:
    + (NSString *) webScriptNameForSelector:(SEL) inSelector
    {
    	if (inSelector	== @selector(doSomethingWickedCool:))
    		return @"doSomethingWickedCool";
    	return nil;
    }
    
    + (BOOL) isSelectorExcludedFromWebScript:(SEL) inSelector 
    {
    	if (inSelector	== @selector(doSomethingWickedCool:))
    		return NO;
    	return YES;
    }
    A Javascript/DOM/CSS GUI doesn't necessarily imply using a WebView. Breaking out the Javascript parser from the open source WebView project into it's own Cocoa class would allow a GUI engine to use javascript on the fly.
    Last edited by cuzco; 09-15-2007 at 10:07 PM.

  9. #9
    Senior Professional Array

    Join Date
    Jul 2007
    Posts
    151
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    16

    Default

    I also admit I am quite surprised I'm talking to an individual who isn't one of the forum whiners going "somebody to make me a A2DP app now!"

    You're right that custom scrollbars, popup buttons, etc, isn't the most easiest thing to do. Not to mention CoreAnimation makes focus ring drawing a whole new adventure. But at the same time, if all we wanted to do was customize a graphic url or font, it's not that bad to change your imageWithName string for a new graphic, or call setFont a new font. We only need to do the custom drawRects if we're going to extremes in terms of customization, or we want to make it even easier on ourselves.

    For example, at work I got two buttons which look completely nonstandard but are just a standard NSButton after calling setImage and setAlternateImage. This is the closest equivalent I can think of to a web form button, doing the changes I'd commonly need would be (to me) equally easy in CSS and in code as it's just a string.

    But I also have a button which has a custom drawRect which composites something like a rounded texture button with an icon. I only made this so that the graphic designer at work doesn't need to align and redraw the button backing in photoshop multiple times. The CompositeImageButton was quite a pain to make. But it's a rarity, and there is no equivalent (or easier parallel I can think of) with web technologies.

    As for performance, you're right that if the render time was on the order to milliseconds, most users don't notice. The problem is that it typically isn't. Considering that we're most likely lazy-loading CSS/HTML/XML/etc, we have to wait for the disk access time, the parsing time, the layout engine processing time, and then the admittedly miniscule drawing time. This adds up both in latency, cpu, and memory usage.

    Consider Safari, which I'm guessing Apple has gone to no small lengths to improve the performance of. 6 seconds to load gmail on my dual G4. It's about the same amount of time necessary to load and check mail using Microsoft Internet Mail and News on a old LC575 I think.

    Web browsers have gotten bloated to the point where simply launching one allocates more memory than a old computer running Netscape 3 had in both ram and disk together. There is little that could be done better with AJAX that couldn't have been done with a 10 year old Mac running Netscape 3 and Flash.

    Now, sure, it might not feel so bad on your desktop with two processors. But a handheld device can't afford to run a text interpreter when an app wants to draw a button, for each button. Every execution of such a repetitive cycle becomes a battery life and/or heat penalty. The iphone doesn't have swapspace either, so it's not like we have the memory to run a xml parser for UI widgets. The best we could do here is to create and serialize an object based off the CSS declaration.... at which point, we might as well just be using IB.

    When considering native code versus JavaScript, I see the speed advantage of native code not only for the speed, but for a more efficient use of the hardware and for the battery life savings, which translates to possible weight savings, and therefore the option to make more interesting and convenient form factors.

    Quote Originally Posted by cuzco View Post
    I stand discredited.

    I also program the Mac and have been for 12 years. For some things, I agree it's more work to do it in Javascript/CSS but for custom controls, where you want a nice unified but non-standard look throughout all your gui stuff (Think iTunes, iPhoto etc..), it's trivial to change a graphic url or font in a CSS style and "BoomŪ" your entire app updates without compiling.

    Think of what a pain it is to create scrollbars with a completely custom look. You have to Subclass NSScrollBar, cache your custom graphics, write your own drawRect method, Recompile the Application to make sure it all looks right rinse repeat.

    By contrast, in CSS you can simply change a few fields of a style relaunch the app and you're done. No need to recompile.



    There is a performance hit but surprisingly for a large chunk of GUI widgets (buttons, sliders, collapsible views etc...), it makes no difference. The user can't tell whether a button clicked in .0001 seconds (Cocoa) or .001 seconds (Javascript) To them, the experience was instantaneous.

    I've done extensive custom widget programming in Javascript/dom and for a majoity of things, there is no discernable difference, at least at the user level. As programmers we may know Cocoa is faster but that speed advantage is unimportant.



    If your app uses a WebView subclass as it's main screen, you can easily add javascript hooks to to any method in any of your app's classes.

    Code:
    + (NSString *) webScriptNameForSelector:(SEL) inSelector
    {
    	if (inSelector	== @selector(doSomethingWickedCool:))
    		return @"doSomethingWickedCool";
    	return nil;
    }
    
    + (BOOL) isSelectorExcludedFromWebScript:(SEL) inSelector 
    {
    	if (inSelector	== @selector(doSomethingWickedCool:))
    		return NO;
    	return YES;
    }
    A Javascript/DOM/CSS GUI doesn't necessarily imply using a WebView. Breaking out the Javascript parser from the open source WebView project into it's own Cocoa class would allow a GUI engine to use javascript on the fly.

  10. #10
    Professional Array

    Join Date
    Jul 2007
    Posts
    59
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    9

    Default

    Quote Originally Posted by hachu View Post
    I also admit I am quite surprised I'm talking to an individual who isn't one of the forum whiners going "somebody to make me a A2DP app now!"
    I'm on it!

    But I also have a button which has a custom drawRect which composites something like a rounded texture button with an icon. I only made this so that the graphic designer at work doesn't need to align and redraw the button backing in photoshop multiple times. The CompositeImageButton was quite a pain to make. But it's a rarity, and there is no equivalent (or easier parallel I can think of) with web technologies.
    <canvas> tag does the trick. Has lots of Quartz-like drawing commands and surprisingly fast.

    As for performance, you're right that if the render time was on the order to milliseconds, most users don't notice. The problem is that it typically isn't. Considering that we're most likely lazy-loading CSS/HTML/XML/etc, we have to wait for the disk access time, the parsing time, the layout engine processing time, and then the admittedly miniscule drawing time. This adds up both in latency, cpu, and memory usage.

    Consider Safari, which I'm guessing Apple has gone to no small lengths to improve the performance of. 6 seconds to load gmail on my dual G4. It's about the same amount of time necessary to load and check mail using Microsoft Internet Mail and News on a old LC575 I think.

    Web browsers have gotten bloated to the point where simply launching one allocates more memory than a old computer running Netscape 3 had in both ram and disk together. There is little that could be done better with AJAX that couldn't have been done with a 10 year old Mac running Netscape 3 and Flash.

    Now, sure, it might not feel so bad on your desktop with two processors. But a handheld device can't afford to run a text interpreter when an app wants to draw a button, for each button.
    I don't think that's how it works. I think Javascript is only interpreted the first time it's loaded. The browser compiles it and uses the compiled code after that, so the only real hit is at load time. I havent acheived the guru level with WebKit but it may even cache compiled javascripts only reparsing the source if it spots a change. Not sure on that one though

    Every execution of such a repetitive cycle becomes a battery life and/or heat penalty. The iphone doesn't have swapspace either, so it's not like we have the memory to run a xml parser for UI widgets. The best we could do here is to create and serialize an object based off the CSS declaration.... at which point, we might as well just be using IB.

    When considering native code versus JavaScript, I see the speed advantage of native code not only for the speed, but for a more efficient use of the hardware and for the battery life savings, which translates to possible weight savings, and therefore the option to make more interesting and convenient form factors.
    Plists are XML files and the iPhone handles those just fine. Besides, parsing can be made extremely fast. For example, I wasn't satisfied with the output from headerdoc documentation generator, so wrote my own and was stunned to see it find source files, read them, parse, extract, resolve dependencies, factor strings for localization, generate multiple language folders etc. from approx 20 source files in .015 seconds. Granted, I'm running a fast machine (2.16 GHZ core duo) but even if it's 100 times slower on the iPhone's ARM processor, that's less than a second to parse 20 large text files.

    Anyway, looks like I've veered way off into the weeds here

    Where did my damn caddy disappear to!
    Last edited by cuzco; 09-16-2007 at 05:04 AM.


 

 
Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 0
    Last Post: 04-14-2011, 04:40 PM
  2. Replies: 0
    Last Post: 08-23-2010, 04:00 PM
  3. MacNN: Judge tosses Real antitrust case, blames Real itself
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 01-11-2010, 07:00 PM
  4. MacRumors: Apple Exploring Ad-Supported Operating Systems?
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 10-22-2009, 09:40 AM
  5. Replies: 0
    Last Post: 07-23-2008, 06:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Powered by vBulletin®
Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.
Search Engine Friendly URLs by vBSEO
(c) 2006-2012 Hackint0sh.org
All times are GMT +2. The time now is 03:14 PM.
twitter, follow us!