Does iPhone provide any API for inserting menu selections into e-mail, SMS and Addressbook context menus? - iphone

The Blackberry APIs allow one to insert custom menu items (and corresponding event handlers) into their standard email, SMS and Address book context menus. Is there any supported way to do this with iPhone APIs?

No, Apple doesn't provide these kinds of hooks. However there are some tricks I've seen - one example is what Twitterific does to tweet pages that you are viewing in Safari, via Bookmarklet which uses a Custom URL to launch Twitterific.
Perhaps you can do something similar by having a text containing a custom URL. I've never tried this but it's worth experimenting with.

As of SDK 3.1.2, no, that's not possible. In fact there's very little you can change! There's not even an easy way to change the colour of the title bar!

Related

Embeding multiple apps in an app?

I am a newcomer to application development and I'm wondering if the concept I have can actually be created.
My concept involves creating an app that has the ability to embed another app within itself.
I'll do an example which is also a very bad one but you'll at least get the point.
Picture an app on the iphone that's called "Kwesi's app". Once you tap on it, it opens up a page with 3 icons. A facebook icon, a gmail icon and a hotmail icon. Now tap your finger on the gmail icon and instantly your gmail opens up withing "Kwesi's app" and you have full access. There is also a button in the top left corner that says "Main Menu". Once you tap the "Main Menu" icon, you go back to the three icons and can now rinse and repeat.
I hope this example is clear enough.
The question I seem to be coming back to is, would it be possible having an application that embeds or links you to other apps in that manner? I can only guess that it'd be really weird since they'd have to be installed seperately on your phone but I don't want that. I want one app that can handle an already set amount of apps within itself as the above example shows.
Thank you very much for reading and any thought would be very much appreciated.
/Kwesi
No, that is not possible in iOS for security reasons. But you have the following choices to modify your idea:
Register a protocol for the app : This will allow you to send data between applications using protocols. However, if the app wasn't made by you and doesn't have a protocol, then you can't use it.
Using this idea, it is possible to open an application. For example, opening Facebook with "fb://" or evernote with "evernote://". I am sure there are other applications that have these protocols. Just be aware that you don't have control on the application in this case. You can only open it and send data to it.
Since your example was about Facebook, Gmail. Then I would suggest using their corresponding API and build everything in your application. Many famous applications provide APIs for a fee or free usage. You have to check with each one separately.

What are the pitfalls when implementing a web page like app?

I'm planning to implement some app that performs similar functions as some website does. An app should be able to post, get and view some data. Most viewing data is available only after login. Payments. The webservices are .NET asmx XML services.
So, I'm planning to use UIKit, drag and drop some text fiels. For posting the data, I will do some manual input validation, assemble input into a string, post it to the server. Also, some parsing will be done after getting info form a webserver. Now, I haven't done any website app before, so I'm just curious what are the potencial problems that I might run into.
I guess you are asking about potential technical issues. The ones I faced recently working on an app of this type and workarounds are:
Maintaining your session with the server if you are combining native UI screens together with UIWebView's of your website.
XML Parsing can be hairy at times, so JSON is the best option depending on your preference. The other solution is to output XML in the PLIST format which is easier to code against. On the server side PHP has some PLIST generating libraries. Am not aware of what is available on .NET.
On the iOS side the ASIHTTP library helps make it easier to post to websites, particularly when you are using binaries etc.
Depending on your use case you may also consider a pure web based UI version which resides inside a UI webview. If you are planning on going this route JQueryMobile is a pretty good solution for rendering iOS like UIs. This saves you quite a lot of effort on the communicating with the webservice and parsing etc.
Thats all I can think of for now.
Biggest problem might be getting it approved by Apple if they think it should be just a website and not an app. They might cite: "Limited Functionality". see : https://developer.apple.com/appstore/resources/approval/guidelines.html
I can also reccomend www.sudzc.com
Your UI will certainly not be as responsive as a native app.
Your users won't be able to use your app without an Internet connection/flaky connection
You'll have to rebuild all native controllers yourself if you wan't your app to look like a native iPhone app.
You'll have to rely on libraries like PhoneGap to use most of the hardware/non HTML supported functions (like geolocation, camera, etc.)
Etc.

Overriding UIPasteboard Globally for iOS/iPhone

The purpose of my application is to extend the functionality of the UIPasteboard across all applications on the iPhone. So if you are composing a text message, you could doubletap and access the extended UIPasteboard functionality. The same goes for email, Twitter, or any other occasion where a text field is present.
I don't really need an example or explanation of how to extend the UIPasteboard, I can figure that part out. The part I'm unsure of is creating a background application that can intercept events from other applications. I've never built one that was meant to sit around until someone performed a certain action in another application.
Any ideas or pointers? Thanks!
Not possible on a non-jailbroken device, I'm afraid. iOS apps are tightly sandboxed, for security and UX reasons—third-party software doesn’t get to mess with system-wide functionality.

source code of contacts - application of iPhone

I have seen the Contacts in iPhone Simulator.
I want to create an application similar like that.
Does apple provide open source of that " Contacts " application.
Similarly, Does apple provide source code of " Safari ",
So we can create our own browser.
They don't provide the source code. You have a UIWevView that you can use to render web pages using WebKit, and you can access the address book information by using the Address Book framework.
To create "Safari" You can just use a UIWebview with a tool bar. It's rather trivial. a tutorial is here:
http://icodeblog.com/2008/12/19/iphone-coding-learning-about-uiwebviews-by-creating-a-web-browser/
Contacts is slightly more involved, you can use the Adress Book Frameworks. There are Cocoa Touch classes to bring specific view controllers into existence. These are like the photo picker where you give up control of the UI until you recieve a callback. There is also a C-based API for direct manipulation of the contacts DB from within your app.
http://developer.apple.com/IPhone/library/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/200-QuickStart/QuickStart.html

What does iPhone OS 3.0 need from a programming perspective?

iPhone OS 3.0 is being announced and previewed next week (March 17).
We all know the feature set users want. Copy/paste, MMS, Flash on iPhone, etc.
We'll see about those.
What I'm interested in what does the development community feel the SDK is missing, in need of, to make programming for the platform easier and more productive.
A more complete Interface Builder with support for custom palettes and all sorts of goodies like that.
Better control over the keyboard.
Better unit testing support. (Unit testing can be done, but only on the simulator, and it's very awkward to set up.)
Push notifications. Please.
A more accurate simulator, i.e. one with a more accurate set of frameworks.
The ability to easily build views like the Mail compose window.
For that matter, an in-application compose window.
A better way for apps to share data locally than by invoking URLs.
Access to the calendar, notes, mail (possibly read-only), and bookmarks (again, read-only) databases. Maybe even limited access to the iPod database—even just the ability to read song metadata and access and change the playing song would be helpful.
Some sort of middle ground between UILabel and UIWebView that allows for formatted text without a huge hassle.
More built-in toolbar icons.
The return of the "glass" button style that was in the beta SDK.
A few useful internal views, like UIProgressHUD, exposed.
And last but not least...
A pony.
An easy Javascript bookmarklet installation method for Mobile Safari. (OpenRadar: 1, 2)
UIWebView needs more of UIScrollView's properties and methods, such as contentOffset.
More configurability on some of the built-in behaviors and views, e.g. the button text on UITableViewCell's "Delete" button, or the styles and text of UIAlertSheet/UIAlertView buttons. (Some of these can be done today with undocumented calls, but I'd rather not rely on those.)
More flexibility from UINavigationController, such as the ability to push/pop views that selectively don't display the navigation bar but using the same animations and stack, or more customizability over the navigation bar button labels and behaviors.
The ability to restrict interface orientation per UIViewController, not just accept/reject changes via shouldAutorotate. E.g. I want my main content view to be autorotatable, but I want my navigation hierarchy and settings screens to always display in portrait, even if the content view was rotated to landscape.
libxml and its handy DOM XML parser instead of the SAX-based NSXMLParser.
libcurl w/SSL, or more options and functionality for NSURLConnection.
Ability to check whether a URL scheme is registered. This could be used for apps to detect whether other specific apps are installed, and enable functionality selectively, e.g. when Instapaper detects Tweetie is installed, it can offer a "Post with Tweetie" button. (Disclaimer: That was a plug. I make Instapaper.)
I'm sure I'll think of more, but overall, I'm very happy developing for the iPhone. I'm amazed at the quality and sophistication of the iPhone OS, the SDK, and the development tools given how incredibly young they all are.
I'm surprised no one has mentioned garbage collection yet. Objective-C 2.0 on the Mac supports optional garbage collection. I don't really see any reason it wouldn't work just fine on the iPhone as well and it would eliminate much of the tedium of having to explicitly release objects all over the place.
What I'm hoping most for is to allow iPhones to talk to each other either via Bluetooth or some other means. Granted, they can talk via Bonjour if they are on the same Wi-Fi network, but that's just not convenient enough in 2009. If I'm out with a friend and want to play a multi-player game we first have to find a Starbucks or whatever the heck to get on the same Wi-Fi network. Also, think of the ridiculous amount of social apps you could have if iPhones could talk to each other without needing Wi-Fi. Exchange business cards, flirt with the cute girl over there, etc.
Form a PURE programmers perspective, make XCode as helpful of an IDE as Eclipse or IntelliJ are in the Java world. There's so much time I waste on stupid stuff that the IDE could have found for me as I typed it.
I also don't understand why I can't color buttons without having to use images.
Better multitasking is absolutely key at this point. Android's got it, Palm's WebOS has it - both, it seems, in largely unrestricted and well-implemented fashion. Possibilities:
Push notifications with a good UI (message stack in addition to badging/sound/whatever - if they have to have an extra approval step so apps can't be obnoxious, so be it)
Multiple full processes (not possible with current OS, I realize, but then I've never seen a good explanation why the iPhone doesn't support virtual memory)
Smaller "background" versions of apps that can run in the background - no GUI and a significantly tighter memory constraint
A good mapping API. Let us access the Google Maps abstraction that the Maps application uses !
More Interface Builder goodness
Better simulator
Smart inbox. Incoming messages are routed to installed handlers based on type.
Synchronisation framework that simplifies syncing with desktop & Mobile Me.
Decent landscape support, without the multitude of bugs, especially for the camera picker. Better support for rotation and more control of it.
Access to EXIF data on images from the picker, so we can tell their location
Deeper access to the camera API, so that we are not rail-roaded into the standard photo taker / picker
Push notifications that can launch an application. (In lieu of full multi-tasking, which I don't think we'll get and which could be problematic.)
Better, more intuitive keyboard controls.
API for inter-application messaging.
Access to data from Calendar, iTunes, Mail, Notes and more (with user's permission)
A more accurate simulator, with, for example, ways to limit bandwidth, and use the Mac's camera to actually take a photo.
Phone-phone bluetooth for data exchange
Access to more of the views used by iPhone apps, e.g. the progress HUD, email "blobbing" mechanism for email addresses, thumbnail scrollers, HUD brought up in Photos app, and more.
Less sandboxing. It won't likely happen, but it would always be appreciated for an app to have slightly more power than they currently do (actual filesystem access, for example. even if it was read-only access, it would still allow for more interesting applications to exist).
EDIT: Also, access to the copy/paste API. But I hope that one is obvious to Apple.
My list:
More full-featured IB support as the Mac has
Inter-app Data transfer mechanism (could be C&P, but does not have to be)
Greatly improved camera API with deeper level of control and more flexibility
SDK access to bluetooth and more support for protocols
Real ObjectiveC framework around the address book like the Mac has today.
Warnings similar to the location warning when an app tries to access address book data.
I'm sure whatever they actually have prepared, there will be a few interesting twists.
Ability to send SMS messages without having to have launch the SMS client and have the user type the message.
Access to the raw camera data so that things can be done without having to take a picture and wait for it to save (like you can do with Android)
push notification so that you can launch tasks... would need to be user controllable.
A camera that can focus (I know... have to wait for the next iPhone for that... if they decide to put it in...)
A UIKit level drawing api.
We all know the feature set people want. Copy/Paste, MMS, Flash on iPhone, etc.
I would have thought those specific items were down the SO wish list (although it seems I'm wrong looking at the votes on this comment :-).
MMS is a pretty pointless app when you have eMail. Flash is not an OS issue - Flash could be delivered today.
I don't even want push notifications - they're just a patch, I want background apps. I also want fixes for all the broken APIs like Camera, video and landscape support. Support for CoreImage filters would be nice too but probably too much to wish for.
[[ABAddressBook sharedAddressBook] me] for being able to use the owner's Zip code, phone number, or whatever.
Ability to download files to local storage and sync them back to iTunes or your hard drive
Get EXIF data from photos
Pull all photos at once
Pull all contacts at once
Control screen brightness
Access to music in iPod section
Read access to email and text messages
Access to Safari cookies (so maybe I could make some kind of keep-me-logged-in app.)
fix table view in landscape mode
new camera API with direct access to the camera
distribution code signing automatically when uploading to the app store (instead of code signing in xcode)
ability to request more memory so users don't have to reboot their phones to get rid of background apps
A non-Mac based development envionment.