I don't know whether this question belongs to SO or UX (or Programmers.SE) but here it goes.
We have built a mobile app a couple of months back, which we intend to alter in some major ways (like authentication and security) in next release. We published it to AppStore/PlayStore and it has a download count between 5k-10k range.
Now the question is;
whether if we retire our current API rightaway and show current version users a popup which forces them to update the app (via stores)
or
create a new API under a different URL and maintain both APIs at the same time (in this case should we maintain it forever or should we set up an expiration date) ?
EDIT:
It'll be our first and possibly last update, since our app is a cordova based hybrid app, we intend to use silent cloud deployments without relying on app stores.
I would say - for a mobile application, forcing your users to upgrade straight away isn't a unreasonable expectation. The exception to that is if you have users on an older operating system (e.g. old iOS) that cannot upgrade. Then you might want to maintain a legacy API.
Can you give a legitimate reason why a reasonable user wouldn't be prepared to update your app?
Related
I want to develop service for synchronising user specific data within installations of my app. For instance, I have in-app consumable purchase in my app, lets say credits for a game. I need these credits to be shared between both mobile and desktop version of the application. But if user has only mobile or only desktop version, it is waste of resources to store historical purchase records for synchronisation. Current credits amount should be enough.
Maybe not really good example but should do for illustration. So is possible to know if user has both platform versions or he has only mobile/desktop version? Is there any proper API I would touch for the information from sync service or from the app?
Thanks for answers in regards
So is possible to know if user has both platform versions or he has only mobile/desktop version?
There is no official existing API to meet your entire requirement directly, but you can handle it by yourself. Using AnalyticsVersionInfo class to get the type of device the application is running on, especially the AnalyticsVersionInfo.DeviceFamily property.
For different platform, you can decide how to sync up your records.
I have deployed an application to the Windows Store. Is there any way to find out how many of users have uninstalled the app?
The store does not get updated when an app is uninstalled, so you would instead need to consider some other way of measuring it with your analytics (for example, you might consider an app uninstalled if it is unused after thirty days for a given device id)
To achieve what Rowland Shaw proposed, you must manually implement some kind of telemetry in your app.
You can do it all by yourself by retrieving the Device ID via the appropriate API (a quick search on the web could help here) and later send that ID to your web service on a periodic basis.
Alternatively you can use third party frameworks, Application Insights, just to name one, but I don't know if it allows you to track a specific Device ID natively.
Could anyone explain how Chrome Extension upgrading works?
Let's say I publish version 0.0.1. After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2? If not, what is the process to sending/updating Chrome Extensions?
Thanks!
After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2?
Yes. By default, if you publish (not just submit a draft, actually publish and wait for the automated review process to complete) a new version then all users will get it.
..eventually.
Chrome does not get push notifications about extension updates; it instead polls the Web Store for version information once every few hours.
While it would be possible for Google to make this push-based, I think this remains in place as a natural load-balancer (not everyone trying to update at once) and a bit of a safety net in case you published something badly broken.
On the extension side, there are 2 things in the chrome.runtime API that can influence the process.
You can force a check for a new version with chrome.runtime.requestUpdateCheck(). Note that this is rate-limited - you can't check too often.
In principle you could use some other method of delivering a notification to your extension (GCM, WebSockets to your server, polling your server etc.) to discover an update and trigger this check.
You can delay an update after it was detected with a listener to chrome.runtime.onUpdateAvailable event. It can be delayed no longer than the next browser restart.
If your extension has a lot of users (this starts at 10k users), there's an additional option available in the Dashboard's edit item interface.
Is it possible to perform a partial roll out in the Chrome web store?
CWS offers an option to only offer this version to a developer-specified percentage of users. This way you can limit the damage from a bad update.
Does WP8 have any OS hook or callback (sync mechanism) I can implement to get a notification when a contact changes?
For example I'm running an application as a background agent, and a user randomly changes a contact's details. I want to get notified in my background engine so that I can do various operations.
I could always implement a periodic check (say every minute I read all contacts and check to see if there are any modifications - assuming I'm remembering the last configuration somehow). But this solution is not efficient for a large number of contacts, especially when I want the application to run on the low end phones.
Windows Phone does not support any built in way for applications to be notified of contact changes.
As you've noted, the only way to do this would be to track the details and periodically look for differences. Yes, you'd have to do this with the app running (rather than a background agent) if you want to support WP7 devices with one 256MB of memory.
As an alternative and assuming that the user is syncing their contacts with their live.Windows account you could create an external service that periodically polls their live account (via http://msdn.microsoft.com/en-us/live/ff519582.aspx) for changes and then send a notification to the device/app regarding the change.
I am wondering if someone knows the best method for storing data in a global DB against a mobile device (iOS and Android)?
I am building an app that writes/retrieves information based on a query however I need to know if any of the records returned were sent from that device.
Basically the idea is that if a user submits some information (which is stored in the DB) they gain access to additional features of the app. When the app is launched, I will check the DB to see if they submitted information in the past and allow access to other areas.
I use local storage for the information they submitted but also store remotely so if the local storage becomes corrupted for any reason there is still a record of the information the user submitted.
The ID needs to be unique to the device as there could be 100 of users (hoping for millions) so the ID needs to be unique enough that it will never conflict with another device. Any information submitted will be available for retrieval by all other users.
Thanks :)
There are three options as I see it:
1. User
You can create a typical username + password user scheme and use this to verify the user. A possible advantage of this method would be that the user can log in from any of their devices (for instance, under your method a user using the app from their iPhone and iPad would have two different views - which you may not want). Of course, this means forcing every user of the app to register within your system, which is not ideal.
2. App Install
You can uniquely identify an app install by having your app generate a UUID the first time that the app is run (you can use an AS3 helper library to generate the UUID). You can store this UUID locally and send it along with every request the app makes. The downside to this approach is that it doesn't uniquely identify the device - only a specific app install. For instance, if the user deletes the app and then reinstalls it at a later point, it will now count as a new unique device, even though the user is on the same device.
3. Device
AIR does not have a built-in way of reading device identifying info. However, you can retrieve device info through AIR Native Extensions, for example this one can get the MAC address and some other things. There are privacy concerns and other issues involved in reading and storing device info such as these, so you are probably best served trying to implement the OpenUDID project as an AIR Native Extension, since they have already dealt with all such issues. Unfortunately, I have never looked too far into developing ANE's so I am not sure how complicated or feasible it will be to turn OpenUDID into an ANE.
Summary: I would recommend the app install method due to the ease of implementation. If you really need the unique device and are worried about the multiple app installs case, you will have to work out how to use native extensions to get the info you need. If you decide that you would rather identify by user rather than device, use the user method.
As of now I don't think its possible to get the hardware devices guid using air mobile. However you do have a couple of options.
If the MAC address is good enough for you there is an ANE that will let you grab it on both iOS and Android.
http://www.adobe.com/devnet/air/native-extensions-for-air/extensions/networkinfo.html
and an example of how to use it
http://cookbooks.adobe.com/post_Getting_NetworkInfo_from_both_Android_and_iOS-19473.html
You could also write your own ANE, it should be pretty simple to wrap both Android and iOS implementations.
Objective-c: [[UIDevice currentDevice] uniqueIdentifier]
Android: TelephonyManager.getDeviceId()
If your app requires any kind of user account or login the best option would be to store this setting in the remote db.