Is there a way to enable or disable sending crash report depending on a particular criteria. For example if want to send the crash report only if the device is connected to wifi and not through cellular network
Or if we want to send the report at a later time triggered by a user click a button.
As of now there's no way to do this via a criteria. You can either turn on/off crashing on the Crashlytics website. As for your second question this is the only way for now: http://support.crashlytics.com/knowledgebase/articles/92530-can-i-toggle-whether-or-not-a-user-needs-to-give-p
I was talking a while back with one of the members of their team and they said they may look into turning off/on the ability to collect crashes with a check box or something. So we'll see if that happens in the future. :)
Edit: actually see if something like this suits your needs
How to disable Crashlytics while developing
Related
We have uploaded an update of our existing app (WASFAT) as internal testing build. We can access it successfully.
Now I want to leave from the internal testing and want to access the live build.
There is not leave button the playstore wasfat page. Please have a look at the attached image.
When we have released beta version, we had that leave button. But in the internal release, we don't have it.
How can I get out from this internal testing mode? How can I access the original live build? Also I don't want to remove my id from play console internal testing.
Thanks for any suggestions
As far as I know, you can opt-out of internal testing with the same link you used to enter in the internal testing program. Also, you need to remove your email from internal tester. However, It will take some time to be able to access live mode again
The simplest way I have found is to just switch to a different account within play store.
Open play store afresh
On top right, tap your account icon (or where ever it is located)
Click the drop down and tap "Add another account"
Later on it is just a matter of selecting an account, no password entry needed if done before.
The advantage of this is that you don't have to wait for Googles services to register that you have disabled a testing account. When you need to enable the testing account you will have to wait again. So this is pretty nifty for me.
I'm reliably able to restart my phone, and have changes to beta status reflected immediately.
I want to make an application which will send information to a server about user's location every 30min. It is needed to provide location specific push notifications.
I need such functionality for Android/iOS, which would work in background (also if device is restarted). I found some articles covering background services and I created background service doing that, but after phone is restarted it won't work.
Is it possible with Android and iOS? How can I achieve that?
With iOS, no. With Android, yes.
Apple has gone to great lengths to limit what apps can do. You can do some things in the background for an extended period of time (GPS, play audio, Voip, etc), but after a reboot your app will not be restarted until the user opens it again. There are exceptions to this. Voip apps are allowed to restart after a reboot, but apple will not approve your app for the App Store unless you actually have a place for a user in your app to use the Voip feature. Geofences are a possibility, but I haven't had experience with that feature yet. In my experience, Apple does whatever they can to make sure your app doesn't run forever.
With android, there is more flexibility and what you propose is totally possible. I've listed some important links below, since most of those solutions are far better documented than what I can do here.
Essentially you need to register as a boot receiver and then send an intent to start a titanium android service when the boot event is received. I don't have experience with starting a titanium service, but I'm sure its a simple intent you need to fire. Either way you'll need a module for this native code. I attached a link to a bencoding titanium module that may help you, although there may be some others out there. You may even need to code one yourself.
Samsung is notorious for stopping your app with their SPCM feature. You may want to familiarize yourself with it. I've added a stackoverflow discussion link below.
I don't know all of your system requirements but honestly, for any app I would try my best to not run forever. It will hurt the battery life for your users and will add a lot of complexity. Maybe you could simply have the app check the GPS coordinates when it receives a push notification and decide right there and then whether to present a notification to the user? Just something to consider.
Either way good luck!
How to start an Application on startup?
http://docs.appcelerator.com/platform/latest/#!/guide/Android_Services
https://github.com/benbahrenburg/benCoding.Android.Tools
Dealing with Samsung SPCM killer
I have an Array of ArrayBuffers that I send through WebRTC from peerA to peerB. The major inconvenience that I'm experiencing is this: if peerA changes the tab to another one, then he is sending at a horribly slow rate. When peerA comes back to the app's tab, the sending speed hops back to normal levels.
Is there any way to address this particular problem?
I had a similar issue when I was slicing the files, that a change of tabs dropped the rate, and overcame this by using WebWorkers. As long as I have searched the WebRTC methods are not accessible from WebWorkers (just many people asking for this feature).
Any ideas?
There's a demo page at https://webrtc.github.io/samples/src/content/datachannel/datatransfer/ that will generate and transfer data. I'm unable to see any issue like the one you describe when I put the tab in the background. If this problem persists, please file a bug at https://bugs.webrtc.org.
I believe this may be a problem with the system timer resolution. Chrome sets this to 1 ms for certain active tabs, and sets it back to a higher value for backgrounded tabs to preserve battery life. To test this, try switching to a tab that is playing a YouTube video, and see if the send speed drops in the meantime.
My Windows 8 app needs to run a background task triggered by the receipt of raw notifications sent from Windows Phone 8 apps. Responding to that event to invoke a background task is apparently only allowed for lockscreen apps:
http://dotnet.dzone.com/articles/windows-store-app-development-10?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fdotnet+%28.NET+Zone%29
Normally, the user has control of whether they will allow an app to be a lockscreen app or not. In my case, though, it must be such or be basically braindead. So, can I enforce that: IOW, inform that users "Install this as a lockscreen app, or don't install it at all"?
What I mean is: assuming the user retains ultimate control, will letting them know that the app won't work well without them allowing it to be a lockscreen app cause it to fail certification?
You bet, that's how it's done.
Want to force them to allow it? Disable the "Block" button. (just kidding, you can't)
Remember, it's your app.
Check out how the Store app "supports" snap view. That's a nice example to show certification requirements can be "met" at the bare least implementation.
When you read the cert reqs. read them literally.
Responding to that event to invoke a background task is apparently only allowed for lockscreen apps:
Not exactly true. But anyway, the short answer to your question is no. And in reality, I can't see why the user would want to use your app, if it were to constantly do things in the background and thus drain their battery-life, for no good reason.
You might want to detail what your app actually will do, for more accurate advice.
No, only the user decides what is, or is not, on their lock screen. Because a user decides what is on the lock screen app list, apps preferably should provide a decent degraded experience if they are not on the lock screen. Messaging can be provided in the application to make the user aware of the degraded experience, but again, it is ultimately up to the user.
To answer your question "will it fail certification" no. You can programmatically request that the user promote your app to the lock screen when you run, but you should consider degrading gracefully if they don't. (E.g. register for a timer event to give your app some time to periodically update itself, or send a notification through WNS and handle it then.)
While it's great to assume that your users will want to run your app under the lock screen, providing a consistent, delightful experience under different conditions is what will set you apart.
How can an application perform stuff when its actually closed like google+?
I notice that I got a notification from huddle chat from the google+ app for iOS. But google+ was actually not active, it was closed. Same situation with Whatsapp, I always get push messages both if the app is closed or active.
This kind of behaviour seems for me to be impossible to implement. From other questions I know that we cannot register some kind of background process. How do this apps handle that?
Can I still listen form something when my app is minimized?
When my app is just minimized but not closed I know that a certain method is called. Can I perform a repeating update task, e.g. read geo data?
The apps you mentioned use something called Push Notifications which work regardless of your App being open/in the background/closed. They are notifications sent to the device when an action happens and most of the processing is done on the Server (The notifications are not generated by the App itself. A server pushes the Notification on).
Apple has a fantastic section on Executing Code in the Background when your App is minimised which should provide most of the answers you need. It even has a dedicated section on explaining the Geo Data capture which should help you in this case.