I'm working in an application that loads a few remote jsons at startup. The application has been programmed to do certain tests on the incoming data to prevent invalid states and to detect possible human errors. However, I am not sure of how we should treat such situation at the GUI level - our initial idea was to display a "Oops there was an unexpected server error. We are working to solve this issue. Please, try again later." popup to quit the application when the user hits an "Ok" or "Exit" button.
Apple apparently discourages exiting the application from within your code: https://developer.apple.com/library/ios/#qa/qa2008/qa1561.html
What good alternatives are there to handle this situation?
Update: I updated the error message above, since it was misleading.
I encountered a similar issue. My app was useless unless it could establish a connection to a server.
There are two ways around this:
place holder text, this can hold the position until you can get your json arrays, or at least allow a back drop for popping an alert.
Load a view with all interaction disabled, with a small message box saying "connecting..."
Basically I have taken the first responding storyboard frame and disabled everything that the user could touch. I just allowed static interaction like pressing a button to get to the about screen.
Don't beat yourself up too much about it though. If you don't have any connectivity at all then none of the user's apps are going to be functioning properly. I think in this state, from a GUI perspective it is mostly about damage control and protecting the user experience.
It's tough to be graceful at startup. I suggest presenting UI modally while your app gets ready to run. I asked and answered this SO question which shows a clean way to do the UI, including nice transition effects.
As for exiting: Your app should never self-terminate (copyright Arnold Schwartzenegger circa 2003). The correct app behavior when it can't get something done that has to be done modally is to alert the user and give the option to retry. If the user wants to not retry, there's a hardware home button on the phone.
Related
My program needs to react to the user not taking any action on a GNotification.
More specificially, a piece of data is written to the database only if the user does not press the "undo" button on the notification sent after the data's creation. My target deployment scenario does have notifications enabled and a real timeout value.
To be precise: Moving the notification "away" / deleting it should also count as such a timeout.
1) Is there a built-in way to 'listen' to notification timeouts?
2) If not, how could I still implement similar behavior?
I would use the D-Bus org.freedesktop.Notifications interface. Although it is still a draft specification, it does appear stable. My experience accessing the D-Bus interface using Vala has been that it is easier to use and gives the full feature set of the specification. GNotification doesn't seem to be as feature complete.
From the draft specification you will see there is an expire_timeout argument of the org.freedesktop.Notifications.Notify method. That should fit your time out requirement, although I've not used it personally. There is also a org.freedesktop.Notifications.NotificationClosed signal that will allow your program to be notified when the notification is closed, including because of a time out or if it was dismissed by the user.
This post about the screen lock re-design for GNOME Shell 3.10 might give some indication of what notifications are capable of. The post includes some screenshots of notifications appearing in the lock screen.
I have a little issue with a form in a delphy XE2 application:
It's an old issue on this application and i have begin to work on it just since a little time.
When the user choose to launch the process with a button's event, my application launch a connexion with an OPCServer , an SQLServer and construct the form for a good following of data take on the tow servers.
The construction of my form involves a blockage of the interface (for approximately 15 sec) because of lot's of data which are necessary for make it.
When it freeze, if the user want drag the form, she go far away, and usually with the TMainMenu which go out of the screen. After that, it's impossible to use the application because we can't drag and we need to close and re-open.
In the old version, the form be already construct before the connexion. So the modification for a dynamic form isn't in link with this issue.
Life of my event :
-Open connexion with OPC Server
-Open SQL Connexion
-Send SQL Command Text
-FieldByName('') for update my UI (Button.Caption// TPage.TStaticText.Caption // TPage.Label1.Caption)
-FieldByName('') for update an array of record
-Close SQL Connexion
-Open SQL Connexion
-Send SQL CommandText
-FieldByName('') for update an other array of record
-Panel.Visible(false)
-TPage.Panel.Show;
-TPage.Panel.BringToFront;
So I haven't MainForm modification can change its position.
I'm a young developer, so I don't know why it moving and what I can make for repair that...
If you want a part of code, ask me what and i edit this, it's very long and i don't want spam answer.
Thank's for read.
The core of your problem is that you have a lengthy process (form construction) which completely blocks the main thread so your application isn't able to process normal Windows messages at the same time. That is why when you move your application it doesn't properly update its interface.
Now based on your description you already have this form construction process split into multiple steps so you could call Application.ProcessMessages between them.
This will force your application to update its UI part.
But beware calling Application.ProcessMessages often could hurt your application performance quite a bit. Why? It is usually a lengthy process because it forces your application to process all the messages that are in its queue.
Normally not all of these messages get processed as soon as they arrive. Windows groups them in the message queue by their priority list, making sure that high priority messages like WM_PAINT are processed as soon as possible while some other low priority messages like demand for application to respond to OS so that OS can see if the application is still working are mostly processed when application is idle or when they are in queue for certain amount of time.
So that is why Application.ProcessMessages can be so slow as it forces your application to process all messages regardless of their priority.
Also bear in mind that using Application.ProcessMessages can in certain scenarios actually become a bit dangerous.
Let me give you an example:
Lets say that clicking on a button starts a lengthy job which can take some time to finish. Now in order to allow your form to be updated you call Application.ProcessMessages in certain intervals. So far it is all good. But what happens if user clicks on that button again?
Since you are calling Application.ProcessMessages which forces your application to process all the messages and since clicking on button creates a MouseClick message which then fires buttons OnClick event which then executes the OnClick method that has been assigned to buttons OnClick event in the end this will cause the same method that was executed on first button click to be executed again.
So now you have this method partially done from first button click and same method executing again for second mouse click. Now the method that was executed from the second click will finish first and then the method that was started from first button click but was interrupted with Application.ProcessMessages handling the second button click will continue its execution to the end.
This all can lead to strange bugs which are hard to track, because you as a programmer normally don't predict that your end user might have clicked the button twice.
So to avoid this I strongly recommend you implement some safeguard mechanisms to prevent such scenarios by temporarily disabling a button for instance.
But the best solution is always to show your user that your application is working which in most cases will dissuade them from clicking the button again, but unfortunately not always.
You should also take a good care when dynamically constructing a form to enable the controls only after all of the controls have been successfully constructed. Failing to do so the user might click on one of your controls and that control could attempt to access some other control which hasn't yet been created at the time. The result hard to track bug which causes Access Violation.
You might also consider showing a splash screen at start instead of half built form. Why?
For once it is much nicer to see and it tells your users to wait a bit. And for second having main form hidden until it is fully created makes sure that user won't be doing any clicks on it prematurely.
I've decided to integrate OpenFeint into my new game to have achievements and leaderboards.
The game is dynamic and I would like user to be rewarded immediately for some successful results, but as it seems for me, OpenFeint's achievements are a bit sluggish and it shows visual notification only when it receives confirmation from the server.
Is it possible to change something in settings or hack it a little bit to show notification immediately as soon as it checks only local database if the achievement has not been unlocked it?
Not sure if this relates to the Android version of the SDK (which seems even slower), but we couldn't figure out how to make it faster. It was so unacceptably slow that we started developing our own framework that fixes most of open feint's shortcomings and then some. Check out Swarm, it might fit your needs better.
There are several things you can do to more tightly control the timing of these notifications. I'll explain one approach and you can use this as a starting point to explore further on your own. These suggestions apply specifically to iOS apps. One caveat is that these suggestions refer to internal APIs in OFSDK 2.8 for iOS and not ordinarily recommended for high level use and subject to change in future versions.
The first thing I recommend is that you build the sample app with your own product key. Use the standard sample app to experiment before applying the result to your own code.
You are going to get the snappiest response by separating the notification pop-up UI from the process of submitting the achievement. This way you don't have to worry about getting wrapped up in the logic for deciding whether the submission is going just to the local db or is doing the full confirmation on an async network transaction.
See the declaration of "showAchievementNotice" in "OFNotification.h". Performing a search in the sample app, you will see that this is the internal API used for displaying the achievement pop-up when an achievement is earned. It does not actually submit the achievement. You can call this method directly as it is called from "OFAchievementService.mm" to directly control when the message appears. You can then use the following article to disable the pop-up from being called when the actual submission occurs:
http://support.openfeint.com/dev/notification-pop-ups-in-ios/
This gives you complete freedom to call the submission at a later time provided you keep track of the need to do so. For example, you could locally serialize a flag to take care of the actual submission either after the level is done or the next time the app starts up. Don't forget that the user could quit out of a game without cleanly finishing a level.
I'd like to integrate something like a welcome panel (welcome screen) into our iPhone application to inform our users about updates and new offers when they launch the application. I have the following thoughts and doubts:
No user input required
Shows generic HTML without any action from the user point of view, the thing closes after 2 or 3 secs and has a close button if you want to close it manually. This is for advertising and tips.
This should be very simple to implement
User input required
Shows generic HTML with an action required from the user point of view, for example a survey. The user should be able to skip it
same as above, but is it possible that the user submits something on a HTML page and that causes also something to happen within the iPhone app (maybe via Java Script)? For example the user submits a survey on the HTML page and then app closes the current screen and continues to the next screen (i.e. the real application)?
Is it also possible to receive parameters (e.g. an ID) via a HTML website? e.g. if the user receives an offer on the HTML welcome panel, then he clicks on it and it takes him directly to a screen in the iPhone app with content loaded from a server (via JSON) depening on the offer id retrieved through the HTML page.
We prefer implementing it via HTML, because it gives us more flexibility. But I'm also open to hear other suggestions.
Thanks
Rengers answer is the correct one to accomplish what you want. However, the real correct answer is "Don't do that in the first place."
From a design perspective, a "Welcome Panel" or any kind of startup/splash-screen is a bad idea and the Apple Documentation tells you explicitly not to use them. Even for games, they're a bad idea that should be avoided if possible.
It's not a "Welcome Panel" it's a "wade-through-all-our-marketing-crap-before-you-can-actually-use-our-app" panel.
Mobile apps aren't like apps for regular platforms. Non-mobile hardware is faster so the obtrusive startup screens load faster and can be dismissed faster. Non-mobile apps tend to accomplish many task and people use them sitting down for prolonged periods. Users will tolerate a few seconds wasted clicking through startup screens so they can get into an app they will use for many minutes or even hours.
By contrast, mobile apps are often used by people on the go and in a hurry. The apps are small and ideally perform a single task. As quickly as possible, people need to be able to get into the app, perform what ever task the app accomplishes and then get back out again. If you're only using an app each time for 30 seconds or so, having to spend 5 seconds each time wading through startup screens is massively annoying.
Mobil hardware is slower and operations can take longer. Depending on its complexity and resources an app can take as much as 10 seconds to launch. In your case you want to add to a startup screen that has to load, connect to a url, display and then have the user perform an operation. That will take another 5-10 seconds minimum. So you're looking at users having to spend 20 seconds or more just getting into your app.
That doesn't sound like much but try mocking up your app and then using it on the go i.e. while walking, waiting for an elevator, going up the stairs, waiting for a red light etc. Test it in social situations. In the middle of conversation say, "Let me check on that" then take out the iPhone launch your app and try to get some information from it. 20 seconds becomes a very long time in all these circumstances.
Even shorter launch times are very annoying if you have to take some action every single time you open the app just to get to the functional part of the app. It's arguably even worse to spring a startup screen on them intermittently so they never know when they open your app how long it will take to get in it. User surprise is not good design.
Instead of forcing users to do something, you should embed advertisements and update notices unobtrusively in the app itself so that people can see them while they are using the app. In the case of advertising, this has the added advantage of putting the adds in view the entire time the user is looking at the app.
I don't know how many times some idiot from marketing has come in and started a feature request with, "We need to force the user to..." The only response to those types of request is to set the marketing weeny on fire. Do that several times and they'll stop trying to systematically alienate your customers.
UIWebViewDelegate has a method that allows you to respond to interaction in a HTML page:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
Using this, you can catch any links clicked and respond to them in your application by presenting a different view.
Recieving parameters like an id can be done in a few different ways.
1) You can parse the HTML and determine it from the source.
2) You can have a javascript function in the HTML that returns the id. Call it by using
- (NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script
3) You can also use the delegate method I mentioned.
If you make a link like this: get offer you can catch it in the delegate and retrieve the id from the NSURLRequest.
I hope this will point you in the right direction.
If you do need some kind of startup screen a good option is to use the default.png. The app loads and displays that image before it does anything else.
It's usually used to display the illusion of the user interface before the UI loads completely. However, you could use it to display startup information. Since it displays almost instantly (within 1 sec) it does give your user something to look at while the app loads. In the case of a mock interface, it lets the user see the location of the interface elements and begin moving to activate them before the elements finish loading.
The catch is that the image disappears as soon as the first view loads so you have to load a view behind it that is a duplicate of the image (more ofter the image is screenshot of the view)
In your case you would need to dynamically generate the default.png when the web page updated. Upon launch it would display the information and buy the time the user read it, made a decision and touched the interface, the real web page would have replaced it.
Of course, this system won't work if you want new info at the start of each launch. Instead you'll have to generate the image during one run for use in the next.
In any case, if you launch into a web page the user did not select, I advise that you create a default.png that displays a message along the lines of "Checking for Updates and Info" (or whatever your doing) so the user won't think your app launched and hung.
how to handle error in an iphone app ?
log and exit ? show an alert dialog and exit ?
for exemple, if an image is missing from the bundle..even though it should not ...
You are never supposed to exit the app programmatically. Advise the user there was a problem, offer to try it again, etc. But don't kill the app. This is explicit in the Apple HIG.
Let the user decide your app needs exiting. Don't do it for them.
Ideally, don't get yourself in this situation. : ) Easier said than done I know.
#Genericrich has it pretty spot on:
Advise the user there was a problem, offer to try it again, etc. But don't kill the app. This is explicit in the Apple HIG.
The only advice I would add is to expect the unexpected. Just make sure your app is ready for those little blowups. This might be things like: default information to fill in the blanks, adequate alerts to let users know what's happening/retry, saving state before attempting failure prone destructive actions, and any other defensive programming habits you can think of.
As an added note if you are wanting to test network errors you may want to check out Craig Hockenberry's excellent post Slow ride, make it easy on the subject.
Alert box and exit should be fine. Short and sweet with just enough communication with the user to let them know why your software is about to not work.