I have a banner Advert view (could be an iAd or another type) and It loads an advert.
Now after it has loaded, I might want to move it offscreen (for example when I load a complex UI, I dont want to confuse the user, so I hide the ad).
My question is, will the advert know its offscreen? I.e. Will it stop updating its CPM and adjust advertising revenues accordingly, or will I be violating some kind of terms of service by pretending I am showing an advert when really its hidden?
The iAd ADBannerView will detect that it is not visible, so you can assume it will take appropriate action. There is no way to make a categorical statement about any generic advertising program.
Related
I am adding camera using {[UIImagePickerController availableMediaTypesForSourceType:UIImagePickerControllerSourceTypeCamera]} as a subview to a UIView with fixed boundaries in my app.
Everything is working fine. But all the examples i see shows displaying camera as a modalcontroller as single screen. My doubt is, are there any cases that APPLE will reject if the camera is added as an subview to a view?. Should it be only shown as a full screen modal controller?
There is no rule that says you may not use camera view as a subview. It's all down to the specifics of your requirements and your app. Apple probably won't reject your app just because of such use of the camera view.
For example, Layar app is using camera view as a background for their overlays - clearly not a modal controller.
At the same time, consider the user's experience. If you are providing your user with the ability to take a picture with the camera and then use this picture in further application logic, then using it as a modal controller may be a better approach, as it provides the user with a consistent experience across multiple apps: users do get used to certain experiences and you need to have a valid reason to go against those consistent experiences.
At the same time, if you do have a valid reason why you want to have camera view as a subview (for example, display an overlay layer over it or apply a filter to the preview, or whatever else), then this is a perfectly valid reason for your UI design decision.
So, to summarize, there's no rule against it, but keep the user's experience in mind. Also remember that Apple may choose to reject your app for any reason they choose - and they don't have to explain it to you. At least, that's what you're agreeing to when you join the developer's programme.
I'm building an iPhone app (in iOS 5) with several different views, one of which contains a map (also has separate view controller). The first time I go over to this view, it takes a while for it to load, and things such as animating pin drops also don't work well as a result of it. Not to mention that it takes a bit for the location to stabilize.
What I want to know is if there's a way to load MKMapView before a user goes to that view, so by the time they get there, these issues aren't present anymore.
I've already seen this and this question but they haven't been very helpful. Keep in mind that I don't really need to interact with that view before I get there, I just want it to be fully loaded by the time I go there.
I want my view controller to display different views based on a condition that depends on some runtime checks (lets say a uiwebview at even hours and a form on odd hours).
What is the best pattern to achieve it in iphone project? Maybe I can hide controls based on aforementioned condition or maybe it is better to load different views?
or maybe i should load different view controllers and make the check in my parent view controller?
The iPhone UI is so small and crowded that you are usually better off creating a different view/view-controller pair for different UIs. Hiding UI elements leaves gaps that are very noticeable and manually rearranging the UI elements on the fly is a pain.
More importantly, different views communicate to the user that the app is in a different state. You don't want the app to switch to a different state without informing the user. It's hard enough for them to understand what is going on without confusing them with UI slight of hand.
It is very bad UI design to have the same user action present a different UI for no reason discernible to the user. For example, presenting a "a uiwebview at even hours and a form on odd hours" would be a fantastically bad idea because the user would have no idea why clicking on a specific button sometimes gets them a web view and a form view other times. Do you expect the user to check the clock before clicking so that they know what to expect?
If some UI element is unavailable for some reason e.g. no network access, then it's better UI design to present the element as disabled instead of disappearing it. The interface grammar teaches users that grayed out controls are temporarily unavailable. That is much less confusing that a constantly changing UI.
I have used to loading a default image in my appication. So i have set to,
Sleep(3); in my delegate.m class.
But sometimes it will take more than 6 to 7 minutes. So i want to display the image 3 seconds only and then it goes to my appilcation based on my requirements.
Which one is best way to do that?
Sleep(3) or [NSThread sleepForTimeInterval:3.0] or something else;
And i must display the image 3 seconds only. Please explain me.
(Note: And I declared setter and getter methods only in my deleagte class.)
Please explain me.
As Rob noted, Apple strongly recommends against a splash screen unless it hides some necessary behind the scenes process (like loading game graphics.) It is so strongly discouraged that some people have claimed that their apps have been rejected for using an unnecessary splash screen.
The default.png doesn't exist to create a splash screen. Instead it exist to allow you to create the illusion that your initial view loads faster than it does. You supposed to use it to provide an image of your initial view so that the enduser can begin to cognitively orient themselves to the interface. By the time they have oriented themselves to the interface and moved their finger to touch the interface, it is live.
Why? Because iPhone apps are supposed be quick in, quick out. People don't sit down to use them at a desk like a desktop. People use then on the go. Sometimes they use them in the middle of a conversation.
I tell my clients to test out the usability of their apps (except for games) while walking, riding an exercise bike etc as well as in the middle of a face-to-face and phone conversation. In those circumstances, a three second pause is a big deal and very noticeable especially if the app is a practical app. Imagine if every time you opened the Contact app you had to pause three seconds to see an Apple splash screen. You would get peeved in a hurry.
The key thing here is that an unnecessary splash screen doesn't add any value for the user. It is a selfish act on the part of the software publisher to eat the end users time so that the publisher can build brand recognition for the sole benefit of the publisher. Wasting three seconds of the users time every time they use the app adds up in a hurry. (In my experience, it also makes the user perceive that the overall app is slow and clunky.)
However, if you do want to shoot yourself in the foot or if you have a client hell bent on a splash screen, you do it like this:
The splash screen appears until the first view loads so you delay the loading of the first view. In the app delegates applicationDidFinishLaunching: method, remove all the code that loads the first view into the window. Replace it with a NSTimer. Put the code to load the first view in the timer's fire method.
With that setup the app will display the default.png as it launches, when it gets to applicationDidFinishLaunching:it will appear to pause from the end users perspective because no view will appear to replace the default.png.
You should note that the standard launch time for an app is 3-5 seconds. So you may not have to do anything to show the splash screen for 3 seconds. It might happen automatically.
Apple strictly recommends against this (using sleep in this way), especially in the scenario of showing a splash screen.
The best thing to do is create a view that looks like your Default.png file, then have that be the first NIB.. you could then set an NSTimer to transition (with animation if you want) to your main view/window/controller.
The Apple UI design guide suggests that a UIPageControl is ideal for presenting the top view of a utility app.
Would a paging view that appears at the 2nd or 3rd level down inside the main UINavigationController view trigger a fail during the App review process?
In my App I have inserted a 3 page view at the second navigation level down in my productivity style app. Each page presents a question and requires an answer that might by a multichoice tick or text box entry. The questions could be stacked vertically in a multi-section table but in my prototype flicking through the questions horizontally feels very natural.
However I have not seen an App store program that uses paging as I have.
I asked Apple a similar question recently and got back:
"Thank you for contacting the iPhone Developer Program. Apple is not able to provide pre-approval to developers for proposed application submissions."
In the end it really depends on the reviewer, the specifics of your app, full moon, etc.
Personally, I would simply try it. If the interface looks good and you think it will not confuse users, then just submit it.
Also, being rejected for stuff like that is not the end of the world. You just have to replace it with something similar. Happened to me once or twice. It is usually not a complete blocker.
Although you will probably not fail app review, I believe using a UIPageControl may be confusing to your users. As you pointed out, I can't think of any apps using the UIPageControl in this manner. The following quote from the iPhone Human Interface Guidelines is informative:
A page indicator gives users a quick
way to see how many views are open and
an indication of the order in which
they were opened; it does not help
users keep track of the steps they
took through a hierarchy of views.
Because the views in a utility
application tend to be peers of each
other, a page indicator is sufficient
to help users navigate through them. A
productivity application that displays
hierarchical information, on the other
hand, should offer navigation through
the elements in the navigation bar
(for more on this, see “Navigation
Bars”).
From your description of how this portion of your app is supposed to display, it doesn't sound like these pages with questions on them would be considered 'multiple views'. In addition, you probably want your users to answer each question sequentially and move on to the next. The UIPageControl is designed so that a user can switch between any of the views in any order they choose, not only in one direction.
This sounds much more like a hierarchical design, and this portion of your app would probably work a lot better if you used a navigation bar along with a UITableView. Requiring your users to answer a question by tapping a multichoice tick box, and then make them figure out that they need to swipe in a certain direction to get to the next question would not be obvious to a user, and could be much more intuitive. For example, as soon as the user selects a tick box, you could just programmatically navigate to the next question. Or, have a button at the bottom of each screen that's labelled "Next Question", which would transition to the next screen.
Hope this helps!