On the iPhone, when your phone is locked and screen off, if a SMS message comes in, the screen turns on and an alert shows up.
Currently I am using UIAlertView to create the alert dialog (with 2 buttons).
If the phone is off/locked, nothing shows up until I turn it back on and unlock it.
Is there any way to simulate the 'SMS preview' behavior, possibly with another class, and hopefully still allow the user to interact with the buttons there?
CFUserNotificationCreate is your friend.
Not in the official iPhone SDK? Too bad, I remember that a year ago on the big presentation of the yet-to-come SDK, an Apple evangelist/chief saying that the SDK would include exactly the same API as used internally by Apple... Pfff...
/John
What you want to do is not currently supported by the SDK. You should file a request with Apple.
Related
On Android, toast notifications work differently to UWP. It simply shows a little black popup message over the top of the app. In UWP, toast notifications are indistinguishable from push notifications from the user perspective. Is there a standardized way in UWP to simply show a quick notification inside the app that will disappear after a few seconds and not interfere with the user's experience? I mean without it looking like the user has received a push notification?
This article doesn't seem to hint at anything like what I am talking about.
https://learn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-badges-notifications
The UWP Toolkit provides an InAppNotifications control for this.
http://www.uwpcommunitytoolkit.com/en/master/controls/InAppNotification/
In many cases, the Snackbar class supersedes Toast. While Toast is currently still supported, Snackbar is now the preferred way to display brief, transient messages to the user.
Take a look at Showing Pop-Up Messages to find out the most common use cases.
We ended up building something as part of our Xamarin UI library to handle this.
The code can be found here:
https://github.com/MelbourneDeveloper/Adapt.Presentation/blob/master/Adapt.Presentation.UWP/Adapt/Presentation/UWP/InAppNotification.xaml.cs
There is a sample in this repo:
https://github.com/MelbourneDeveloper/Adapt.Presentation.git
Note: the same is for Xamarin Forms, but if you crack the code open, you'll be able to figure out how to use this for any UWP app.
I am currently trying to find the most efficient way to continue a method in the background of my app.
I am probably adding location/gps to my app soon, so I was considering using that flag to keep the app Active in the background. However, I do not want to add that flag yet because I want to post an App Update before I add the location functionality.
I know the exceptions;
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Besides asking for a more generic idea then these ^, can someone explain the "external accessory" flag please? I am recording video from an outside device. However, I do not know what constitutes an "external accessory".
I also see that iOS7 has introduced new Multi-tasking functionality but I haven't seen any examples that I understand can someone also explain that? Maybe that is a viable solution?
Thanks in advance!
I am currently making an app that recommends other apps to download on the apple app store. I assumed that the only way for users to download these linked apps was to call the iTunes URL of the particular app -> the apple app store would then open pushing the original calling app into the background -> then the user would press the download button here as per normal.
Then I was playing with the app "App Hero" and they do something I thought wasn't possible. You can actually download another app to your device without ever leaving the "App Hero" application. I thought this was impossible due to sandboxing. They have a modal segue to what appears to be an embedded app store where you can commence installation of another app. This "embedded" app store doesn't have the usual UITabBar running along the bottom but everything else is basically the same.
Does anyone have any idea how they would have achieved this? It doesn't appear to be a UIWebView, perhaps I am wrong. And is this against any of the apple regulations?
*This is no way an advertisement for "App Hero". I am genuinely impressed/confused how they are able to do this and would love this functionality in my own app if it is allowed.
The class you are looking for is called SKStoreProductViewController. Docs here.
I need to build an app such as "Messages" in iPhone, but easier (don't need to send messages to server, only in datebase). I was faced with some questions.
http://www.ibm.com/developerworks/library/x-ioschat/index.html
In this tutorial messages look like TableView, how can I do them such as in iPhone standard messanger (comics speach). And how can I implement bar with camera button, text box and send button (what class is responsible for this)?
You are in luck good sir, there is already a class that can fix you up with this and avoid all the work, it's called AcaniChat (screenshot provided). Or you can even see at Sam Soffle's SSMessagesViewController, he is a well known iOS developer who built this class.
It will definitely help you, if you want to mimic that behavior.
I want to develop a screensaver-like app where the only way of getting back to the springboard is entering a code. Therefore I would need the Home Button action to be ignored, that is that when the user presses the button nothing happens..or something custom...instead of going back to the springboard and terminating the app.
Is this possible? does anybody know if apple will approve/reject this kind of app?
The answer to your question is, yes.
The answer to the question you meant to ask--can I ship an app through the iPhone store that has the home button disabled--is no.
If you are only publishing your app to jailbroken phones you can do it, but it will piss everyone off.
Edit 7 years later:
This is actually extremely possible now--there is a standard feature in the iPhone called "Guided Access". It's hidden under that "Accessibility" Link (With some other fairly cool stuff like flashing the LED whenever you get a call and allowing a Bluetooth keyboard to tab between controls)
It's called "Guided Access". You set a passcode, launch the app then triple-click the home button to start guided access.
It disables exit and allows you to designate regions of the screen you can't touch. You can also set a time limit (For kids playing which seems to be the reason a lot of people look up this question).
Tempted to edit the "Accepted answer" and throw this info in there, but that seems rude so I'll just hope people find this answer.
Annoyingly you also seem to be unable to shut off the phone--I suppose this is perfect for people who want their kids to play a game, but might not hit the original asker's problem of restricting access to a single app (I mean it WILL do that but it'll also prevent it from doing ANYTHING else).
Not with public APIS (and hopefully, not with private ones). Even if you manage it somehow, Apple will reject it for breaking UI guidelines. Moreover, even if they didn't, people could always use the iPhone's "Force Quit" equivalent to hard terminate your app.
Apple is not going to approve this type of app, they state pretty explicitly that you're app needs to respond appropriately to springboard telling the app to terminate both when things like phone calls come in and when memory warnings come in.
This is not possible with the current SDK, nor do I suspect it will ever be.
You might be able to get this behaviour via jailbreaking, but you won't be able to sell your app through iTunes, nor will Apple ever approve such an application.
You can do it like this
Install the following mobileconfig file
This will disable the home button once you launch the app
Download
Found the link Here
Apple won't allow it.
What if something emergency happens and you wan to dial an emergency phone number. You are putting the user at risk. The trade-off isn't worth it.