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.
Related
We are going to redevelop one website we developed as an ASP.NET website to be a mobile one.
So, I'm wondering how does the development of a mobile website differ from a normal one?
Also, what is the best approach to do this taken in consideration that this mobile website will be browsed mainly from iPhone?
There are a number of differences between a mobile device and a standard computer.
The screens are much smaller (fewer pixels to display your page). You should put fewer elements on each page.
They are typically viewed in portrait mode (narrow display - narrow page). You should plan on using the full width of the screen instead of setting a fixed page width like most people do on standard web pages.
People use finger gestures to manipulate the page instead of a mouse (buttons/links should be larger)
They can include additional features such as geo-location, telephone, etc. that you can incorporate into your app to be easier to use. There are some libraries available to help you use these, such as jQuery Mobile.
Users are concerned about battery life plus the CPU tends to be slower. Make sure you keep animations and client side processing to a minimum.
Users are concerned about data usage. Keep ajax calls to a minimum (don't ask the server for data every few seconds!) and use graphics sparingly (it's better to use html/CSS to make the page attractive).
Flash isn't supported on iPhone and is not well supported on other devices. However, most mobile devices have decent support for HTML5, so you can typically use that instead.
Users on smartphones are used a different experience.
In addition to Brian's answer I'd add:
Screens are not resized but scrolled, however sides scrolling is not generally a good experience
Screens orientations can change, but the same scrolling rules apply
Consumers are used App like behaviour and as such less information with backwards and forwards between pages is common and between sites
Consumers generally have data concerns so data traffic needs to be minimised
Controls/buttons/selections/data entry need to optimised for hand gestures - for example think of what happens with the keyboard pops up to allow data entry, how much screen is available - can the see all their input easily if they need to?
I suggest that for developing a mobile website is to use the target smartphone for a few weeks to understand how the device is used in the real world.
I'm afraid you cannot use current asp-View to mobile especially for iPhone. There's special control set for iphone development - componentone.
If you web application is based on MVC or MVP patterns then moving will be not difficult.
Recently we have developed a site for iphone users, we are using asp.net/sql for normal site.
But when you look at mobile sites, mobile normally have small screens and some time optimization problem.
We use jqtouch for mobile development. A JQuery plugin for mobile web development on the iPhone,Android, iPod Touch, and other forward-thinking devices.
Learning Video
Getting started
Establish the context for the mobile site: is there subset of information that is more relevant to your mobile users? Maybe your regular site has apps that are irrelevant on mobile devices? Either way, you should create your mobile site separately in a mobile folder! You can then use a sub-domain to reach it: for example, http://m.mysite.com
You can use a combination of CSS Media Queries and 51degrees.Mobi to detect browser features and render the correct size layout depending on which type of device the user has.
http://html5boilerplate.com/
http://www.modernizr.com/ (this is included in HTM5 Boilerplate)
http://51degrees.codeplex.com/
Do not make the stupid mistake of following current fads like "Responsive Web Design" which attempts to squeeze a desktop version of a website into a mobile screen. Above links should get you started.
When i create web app for all mobile devices, what are all things need to follow,
Is it enough to create single html app for all device?
Or, create every single app for a device based on web browser?
Is there any Framework has overcome above mentioned issues?
Thanks in advance,
sri
No - different phone browser have different levels of HTML compliance. Compare iPhone/Android browser with, say, a 3 year old Nokia phone (that most corporate users probably have to use)
No - there are far too many browser/device/operator combinations for you to write individual web apps. This is known as the mobile web fragmentation problem.
Luckily yes - have a look at http://wurfl.sourceforge.net/ or http://deviceatlas.com/. These frameworks let you write one web app (within some limits). These frameworks will recognise the browser (through the User Agent) and output the most appropriate HTML for that device. They can also deal with issues like resizing images for lower end devices.
You need to be aware of the screen size as i think it's bad form to have to scroll left and right as well as up and down.
also, keep the page sizes small as your page may not be the only one open so you want to give users the ability to open more than a single page. also helps in speed and keeping the cost for the user down.
remember to have text size at a readable scale as mobiles are used not only stationary but also when in motion and being bumped around.
My wish is to know how I can program a mobile website, that fit to all mobile phones.
Are there any special approaches to recognize a device and render the code according to it?
Which tools and coding languages are required?
My first thought was to hold the website in XML, which would be parsed depending on the device.
You have to consider old phones, even devices with only wap support.
For example: The mobile website has to recognize Nokia N75 and render/send the code that looks optimal for this device. Same thing with an iPhone or a Motorola Razr.
There are all sorts of problems associated with developing mobile websites. Doing it well takes a lot of time and effort, as phones have such varying support of web standards. There are tools that do it for you, such as the Mobile Web Toolkit and Vodafone's PartnerMl. These tend to force you to write your pages using dedicated XML tags which describe a limited set of elements and styles that can be rendered on the page. The phone requests these xml pages, and the server side software intercepts the request, examines the type of phone (the User Agent), and serves back markup appropriate to that phone. The disadvantage of this system is that it is very inflexible; you are limited to the set of XML elements that the tool supplies, rather than the full flexibility of HTML.
If you want to do it yourself, essentially, you have to do the following.
Using server-side code, examine the User Agent in the Http Header. This tells you what kind of phone/browser made the request
Output appropriate markup and CSS for that user agent.
Useful tools are the User Agent Switcher add-in for Firefox. Using this, you can, for instance, visit the BBC's website, pretending to be various devices. You will see that the BBC outputs 3 or 4 versions of its markup, as well as 3 or 4 different versions of the CSS, depending on the user agent.
mobiForge contains useful information. WURFL and DeviceAtlas are databases that allow you to determine the capabilities of the device that has made the request.
You will quickly realise that you will have to keep your design simple, and it's best not to rely on Javascript, as only the most modern phones can handle it well.
XML is the way to go.
From there, you mosey on to parsing out and acting upon the Agent tags in the request.
From there you can choose (assuming the device supports it), having the device render it via XSLT, or you can apply the XSLT on your end and stream down the appropriate markup language for the device.
In the end, you end up with a specific "rendering" per device. Ideally, the more compatible the devices are with normal browsers, the close the final XSLT is to each other. But you'll still likely have a version for each device that you support.
The beauty of this is that you can add devices incrementally, as time and demand permits. And as devices converge, you gain value by being able to converge your renderings. Also, your back end stays the same no matter what.
Finally, it also works great for non-mobile as well.
Yea, it's a burden to support the different devices, but that's just a truth of the marketplace.
One way is to use strict html with very clear semantics and minimum of css tricking. Do only use relative measures (for example em and %). Trust the browsers default values, because they are in one way optimal for every device, more or less.
Nowadays there isn't exist good tools to do this.
A good practice is to respect the different W3C standards about the accessibility (like the WCAG, the XHTML, etc).
If you made your web site the most accessible as possible it'll be more adaptable. (independently from device, screen size, with or without screen touch...)
If you want more information you can read one of my article about the web accessibility here if you want: Guideline to move a website on a mobile device.
However you can use some meta tags to allow the web browser of the phone to adjust the content like this for the iPhone:
<meta name="viewport" content="width=device-width">
You might wanna check out WURFL
Following iPad's announcement and its SDK (iPhone SDK 3.2), porting apps to iPad becomes an important issue. What guidelines I should follow in my iPhone apps to ensure I can port it to iPad as seamlessly as possible?
The different resolution is particularly an important issue. While the iPad runs iPhone apps unmodified, it's not really the desirable behavior for a native app. How can we make our iPhone apps resolution-independent so that they can run gracefully on all resolutions like most desktop apps?
If you've been using IB and setting the resize behaviors of elements properly, and also coding frame coordinates all relative to each other you are half-way to having a UI that can potentially scale to a larger screen.
From the screen shots there are new kinds of action-sheets as well, potentially attached to UI elements instead of floating - if you use overlays today they will probably work about the same but you may want to consider changing placement from the center on larger display.
UPDATE:
Now the event is over, and registered developers can download the SDK - although we cannot talk about specific features here just yet, read through ALL of the documents related to the new OS version as there are a number of things aimed at helping you transition to supporting both platforms. Also before you start using custom libraries for things take a look through the API changes to see what new abilities might be supported that are not today.
Generally speaking, what I said above about IB holds true, and also you should start thinking about how your apps today could use more space to present more information at once instead of being split out over multiple screens. Also if you are doing any projects right now that use images, make sure to initially design the images large enough that you can also use them for higher resolution tablet applications.
It is far more reasonable to expect users to input text (and larger amounts of it) than with a non-iPad device.
Nothing, it appears. Although we don't have the SDK quite yet. It will all existing run iPhone app without an issue, albeit at reduced resolution.
It remains to be seen how much of the existing iPhone SDK is shared with the iPad SDK UI wise.
Judging by what has been said, absolutely nothing. You will have to adapt to the new screen size and better hardware all together, if you want to take advantage of the features that the improved device offers. The lack of a 3g module is also something to consider if your app(s) rely on that functionality.
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.