Manual testing for GPS on ios - testing

I'm a newbie in testing area. I have an application which has the facility to use gps and I don't have garmin tracker. I have done few tests on gps but i don't feel it's sufficient.
How to test gps manually?
What are the ways and methods to test it? please, suggest some testcases for it.

1.Need to test while traveling how the application is working with Gps connection.
2.How the Application is behaving while we got a call/Message.
3.How the Application is behaving while battery low /Automatic turn off u r phone,the current data is saved in data base properly or not
4.Need to check Battery life while using GPS

I am sure your done with smoke testing!, In that case start with Interruption testing.
Keep moving in a place, check the your GPS connectivity.
Travel to remote places where you feel the GPS can't be tracked. Check how your application responds.
Try receiving call while using the Application.
Place an alarm, check how your application responds during alarm work.
Check when your device is about to die, how the application responds. Since you'l be using GPS, chances of u'r battery drain is too high.
Check with Notification. how your application behaves.
Switch off your GPS, see if an appropriate alert is provided.

Related

How reliable is Bluetooth BLE in combination with smartphones?

We are developing a system where we can open doors with a smartphone. The chosen technique for this is Bluetooth BLE. There is an app which needs to be active in the background for providing this “handles key system”. This app recognizes and connects automatically with the door to open it.
We have a working demo on 3 different iphone models and several different android phones. The exact details of these system are not important for my question.
For our project we are in talk with some investors who says the idea is great but the Bluetooth technique is not reliable enough. The don’t say on what point it isn’t reliable enough.
We need to prove that Bluetooth IS reliable for this situation so we are looking for some best practices where Bluetooth is uses in critical situation such as a transport or health sector. Some “official” papers from a professors or university is also welcome!
We also looking aslo for examples where comparable situations where locks or something else are opened “handless” with a smartphone.
Where can we find these information, firms, papers and so on? In one line: How can we prove that Bluetooth is stable and reliable for our purposal (using a smartphone which autoconnects to some device for authentication)
I hope someone can help us else our project will be canceled!
There is nothing wrong with the BLE technology itself regarding reliability. It's rather the hardware and software implementations that will define how reliable a solution will be.
After having worked with BLE for several years I can tell that most peripheral SoC solutions are very reliable. And if they for some reason crash, the firmware is usually rebooted and restored.
Android and iOS are often the ones to blame if something isn't reliable. The Bluetooth stack running on these OSes crash quite often or misbehave and it can be hard to recover from.
For Android, sometimes Bluetooth crashes and when you try to turn it on again in it just goes back to turned off state. To recover you have to reboot the phone. I must however say that if you manage to initiate a connection and don't get any errors it will often continue to run correctly. To avoid the Android system to kill your app while it's in the background you have to use a foreground service. On some phones, like Huawei, the user must also explicitly mark the app to not being killed by the system when it's running in the background. For Android, there are also many phones with different Bluetooth controllers and some have bugs other controllers don't have. For example I once got hand on a Sony Xperia Z3 phone which Bluetooth controller cancelled a pending connection when an LE scan (running in parallel) was cancelled, but according to the HCI log the pending connection was still going on. The peripheral was advertising but was never connected to the phone. Once the pending connection was explicitly cancelled and restarted, it connected immediately.
iOS is more problematic than Android if you want BLE to work in the background. iOS will kill your app when it has been in the background for some time. To get around that, they have something called "state preservation" which is their solution to wake up the app on an incoming Bluetooth event such as the peripheral connects or sends a notification. However there are many bugs and design decisions which will lead to that your app isn't being woken up. For example see https://forums.developer.apple.com/message/65953. If your app has been terminated and the user turns off and then turns on bluetooth (or the system restarts bluetooth due to internal errors), your app will not be woken up on an incoming Bluetooth event. Also, if a bug occurs in the Bluetooth stack (which happens quite frequently), your app will not be woken up and all the events will rather arrive to your app once the user manually opens it up.

Communication is lost on wifi toggle and onDisconnect and onPeersDisconnected not being fired

I'm using code from Google's sample game "ButtonClicker2000" found here: https://github.com/playgameservices/android-basic-samples
I have 3 androids running this game in genymotion plus one on my own phone, debugging them all from android studio. I've gotten to a point where I'm trying to gracefully handle disconnect in the event of network issues. The way I'm simulating network issues is toggling the wifi on my phone. (on or off, same behavior) After that, real time messages from my phone are no longer being received by the virtual devices, and my phone is no longer receiving real time messages from the other devices. However, my phone never enters onDisconnect() and the other devices never enter onPeersDisconnected. If I exit the app on my phone after communication ceases, onPeerLeft fires on the other devices.
How can I either ensure communication between devices in a game isn't lost in the likely event that a user at some point comes in or out of range of their wifi? If that's not possible, how can I at least ensure the onDisconnect event is firing from the offending device and onPeersDisconnected event is firing on the others?
If we're going with what the documentation states, onDisconnect usually happens when there's a problem with the remote services (crash or resource problem). having the WiFi turned off doesn't look like it fits with those criteria. [onPeersDisconnected](https://developers.google.com/android/reference/com/google/android/gms/games/multiplayer/realtime/RoomStatusUpdateListener#onPeersDisconnected(com.google.android.gms.games.multiplayer.realtime.Room, java.util.List)) is called when the participants are disconnected from the room.
Determine if the onP2PConnected is called when its connected and onP2PDisconnected when disconnected (hopefully this can catch WiFi toggling cases) since I think its more appropriate when you're using real-time multiplayer.
You can also read more about it in the Real-time Multiplayer section of the documentaiton.
Hope this helps!

Does Reach-ability class keep sending / receiving data in iOS dev?

I have been working on Reachability class for a while and have tried both the one from Apple sample and the one from ddg. I wonder whether the Reachability class keep sending / receiving data after starting the notifier.
As I'm developing an app which connect to different hosts quite often, I decided to write a singleton and attach the reachability classes I need on it. The reacability classes would be initiated and start their notifiers once the app start. I use the singleton approach as I want this singleton class to be portable and can be applied to other apps without much rewriting. I am not sure if it is good idea to implement like this but it worked quite well.
However, someone reported that the battery of his device drain significantly faster after using the app and someone reported more data usage. My app does not send / receive data on background so I start wondering if it is related to the reachability.
I tried profiling the energy usage with Instrument and I notice that there are continuous small data (few hundred bytes in average) coming in via the network interfaces even I put my app in idle. However, there are almost no data sending out.
I know that Reachability requires data usage when initiate (resolving DNS etc) but I am not sure that whether it still keep using data after starting notifier. Does anyone can tell?
I am not familiar with the low-level programming, it would be nice if someone could explain how does the Reachability work.
I use Reachability, and while I haven't monitored the connections, I have browsed the code, and I can't see any reason why it would keep sending ( or receiving).
If you have a ethernet connection to your Mac, it is quite easy to check. Enable sharing over wifi of your ethernet connection. Install little snitch, it will run in demo mode for three hours after every boot. Turn off the data connection on the test device and connect it to your mac over wifi.
This will allow you to see any network access your test device is making.
If this isn't possible, you can also run your app in the simulator as the network side should be the same, so you should be able to check.
There are also a ton of other tools to track network activity, but I think little snitch is the easiest to use.

GPS connection is lost and does not recover

We have developed an application on Windows.net mobile framework and it is used on a Windows 6.5 Smartphone. for our location based application. Our application is real time and tracks our employees. We are finding that the device loses its GPS signal.
Has anyone managed to restart the GPS receiver so that it starts giving the GPS signal again. I would be ever so gratefull if someone can help. We are using GeoFramework2.0 to deliver the geographic information that you need.
Regards
Sandy
The GPS is "shut down" when no application is using it. Just close your handles and re-open them.
If the GPS on your device is part of the WWAN radio (i.e. cellular phone) it may get put in to a low power state rather than being actually shut off. In that case, you can try restarting the radio.
If that doesn't work, some GPS's will allow you to send proprietary commands to them to force a reset or clear the memory. These commands are not standard and will differ significantly by manufacturer. If you have a SiRF GPS, take a look at the SiRF Binary Protocol Reference.

WiFi communication to embedded display

I'm trying to create an embedded outdoor display of bus arrival times at my university. I'd like the device to utilize my school's secured WiFi network to show arrival time updates determined from a server script I have running.
I was hoping to get some advice on the high-level operation of this thing -- would it be better for the display board to poll a hosted database via the WiFi network or should I have a script try to communicate with the board directly over 802.11? (Push or Pull?)
I was planning to use a Wifly or WIZnet ethernet board in combination with a wireless access hub. Mostly inspired by this project: http://www.circuitcellar.com/Wiznet/winners/001166.html Would anyone recommend something else over one of the WIZnet boards? I saw SPI/UART options and thought these boards could work with an AVR platform.
And out of curiosity -- if you were to 'cold start' this device (ie, request a bus arrival time by pushing the display's on button) you might expect it to take 10-20 seconds to get assigned an IP and successfully connect to the database, does that sound right?
I'd go pull. In fact, I'd have outdoor display make http or https requests of the server. That way the server could tell it how long to show a given set of data before polling for a new one using standard http page expiration.
I think pull would make it easier to have multiple displays, and to test your server as well. I've also got a gut feeling that this would make your display more secure. Someone would have to hack your server to hijack your display.
There's a very cool looking Arduino-targetted product called the WiShield. Seems super easy to use and he provides some source code. It uses SPI for host communication. If you're not interested in going the Arduino route, I'm sure the source code wouldn't be too hard to port to something like avr-gcc. Check it out, might save you some time and headaches for $55. Worth checking out anyway.