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.
Related
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.
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?
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.
I'm looking to develop a mobile app which is going to help people find out whether a train is going to go to a particular platform or not.It is very simple. I know the timetables. I'll be making database of train timings and compare with the timings of user, when he uses the app and tell him, if the next train coming at the station he's at, is going to this platform at location X or not.
There won't be any fancy UI. There would be a dropdown of all stations. That's it. Response from the app will be going to platform no A. I don't know if I will include any feature as of now. The requirement that I see is, app should be offline and platform agnostic.The database entries are fixed and if they change then I should be able to give a new update.I have been reading about HTML5, but I don't want people to use the Internet for this. It should be available on Nokia phones,Android phones, Blackberry,Apple in that order.
Offline and platform agnostic will be hard to combine, unless you use one of the toolkits that pretend to do this (we started that way, but reverted - cost more time to chase bugs in the toolkit than to write code). Easiest is you give up the first requirement - most people with smart phones will have data bundles anyway, a tiny query is not going to make them frown.
Assuming you're not dropping the requirement, HTML5 for the UI can still be an option as most platforms let you embed the browser in your app. That way, you'd only need to port some small wrapper code and the business logic. If it's a commercial app, pick one or two key platforms (that will give you the necessary user feedback to make your app better) and outsource porting of the rest.
This is a tough one... I'd choose native programming. Id just have all the different platforms linked so they use the exact same database. Unfortunately, they all use different programming languages. I don't know about Nokia or Blackberry, but Android uses Java (or C# through MonoDroid) while Iphones/Ipods use Obj-C (or C# through MonoTouch).
I have to architect a commercial vehicle fleet tracking system.
Each vehicle (a few 100, max a few 1,000) will have a GPS and satellite transmitter and will periodically report its position. Positions will be stored in a database and used to create a Google Map.
There will of course be other functionalities. Security, log in, etc and probably lots of interaction with other corporate databses (drivers start/stop time for salary purposes, etc).
Question: pure GoogleMaps is probably best implemented as a browser based app (Php & MySql?), but with the additional functionality of a commercial vehicle fleet tracking system, would it be better doing something PC based (Windows/Linux)?
Any other advice? Thanks
I think with the capabilities of modern browsers, along with various mature client-side frameworks, we are witnessing an always thinning distinction between web and desktop interfaces.
You may want to take into consideration that a web application automatically solves some important problems for you:
Distribution: No need to distribute your application. Simply provide a URL.
Updates: Upgrading and fixing problems in your software will be easier and quicker if you distribute it through a web interface.
Security: Deriving from the above, you are able to fix security vulnerabilities more promptly.
Compatibility: Your application will be able to work on any operating system that can launch a web browser.
Last but not least, remember that the Google Maps API is not free for this type of application. Article 10.9.C of Google Maps API Terms and Conditions explicitly restrict using the standard Google Maps API for fleet management and asset tracking. You would need the Google Maps API Premier to legally use Google Maps for your application.
According to one unofficial source (dated April 2008), this would cost USD 10,000 per year, which entitles you to track 100 vehicles. If you exceed the 100 vehicles, you would need to add USD 24 per additional vehicle per year.
Implement solution for the domain problems first. It means data storage, data transmission between vehicles and your system, methods of data analysis, aggregation and visualisation.
These will likely to sit as a head-less system on a server and provide access to it remotely, in both directions: to input data and to query data.
Now, PC or Web is more related to presentation on a client side. You can make both if you like. Web client as well as desktop application can serve as a client to remote data and operational server.
Don't forget that you can always host a web control in a thick client app. This is actually trivial with .Net on the Windows platform with the IE control. You can also access the browser's DOM this way and do some neat things. So just because there's a strong web component to what you're doing you're not necessarily "stuck" writing a pure web app.
One big question is what kind of hardware you'll be able to put in the vehicles. Will they be laptops or small PCs with full fledged OSs or something more mobile like CE or a pared-down Linux distro?
Google Maps is JavaScript based so you can do most things with it, e.g browser based, widgets, etc. However due to the licensing Google won't allow you to use it in anything other than an Internet environment unless you use there Enterprise License.
In terms of integrating it into other systems, its really difficult to say what's best without knowing what other software you are using, what protocols they use, are web services available, etc. I agree with Daniel though in that any distributed system not implemented in a browser better have some good reasons not to, simply because the benefits are substantial. You'll need to weight them up though with a full break down of all the different systems you will need to interact with and work out what fits best.
The great thing is that with it being JavaScript based you have a lot of flexibility in what you can do with it.
This is more an extension to #Daniel Vassallo's answer. Although a web based application would solve most problems there may be the small potential issue of bandwidth usage and reception for internet access. This may or may not be an issue for the fleet management, depending on how that is tackled on the hardware side of things.
An offline solution may assist with this issue but then a clever architect could find a way to create an initial web based solution which can be accessed with an offline application which can pick up the slack and/or provide predictive reasoning until a connection is re-established.