-
Patrick Patience has posted a fantastic little summary of jailbreaking hacks over at Smoking Apples. He’s got some gorgeous themes and extensions working together, complete with links and extended info—it’s definitely worth taking a look.
-
The “Deep” iPhone theme, well photographed by William Hook.
-
-
2-bit 4-bit 8-bit 16-bit Mimeo and the Kleptopus King is a new iPhone game being worked on by Shaun Inman, creator of the great 8-bit title, Horror Vacui. The game gives homage to classic video games, with a twist—instead of enhancing the player, power ups in the game enhance the resolution of the world around him. Check out the homepage and hit refresh a few times for a sample. The app is being developed under a MakeWork grant and should be available by the holidays. I’ve had the privilege of seeing some of the design over the past month on Dribbble, and I gotta say: The details are going to be fantastic. Check Shaun’s Flickr for a nice little video archive of the game’s progress.
-
Dimitri Stancioff questions the lack of utility apps (Weather, Stocks, etc.) in the iPad demos and raises the possibility of a secret “Dashboard” app.
-
As a concept, multitasking goes beyond just background processes. There’s an aspect of multitasking which is purely visual. For example, when developing a website, I’ll often put the Photoshop file next to my browser, for comparison. In a roundabout way, this means the iPad already has multitasking. Consider apps like Mail where, on the iPad, the list view and detail view have been combined to one screen. Users can not only read an email, but also instantly see when the previous email in that thread was sent, who sent it, and delete it—all without losing their place. To me, this is a form of multitasking. Extending this split screen idea to the app level presents a difficult UX challenge, but could be a better approach for multitasking than the typical “windowed” metaphor used on desktops.
-
There has been a lot of discussion over the past few weeks on whether or not the iPad (and iPhone for that matter) should support multitasking. Many people seem to have a different interpretation of what this means, whether it’s just listening to Pandora while browsing the web, having a faster way to switch apps running in the background (akin to WebOS’s concept of “cards”), or just having an app be able to fetch data in the background.
I’ll be posting some more thoughts on multitasking throughout the day, but first a quick poll: Do you want multitasking? Why or why not?
-
Jonathan Stark outlines some quick notes about implementing HTML5
videoon the iPhone:- Poster image is only displayed until the video is loaded.
- True/false attributes do not require values.
- Video can be played (and heard) even when not visible.
i.e. video { display: none } - The autoplay attribute is ignored on iPhone.
i.e. will not autoplay no matter what - The controls attribute is ignored on iPhone.
i.e. controls are visible no matter what - The remote file is downloaded whether or not the user clicks play.
- You can interact with the DOM while iPhone video player is open.
- You can make a video autoplay on iPhone by navigating directly to the video url. However, this is useless within the context of an Ajax app because it spawns a browser window.
-
Panelfly, a beautiful comic book app for the iPhone, has announced their plans to support the iPad. They’ve already mocked up a great selection of screens—each showing incredible attention to detail and level of innovation for a yet unreleased OS.
-
Web Development for the iPhone: HTML, CSS & JS Support:
A very comprehensive list of selectors, CSS3 features, and HTML5 elements featured on the iPhone.
-
“Apparently, the touchstart event object persists in browser memory even when the event has long ended. More importantly, it continues to be updated with information about the current touch action.”
- PPK details a discovery that could have a huge impact for mobile web app performance. -
iPhone Development: Greatly Exaggerated:
Jeff brings many of Jon Casasanta’s points down to earth and discovers that, like Mark Twain’s hero, rumours of the death of Mac software have been greatly exaggerated.
Jeff’s main point—the same which leapt immediately to my own mind—is that the most interesting new developer technology is on the Macintosh, not the iPhone. Sure, the iPhone has a more modern user interface setup, all built on top of CoreAnimation for you. That’s just about the limit of it however: the Mac has multi-touch events (NSTouch, anyone?) just like the iPhone, CoreAnimation itself is there, and so much more.
Garbage collection, blocks, and Grand Central Dispatch are all Mac-only (although hopefully the last couple will make an appearance in iPhone OS 4.0? Please?). These are fantastic technologies to play with, and pretty much swung me away from the iPhone. In fact, they’re so important and interesting in so many ways that my forthcoming book, Pro Objective-C for Mac and iPhone, has dramatically more content appropriate to a Macintosh desktop developer than an iPhone developer. There’s just so much more to work with on the Macintosh, even when considering only the Foundation Kit and the runtime.
I don’t doubt that these technologies are going to be made available on the iPhone platform sooner or later; in fact I think it’s inevitable. But they’ll almost always appear on the Macintosh first, so the good Macintosh programmers will be getting the good jobs. Just look at me and Kobo; I didn’t get my position there because I was an iPhone programmer— I got it because I’ve been a Macintosh programmer for many years; I know where the iPhone is now, and I know where it’s likely to be in a few years’ time. So does any Macintosh desktop programmer worth his salt.
So to Jon, Phill and co: as much as you love the iPhone, you ignore the Macintosh at your peril. You owe it to yourselves to learn and work with the newest Macintosh APIs and technologies now, or you’ll be playing catch-up to desktop developers who’ve been refining their arts for a couple of years yet…
-
So response to my previous post has been fairly positive, despite not achieving the critical mass necessary to land on Daring Fireball— come on @gruber, pay attention ;o)
I’ve had a few conversations with people over the last week about some of the implementation details and suchlike, and I wanted to expound on the original idea a little. The first post went into some reasonable detail on the security and verification systems, but not so much on the type of processing supported, and how it would be setup in a way beneficial to the goals of both Apple and us developers (or ‘plebs’).
There are a few main areas where background processing of some kind is highly beneficial, for which I will detail some examples here. Maybe I’ll even get the chance to do a third post with some code involved somewhere…
-
Push Notifications
This isn’t necessarily what most people would put first, but it’s hard to underestimate just how much of your live data needs can be handled by these magic little packets at once.
-
Manual Network Updates
Sometimes push notifications aren’t feasible to implement server-side, or can’t provide enough detailed information (case in point: Outpost). For such applications, the ability to perform some networking on a scheduled basis in the background would be a boon to the applications’ usability.
-
Custom Notifications
If you’re writing a to-do list app, or some form of calendar, you’ll probably want to alert the user to certain conditions even when your application isn’t running. Currently the only way to do this is to have a server which manages such notifications and uses APSN to pop up an alert on the user’s iPhone, but the costs for maintaining that service can be prohibitive.
-
House-Keeping
If your application deals with large data-sets, it might benefit from performing some house-keeping tasks now and then, for instance database compaction. This is an ideal candidate for a task to run while the phone is locked.
Let’s look at each of these in some detail, so we can see how the setup would work, and how the system would enforce its policies.
Push Notifications
Potential User: Facebook
Your application receives push notifications for new messages as they arrive, but it can’t do anything with that message unless the user chooses the ‘view’ option. If the user cancels the alert, then the application won’t find out about the new message until it does its own networking to fetch the details. A better approach would be to register a background daemon to handle the notifications, thus being able to store them directly into the application’s data store in some manner.
The daemon in this case would run in a no-networking sandbox, since that should be unnecessary for this use case, but would be able to make changes to the disk, subject to the same restrictions as the main application. Once it’s finished processing the incoming notification it can then prompt a standard system response/alert by exiting and returning a special result code which would be monitored by the background processor launchd instance. This way the application can cause the usual alert message to appear, an icon badge to be applied, etc, or it can suppress any standard APSN response action completely.
Manual Network Updates
Potential user: Outpost
In some cases—particularly if an app is based off a third-party service such as Basecamp—it is impossible or impractical to implement push notifications on the server-side, so the application has to do all the legwork at runtime. This can lead to poor user experience issues as the application has to stop and perform a lot of work at startup, when the user wants to just fire it up and check something quickly.
A solution to this would be to register a network download daemon. This would be registered using two key pieces of information: the interval at which it wants to run, and the details of the network resource it wants to access. The system would then tweak the launch times to attempt to coalesce networking operations, meaning that the network hardware would be powered up exactly once, by the system, prior to any such daemons running. The system could also open network connections ready for the daemons, possibly connecting it up to the daemon’s standard input and output streams, further allowing the system to make the major decisions on power and resource management. In this case, the daemon itself might be prohibited from making its own network connections; an alternative should be available however where a daemon could do so, though possibly with a limit on the number of such connections it could open at one time or in a single invocation.
The daemon would be free to do whatever it wished with the data it receives from the network. Those with larger data sets would perhaps simply drop the downloaded data somewhere where the main application could parse it upon launch, perhaps with enough minimal parsing to determine a suitable application icon badge value. Applications with smaller data sets could perform all the parsing internally, updating the application’s main data store directly.
The system would put strict limits on this type of daemon— it can monitor its run time and the amount of CPU and network resources it uses, potentially throttling it or telling it to quit outright once certain limits have been reached.
The system would provide some APIs for this daemon to provide data for an APSN-style alert or other notification to be presented to the user. These APIs would be used to send the data to the parent launchd process, and the application would return a specific result code to inform the service which form of alert (badge, text, sound) to perform after the daemon terminates.
Custom Notifications
Potential user: any to-do list or calendar-based application
Many applications on the App Store now maintain to-do lists or link to online calendar or time-management services. Similar to the manual network type above, it might not be possible or practical for the application developer to build APSN functionality into the service on the server-side, so some means of firing off notifications while the application isn’t running would be necessary to provide full value to your customers.
This type of daemon would be initially registered without any specific launch conditions; these conditions would be added later on, giving specific times at which it would launch. The daemon itself would be expected to only read from the application’s local data store, so it would run in a sandbox with no networking or disk write access, just read access to the application’s data store folders.
This item would in fact be a good candidate for a plugin-style API, similar to those used by Spotlight or QuickLook on the Macintosh. The plugin would be loaded, asked for data, and unloaded when done, and as such wouldn’t require the creation of many separate processes. This might make security and sandboxing a little more problematic to implement however; the best solution would be to spawn a sandboxed loader process for each plugin, but that still requires many of those to be spawned, leaving us only a little better off than using custom daemon processes outright.
House-Keeping
Potential user: OmniFocus
Some applications manage fairly large and complicated data sets; databases in particular are in high demand on the iPhone due to their memory-light access to large amounts of structured data. Every now and then, however, these large data sets might need a little cleaning and pruning. This might be a more involved operation than you want to do while the user is interacting with your application, or it might be something which is good to do frequently (more frequently than your user firing up your app, especially if you’re using any of the other background processing types described above to access your data store).
This type of daemon would be registered with a launch interval specified in days. It would have no access to the network (it’s only working with a local data set after all) but would have read and write access to the main application’s sandbox. The exact launch time would be unspecified, and manageable by the system (to better coalesce multiple such processes together), but would in all likelihood be confined to times when the system is locked, preferably using a heuristic to determine the likelihood of it remaining locked for a good while.
The processes would be monitored for power usage carefully; of all the above, these are perhaps the most likely to cause drain on the system by continually moving data into and out of memory and accessing larger than usual parts of permanent storage. They would also need to have some form of IPC channel available to communicate with the main application so that they can finish up quickly in the event that the application is launched while the daemon is performing its duties. The app would need to prompt the daemon to finish up, then wait for a response back saying that the data store is safe to use. Such interrupted work might then be recommenced when the main application terminates, although that would likely be a function provided and performed by the background launchd instance itself rather than prompted explicitly by the application.
For the IPC, using an Apple-defined ObjC protocol with Distributed Objects would make the most sense, but at present the required runtime support isn’t included in the iPhone’s Foundation framework. An alternative would be a set of Mach IPC methods (defined using MIG) for the application to talk to its daemon via the launchd process itself. The application would talk to launchd, and launchd would pass on messages to the daemon, returning a safe result once the daemon has cleaned up and terminated.
In Summary
The four scenarios above should cover most, if not all, common uses of background processing, while still allowing the system to carefully manage the use of its resources and to optimize such behaviour.
I had planned to push these ideas internally once I started my job at Apple, but since the INS decided to make me its bitch last week, I’m going to have to rely on good old-fashioned social networking to do the job. Perhaps some nice person on the iPhone team will read this and start showing it to the right people. That would be nice. It would help greatly to have it excessively retweeted too— the more people see and advocate such ideas, the more likely they are to materialize.
Now GO TO IT PEOPLE CHOP CHOP kthxbye ;o)
-
-
A lot of people want to run apps in the background on the iPhone, but I believe that Apple has some very legitimate concerns about the feasibility of doing so, at least on the current hardware platforms. However, I believe that there is a perfectly valid way of accommodating most developers’ background-execution needs. This system is called ‘launchd’, and I believe it would provide a very good means of allowing certain tasks to run in the background under the control of various system policies enforced by Apple.
In Snow Leopard, there are some new APIs designed to allow general purpose applications to install background tools used for privilege elevation; these APIs make use of code signing rules to verify that the installing application and the privilege tool match one another (i.e. they must both securely authenticate against one another). The details of this API are in the ServiceManagement framework in 10.6: look at
ServiceManagement/ServiceManagement.h, specifically theSMJobBless()function.This functionality could be used on the iPhone to provide authorized installation and management of user-based (NOT privileged!) background tools, which could be run under a specific launchd instance designed to keep these tasks under control. The launchd environment could also be limited in the functionality it provides: rather than allowing background processes to always run, or to launch and stay alive, it could allow only for launch-on-demand semantics with the requirement that a process keep checking in as it processes data in order to be kept alive beyond a certain threshold. This launchd instance could also throttle the number of such processes running at any one time, or coalesce received data to avoid launching background processes too often (process creation is a lot of work, after all).
This way we could write applications which can perform some small amount of networking on a timed basis (such as pinging a Basecamp server once per hour to check whether updates are required), or could handle Push Notifications in the background, storing received data in a temporary file ready for the real application to handle upon its launch. This last could be useful for twitter-type applications, for example: direct messages could result in a prompt, while @mentions could be dumped quietly to disk so the foreground application can pick them up without waiting for a network connection when it is launched.
Lastly, due to the use of code signing to pair the two processes together, an additional level of security/control is gained by the system, since any attempt to modify either the foreground or background application would result in its code signature becoming invalid. This can then be used as a flag by the system not to allow background processing either way: if either foreground or background signature is invalid, the background process will NOT be launched, EVER.
Pairing this technique with the app store approvals process should guarantee that abuses are kept to a minimum whilst providing developers with some very useful functionality.
-
Really great iPhone app design showcase and gallery. Excellent for any sort of UI inspiration.
