I know there are quite a few questions that may sound similar, but they never cover my needs, so here's my own attempt:
I am pretty aware, that I can fetch the UTI of a file and use a UIDocumentInteractionController to either check if there's at least one app that can open it or ask the user to select an app, that's great.
Also the UIWebView can open a bunch of other UTIs as well, although it never tells the system what kind of and therefore never appears in the app selection dialog. So when I am sure there is no app I can still check if the UIWebView supports it and create an own view.
That works well to some degrees, until smartass apps like Dropbox appear and basically tell the system I can open every UTI!.
What now? For me that renders the whole mechanism kind of useless, I cannot use the fallback anymore and my only way is to let my app go the Dropbox-way and register every UTI as well.
Any ideas how to solve that?
Related
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
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
I am making an app for some people and they want to instantly update the app whenever they want after first submission. The changes will be like color, fonts, background color, removing a tab from tabbar...
What I was thinking was, creating a plist with entries like color, font and etc for specific views. And everytime an app starts up, it connects to a server and download the plist (if it's updated) and then load it's views according to the plist.
So for example, say the user wants to change the font from Helvetica to Arial. In plist I would have a dictionary with key named "Font" and object is the font name...So I simply update the plist with the font name "Arial" now and next time the app starts up, the font will change.
I hope I made it clear what I am trying to do. Now my question is, is this kind of thing allowed in app store? In reality, I am trying to circumvent the update system of App Store, but just wondering if it's allowed or if someone had experience doing this.
Thanks.
Your app is allowed to do these kinds of things, but be careful that your clients don't get the wrong set of expectations. The review process is not there to stifle creativity and color changes, but to prevent malicious code from running. You're not circumventing anything by using a web server to control the appearance of your app. Consider many apps which take content from the internet. You are merely taking it a step further.
The iTunes App and the App Store app have recently added a "Purchased" view without any user having to download anything new. You should be fine doing the same.
Yes, downloading content is ok. Downloading code however is not. So if the changes are due to different content you should be fine.
While nobody really knows until Apple says yea or nay, there are a few assumptions I believe to be safe:
1) If you're updating executable code (complied binary or a scripting language) you will not be accepted, and if you make it in somehow they'll yank the app and kick you off when they find out.
2) If you're updating resources (content, colors, fonts, etc.) you are probably fine, but Apple may decide to reject you anyway. Have a good case to defend yourself with if that happens.
All those changes are ok with Apple and can be performed dynamically in response to an external trigger (eg. api).
You can do whatever you want as long as you don't attempt to download and run additional code. (if you don't know what his means then you're fine). :)
First I need to mention that I'm not a developper, but I can probably work my way around enough in xcode to fix this little issue.
I submitted an application to the app store (that was developped by someone else who's not available right now), but it was rejected because it's "geolocked", meaning the application can only be accessed if you set your international "Region format" setting to Canada.
I need to know what modification I need to make in order for this app to work on all region formats. Is it a string I need to change or is it hidden in a plist file ? I have the feeling the fix is quite easy to apply.
I’ve never heard of an iPhone app using region formats to prohibit launches. I suspect your developer put this code in either out of naïveté or malice; either way, you’ll need to look for a section of code that inspects the region settings.
I'm not aware of something like "geolocking" of iOS application. The only thing you can do, which is quite close to your question, is to set in which countries is this application available. This can be set in iTunes Connect.
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...