iPhone Application Development: Built in applications enhanced - iphone

I just saw an iphone application that enhances the built in "messages" application to send emotions. What this application does is that it extends the functionality of the Keyboard that appears in notes or messages application, and user can send emotion icons as messages. This application doesn't work when the emotions are sent to other mobile devices (it works only with iPhone), but that's not important. What i'm wondering is, how they did that (extended the built in keyboard)? Do we have API's that let you extend the functionality like this?
Best Regards.

They are part of the font set. called Emoji icons.
Apple's latest iPhone OS update
brought cute little "Emoji" icons for
Asian markets
To use them you need to use the (font) character code for each letter / emoji. I don't know what they are, but a quick google returns, abide a lot of spam, some codes worth trying. A quick script could be made to incrementally loop through each character code, thus finding them all.
A quick google:







Related

Getting started with accessibility

What are the typical mistakes an iPhone developer unaware of accessibility makes that renders their app unusable by customers with common impairments?
What are the first and easiest steps to take when making an iPhone app accessible to the vision impaired (etc.)?
How do I make sure Voice Over says or does something appropriate for all my programmatically created UIButtons, UISliders, etc.?
See the following link from Apple on accessibility on iOS.
http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html
I strongly suggest using voiceover to test your application after you've used the developer tools to check it's accessibility. I'm a blind iPod touch user and find that VoiceOver has a very low entry barrior, unlike windows screen reading software that requires you to memorize a bunch of keystrokes and realize that your application may be presented in an entirely different way to the user then you expect.

Emoji usage in a UILabel and appstore rules

Does anyone know if I use emoji unicode in an app's view if Apple considers this out of bounds? I'm not asking about enabling emoji or selling an app that is meant to enable emoji.
And example of the code - which is placing an NSString into a tableViewCell NSLabel:
if([combatCurrentHp intValue] <= [combatMaxHp intValue] / 2) {
characterStats = [characterStats stringByAppendingString:#" \uE022"];
}
This makes an emoji heart appear in the string. Do you guys know if there is a hard and fast rule on if that would get kicked back out of the app store?
I've seen applications that use the Emoji codepoints in the App Store, but I'm not sure if it's permitted or those apps just snuck through. I don't think there is a strict policy on this.
Enabling the emoji keyboard however is forbidden.
2 years late, but just in case anyone else is interested in this question, the official answer is that there's no problem using emoji in your UILabels.
My email to App Review team a year ago:
Hi,
I'd like to seek clarification with regard to the usage of emoji
within an app.
Although emoji input is not enabled for non-Japanese users, all iPhone
can view emoji whether or not emoji input is enabled.
User interface elements such as UILabel can thus display emoji if they
used the appropriate unicode in the text string.
I'm currently working on the next update of my app where I'd like to
display some icons within my text labels, and I couldn't find any
guidelines with regard to the usage of emoji in this manner.
I've attached a screenshot for your reference. I would like to check
if this usage is appropriate for the App Store. Much thanks!
Their response:
Hello,
We see no issues with the use of emoji within the app. Please let us
know if you have additional questions.
Best Regards,
App Review Team iOS Developer Program
Also, my app has been using the emoji for the past one year with no issue.
I don't believe that enabling the Emoji keyboard is forbidden as it is enabled as standard in all Asian countries and there are dozens of apps available in the app store for unlocking it in other countries. Why would Apple incorporate the keyboard in the system if they intended to forbid anyone from ever using it?!

Web page restrictions for use on iphone / smartphones

I want to allow our main application to generate document files that can be easily read on the iphone, or other smart phones. The easiest way to do this, I think, is to create a simple HTML file and use javascript to show / hide different bits of it. For example, when the user clicks / touches "section 1", the section expands to show its full details; otherwise, it will remain collapsed to save space.
What guidelines should I follow when creating this file? I've done a little research and arrived at the following:
The iphone has a native resolution of 320x480, but only about 320x400 is visible for a web page.
Other smartphones have resolutions from 160x120 (probably not high enough to bother with) up to 320x240 and some even have 480x640.
These are useful for deciding how to style and arrange the HTML output, for example. Are there any other useful guidelines to work with? For example:
1) How big / small should I make things to let the user have a large enough 'target area'?
2) How can I get the file onto the iphone? Would the user have to drag and drop it via USB?
3) What size of fonts can I use before it gets too small to read?
etc etc. I don't actually have an iphone to test on, which makes this a little more problematic.
Thanks for your help!
I don't know about other smart phones, but the only way your file is going to get onto the iPhone is via the web browser, email, or a custom application that you write. There is no general mechanism for uploading files to the iPhone.
It's surprisingly easy to read even fairly small text on the iPhone, and the gesture-based zooming makes it very easy to zoom in and out.
If you're going to provide your documents through ASP.NET you might want to check this out:
http://mdbf.codeplex.com/.
It allows you to detect what kind of smartphone did the request, you can then check out the capabilities (screen-resolution, color-display, screen-pixels height... etc.)
Most mobile browsers render XHTML-MP (XHTML Mobile Profile). You can get away with rendering that.
iPhones (and other WebKit phones like Android) support the viewport meta tags which can make the experience more tailored to that phone screen size. You can learn about these in the iPhone web page creation docs from Apple.
If you are really interested in supporting a wide range of handsets, you should look at a "multi-serving" technology like WURFL, which will let you abstract a lot of the complexity away from supporting hundreds of handsets. It's sort of yesterday's technology though, since modern mobile browsers render most web pages just fine.
I'm not sure how current this is, but Yahoo says that one of the restrictions for an iPhone is that it won't cache files larger that 25k uncompressed. This doesn't affect your display necessarily, but it could affect your performance and so you may want to take it into consideration for your design.

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.

which features do you look forward to the most in iPhone SDK 3?

Which of the new features are you looking forward to the most in iPhone SDK 3.0?
Is it one of the main advertised six new things, or something smaller? Something in the "1,000 new APIs", perhaps?
Phone to phone communication via bluetooth seems like it will terribly useful for some apps I am writing. No longer do you have to input all the data you want to store yourself, you can share some of it with other iPhone users.
not really a feature, but the best thing about developing the iPhone SDK further is the great frameworks that arise. there are some really, really great frameworks out there already (like the Three20 project) which will become even better with the new 3.0 SDK.
my real excitement will take over once they let us run background processes. maybe in 4.0?
Video! The ability to write decent tools for mobile video uploads is a big draw.
MapKit by far will bring the biggest change sweeping across the app space.
My personal favorite is that we can finally easily track upload progress of large files (like images).
I really, really want to see fixes in the camera API so that it isn't either broken (2.2.1) or forcing a switch to portrait (3.0).
Apart from that, the most useful features to me are:
push notifications. Great for making an app more sticky - you can let the user know that something of interest to them has happened.
CoreData - I've been using a third-party SQL layer, but it's a little buggy and no longer supported.
Peer-peer bluetooth, as the poster above said, is also useful for local data exchange.
And the least useful? Cut and paste. I actually want to disable it in my app (to discourage people from copying content) - and it doesn't look as though you can (yet).
Bluetooth phone-to-phone communication with GameKit will enable a host of currently impossible applications. Multiplayer games with no WiFi network needed and data exchange between two phones are obvious use-cases.
I'd also like to see - not currently included in the betas - a decent camera API that allowed us to customize the appearance of the capture screen, and as another poster said, have it work properly in landscape and portrait mode.