When displaying web content within an iPhone App, we can generally choose between displaying that content within a UIWebView, or popping open an instance of Safari.
I've generally found that for related content, the experience of displaying the content "in-app" by using a UIWebView is cleaner (maybe in a modal view or navigationcontroller), though it's a bit more work to do so.
For possibly unrelated content, I'll generally go for Safari.
Is there any established line of reasoning for picking one method over the other?
EDIT: Along with the technical, what's your reasoning with respect to user experience?
Last I read, Safari will execute JS much faster than an embedded UIWebView. The UIWebView, as it is used in user-generated apps, will not precompile the JS for improved speed.
It looks like this deficiency may go away iOS 5.
With respect to the UX, I think it depends on when the web content is displayed to the user in the user's workflow. Also, how frequently it is done & how distracting it can be? These things matter because you want to keep the user inside your app for the maximum amount of time (there is a good chance that the user won't come back). It is frustrating for the user if she has to leave your app to go to Safari multiple times & return back to your application within a short span of time. Moreover, if by any chance you have specified that your app be terminated if it is sent to the background, then you should not be launching Safari.
For example, the same factors hold when you create you Settings page. To quote from the HIG,
Applications then have two options for presenting preferences:
Display preferences inside the application. OR
Use a Settings bundle to
manage preferences from the Settings application.
Which option you choose depends on how you expect users to interact
with them. The Settings bundle is generally the preferred mechanism
for displaying preferences. However, games and other applications that
contain configuration options or other frequently accessed preferences
might want to present them inside the application instead.
HTH,
Akshay
Related
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.
I am building a web-based tool for internal purposes for my company that runs on an ipod touch. It's working fine, but there are a few quirks such as not being able to auto-focus on a text field when a page loads without the user actually tapping the screen (I can "focus" the field, but the keyboard is not active). Additionally, I cannot programmatically trigger sounds to play (I am using the jPlayer library). What it seems to come down to is this:
Is there some way I can trick the browser on an ipod touch 4 to thinking the user has actually tapped a specific div on the screen? If I can do that, I can solve every other issue. Since this is for internal purposes, I am free to make any modifications needed. However, I need to able to do keep the "app" code in HTML5 and JavaScript for a myriad of reasons. Perhaps an app with a modification to safari to allow this, then I can run my site in that app?
Perhaps an app with a modification to safari to allow this, then I can run my site in that app?
Yes, you could write a really simple app with just a UIWebView in which you display your HTML5 based app. If you need extra things such as back button etc. you would have to implement that (it's also not very difficult). The UIWebView should behave mostly exactly like Safari, so it should be a de facto "app with a modification to safari".
You could then give the right element focus and call
[webView becomeFirstResponder];
The sounds could also be played programmatically by simply requesting the appropriate URL.
I think with this setup the additional effort in terms of coding beyond your existing web based tool is minimal. However, this assumes you have Xcode, know some basic Objective-C and are familiar with the procedures of ad hoc or company distribution of "real" apps.
You can try to use a timed event
During the development of my iPhone app, I decided to integrate Google Maps by including a UIWebView with a URL I construct pointing to maps.google.com. The problem is that the website tries to get the user's location, displaying the "This app wants to use your location". This creates a number of issues for me, which I can explain if necessary.
Is there any way to disable the UIWebView / Mobile Safari from asking for the user's location. The only workaround I can think of is to use Google's Javascript v3 API to make my own map, but I would have to get a license and I'm not 100% certain I would be able to disable asking for location (although I think I can).
Does anyone have an alternate workaround or way of tackling this issue? Thanks!
I believe I found a suitable workaround for now. I remembered that you can embed maps from Google in your website using an iframe. I checked the url they construct to do this and noticed they appended an extra parameter, "output=embed". I appended the "output" variable in the url and pasted this into Mobile Safari on the simulator and it no longer asks me for my location.
The only drawback of this is that I can see so far is that there are some extra UI components on the page as it includes both the mobile controls and website embed controls on the page. Also, I have not tested this on an actual device yet.
Edit: Testing on the device showed that the embed controls don't work, but the mobile controls work as does every other aspect of the map.
Use an MKMapView instead.
(I'm assuming there's a reason you're not using MKMapView for this task and you're stuck with the UIWebView)
You might try asking for user location earlier in your application via CLLocationManager, i.e. right after launch. The permission alert will not be shown more than once. (whether the user chooses to allow or not, which you do not seem to care about)
Not entirely sure that this will work in your case though, UIWebView may still prompt for permission to share location data with the websites it shows.
Assuming it's done via JavaScript, you could try injecting some javascript in - (void)webViewDidStartLoad:(UIWebView *)webView using -[UIWebView stringByEvaluatingJavaScriptFromString:] (e.g. you could set the location-requesting function to null). I'm not entirely sure how well that works while the page is still loading, though...
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.
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.